Getting Started with AWS

This content was generated with the assistance of AI and should be verified against the official documentation before being relied on in production.

See the section bibliography for the reference material consulted while preparing these pages.

Examples on this page target AWS CLI v2 (2.37 at the time of writing, verified against the official changelog) and the AWS SDK for Java 2.x. Command names and flags are stable across CLI patch releases, but run aws update before following along if a command reports itself as missing. The Free Tier terms described below are the credit-based plans that apply to accounts created on or after 2025-07-15; they change from time to time, so always re-check the linked official page before relying on them.

From account to profile

Getting productive on AWS is a short chain of steps, and each one has a security decision attached:

  1. Create the AWS account. Its first identity is the root user, which is protected with MFA and then put away.

  2. Enable IAM Identity Center and create a workforce user with a permission set. This is the identity you use every day.

  3. Install the AWS CLI v2 and create a profile with aws configure sso. The profile stores no secret: it points to the Identity Center portal and to an account and role.

  4. Run aws sso login to obtain short-lived credentials, and let the CLI and SDKs resolve them from the profile.

flowchart LR A["AWS account\n(email + root user)"] --> B["Root user: MFA enabled,\nthen not used day to day"] B --> C["IAM Identity Center\nenabled (home Region chosen)"] C --> D["Workforce user +\npermission set (for example AdministratorAccess)"] D --> E["aws configure sso\n(profile in ~/.aws/config)"] E --> F["aws sso login\n(browser, short-lived token)"] F --> G["CLI / SDK / IaC tools\nuse temporary role credentials"]

Creating an account and securing the root user

An AWS account is the basic container for resources, permissions and billing. Creating one takes an email address, an account name, contact details, a payment method and phone verification. The email address and password you sign up with belong to the root user, an identity with unrestricted access that cannot be limited by IAM policies. Treat it as a break-glass identity:

  • Enable multi-factor authentication on the root user immediately. MFA for the root user is now mandatory for all account types, and passkeys and security keys are supported alongside authenticator apps.

  • Use a shared mailbox or distribution list that several administrators can read for the root email, and a long random password kept in a password manager.

  • Do not create access keys for the root user and do not use it for daily work. A handful of tasks (closing the account, changing the support plan in some cases, restoring a lost administrator) still require root; everything else should go through an Identity Center user or an IAM role.

  • Once you adopt AWS Organizations, centralized root access lets member accounts have no root credentials at all. See Accounts and Organizations for that and for multi-account structure.

In the AWS Management Console

  1. Open the AWS sign-up page, choose Create an AWS account, and enter the root user email address and an account name.

  2. Verify the email address with the code you receive, then set the root password.

  3. Choose the account plan (see the next section), enter contact details and a payment method, and verify your phone number.

  4. Sign in as Root user and open the account menu at the top right, then Security credentials.

  5. Under Multi-factor authentication (MFA), choose Assign MFA device, pick a passkey or security key, authenticator app or hardware token, and follow the prompts.

With the AWS CLI

Account sign-up itself is console-only. Once you have credentials for any identity, the first command to run verifies who you are acting as:

# Show the account ID, user or role ARN and principal ID of the active credentials
aws sts get-caller-identity

# Keep the account ID in a variable for later examples (a placeholder such as 111122223333 is used in docs)
ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
echo "$ACCOUNT_ID"

References: aws sts get-caller-identity.

The Free Tier plans

Accounts created on or after 2025-07-15 choose between two account plans at sign-up. Both receive sign-up credits and can earn additional credits by completing guided activities (the current amounts are listed on the official Free Tier plans page), and both include the always-free offers, which are monthly allowances for a set of services that do not expire.

Free plan Paid plan

Charges

No charges while exploring: usage draws down credits.

Standard pay-as-you-go pricing for anything beyond the credit balance.

Duration

Ends after six months or when the credits are used, whichever comes first.

No expiry; the account stays open when credits run out.

Services

A subset of services and features. Services that could burn through credits quickly (Savings Plans, Reserved Instances, some Marketplace offers) and hardware purchases are excluded.

All services and features, plus short-term trials for selected services.

Other promotions

Not eligible for other promotional credits and discounts.

Eligible.

When it ends

The account closes automatically and access to resources is lost. AWS keeps the content for 90 days; upgrading to the Paid plan within that window restores access, and remaining credits apply to future bills.

Not applicable.

Several actions upgrade a Free plan to a Paid plan automatically, among them joining AWS Organizations or setting up an AWS Control Tower landing zone. Upgrading manually is a single action in the Billing and Cost Management console. Accounts created before 2025-07-15 stay on the legacy model: a 12-month window of monthly free usage limits for specific services, the always-free offers, and short-term trials. Older guides and tutorials still describe only that legacy model, so expect their free-usage claims to be out of date.

The practical advice is the same on either plan: set a budget alert on day one (see below), tag what you create, and follow the Clean up step of every hands-on page in this section. Pricing for each service is covered on its own page and in Cost Management and Support; this section never hard-codes prices because they change.

In the AWS Management Console

  1. Open Billing and Cost Management from the search bar. The home page shows your credit balance and the plan you are on.

  2. To see free-usage allowances, open Free Tier in the left navigation pane.

  3. To move to the Paid plan, choose Upgrade plan, review the features gained, and choose Upgrade account.

With the AWS CLI

# List Free Tier usage and limits per service (the Billing console is the primary view)
aws freetier get-free-tier-usage \
  --query "freeTierUsages[].{service:service,usage:actualUsageAmount,limit:limit,unit:unit}" \
  --output table

# Show the current account plan
aws freetier get-account-plan-state

References: aws freetier get-free-tier-usage, aws freetier get-account-plan-state.

Setting a first budget alert

A budget with an email alert is the cheapest safety net you can install. Billing and Cost Management is a global console area, so it does not depend on the Region selector.

  1. In Billing and Cost Management, open Budgets and choose Create budget.

  2. Pick the Use a template (simplified) option, then Monthly cost budget.

  3. Enter a budget amount you are comfortable with and the email addresses to notify, then choose Create budget.

ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)

cat > budget.json <<'JSON'
{
  "BudgetName": "monthly-guardrail",
  "BudgetLimit": { "Amount": "10", "Unit": "USD" },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST"
}
JSON

cat > notifications.json <<'JSON'
[
  {
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [ { "SubscriptionType": "EMAIL", "Address": "admin@example.com" } ]
  }
]
JSON

aws budgets create-budget \
  --account-id "$ACCOUNT_ID" \
  --budget file://budget.json \
  --notifications-with-subscribers file://notifications.json

References: aws budgets create-budget, Managing your costs with AWS Budgets.

A daily-use identity with IAM Identity Center

AWS IAM Identity Center (the successor of AWS Single Sign-On, renamed in 2022) is the recommended way for people to reach AWS accounts. You define users and groups (or connect an external identity provider), define permission sets (reusable bundles of policies), and assign them to accounts. A sign-in produces short-lived credentials for a role in the target account, so no long-lived access keys ever exist on a laptop. Older guides and tutorials still start by creating an IAM user with access keys; that is now the discouraged fallback. The full model, including IAM users, roles and policy evaluation, is in Identity and Access.

Identity Center is enabled in one Region, its home Region, which cannot be changed later without recreating the instance, so choose the Region you expect to keep (see AWS Global Infrastructure). With a standalone account, an account instance is created; with AWS Organizations, an organization instance can manage every member account.

In the AWS Management Console

  1. Sign in (as the root user for this one-time step, or as an administrator) and make sure the Region selector shows the Region you want as the home Region.

  2. Search for IAM Identity Center and choose Enable. Accept the creation of an organization instance if prompted.

  3. In the left navigation pane choose Users, then Add user, and fill in a username, email address and name. The user receives an email to set a password and register an MFA device.

  4. Choose Permission sets, then Create permission set, pick Predefined permission set, and select AdministratorAccess for a first administrator (use a narrower job-function set as soon as you can).

  5. Choose AWS accounts, select your account, choose Assign users or groups, pick the user and the permission set, and submit.

  6. Note the AWS access portal URL on the Identity Center dashboard; you will need it for the CLI.

With the AWS CLI

Identity Center administration uses the sso-admin and identitystore commands. The portal sign-in itself is console-only for the first user.

# Find the Identity Center instance ARN and its identity store ID
aws sso-admin list-instances \
  --query "Instances[0].{arn:InstanceArn,store:IdentityStoreId}" --output table

# List the permission sets that already exist
INSTANCE_ARN=$(aws sso-admin list-instances --query "Instances[0].InstanceArn" --output text)
aws sso-admin list-permission-sets --instance-arn "$INSTANCE_ARN"

References: aws sso-admin list-instances, aws sso-admin list-permission-sets.

Console tour

The AWS Management Console is a single web application for every service. The elements worth learning first:

  • Unified search (the search bar at the top): finds services, features, documentation and blog posts, and resources in some services.

  • Region selector: the Region shown at the top right scopes almost everything you see. A resource that seems to have vanished is usually in another Region. A few services are global (IAM, Route 53, CloudFront) and show Global instead; see AWS Global Infrastructure.

  • Account menu: shows the account ID, the signed-in role or user, and links to Security credentials, Billing and Cost Management and Switch role.

  • Favourites and recently visited: pin the services you use most to the navigation bar.

  • Console-to-Code: available in several services (Amazon EC2 is the most complete), it records the actions you click through and generates CLI, CloudFormation or CDK code for them, a fast bridge to the infrastructure as code workflow in Infrastructure as Code.

  • Resource Groups & Tag Editor: finds and groups resources across services and Regions by tag. The older myApplications dashboard is in maintenance, so prefer Resource Groups for new work.

  • Notifications and Health: service events and account-specific events appear under the bell icon.

AWS CloudShell

AWS CloudShell is a browser-based shell that opens from the console toolbar. It is already authenticated as the console identity, so no credential setup is needed, and it comes with the AWS CLI v2, the SDKs for several languages, git, jq, pip, npm and more. It has persistent home-directory storage per Region and is available at no additional charge for the shell itself (the resources you create from it are charged as usual). It runs in the Region currently selected in the console and is not available in every Region, so check the official list.

For a first CLI session, CloudShell is the shortest path: open it, run aws sts get-caller-identity, and carry on without installing anything. It is also handy for running examples from this section that only need the CLI.

In the AWS Management Console

  1. Choose the CloudShell icon in the top navigation bar (or search for CloudShell).

  2. Wait for the environment to start, then run aws sts get-caller-identity to confirm the identity.

  3. Use Actions to upload or download files, and the Region selector to start a shell elsewhere.

With the AWS CLI

CloudShell itself is a console feature. Inside it the CLI behaves like a local one:

aws --version
aws configure list
aws ec2 describe-regions --query "Regions[].RegionName" --output text

References: What is AWS CloudShell, aws configure list.

Installing the AWS CLI v2

The AWS CLI v2 is the supported command line interface. CLI v1 is a different product that uses the same aws command name: it enters maintenance on 2026-07-15 and reaches end of support on 2027-07-15, so if an older machine still has it, migrate. Verify the dates on the official page linked below.

The current install script is the recommended method on every platform. It downloads, verifies and installs the CLI for the current user by default.

# Linux and macOS: install for the current user
curl -fsSL https://awscli.amazonaws.com/v2/install.sh | bash

# Linux and macOS: install for all users
curl -fsSL https://awscli.amazonaws.com/v2/install.sh | sudo bash -s -- --system

# Verify
aws --version

References: Installing or updating to the latest version of the AWS CLI.

On Windows the equivalent is irm https://awscli.amazonaws.com/v2/install.ps1 | iex from PowerShell. The guided alternatives are the macOS .pkg installer, the Windows MSI installers and the Linux zip installer (useful when you need to pin a version), plus an officially supported snap package that updates itself. On Amazon Linux, remove the pre-installed package manager version of the CLI first.

To update an installation made with the script or an official installer:

aws update

References: AWS CLI update instructions.

Credentials for the CLI

The CLI supports several ways to authenticate. Prefer the first two for people, and never use long-lived keys when one of the others is possible:

Method When to use it Notes

aws configure sso then aws sso login

Workforce users with IAM Identity Center. The recommended default.

Profile stores the portal URL, account and role, not a secret. Credentials are short-lived and cached.

aws login

A person who signs in to the console with an IAM user, root or federated identity and wants the CLI to use those console credentials. Added in CLI 2.32 (November 2025).

Opens the browser to authorize, then issues temporary credentials. Intended for interactive use; not for CI.

Environment variables or an assumed role (role_arn plus source_profile)

Automation that already holds temporary credentials, or cross-account access.

Credentials from sts assume-role expire; scripts must refresh them.

Container, instance and function roles

Code running on ECS, EC2, Lambda or EKS.

Credentials are delivered by the platform; nothing to configure.

aws configure with access keys

Only as a discouraged fallback when nothing else is possible.

Long-lived keys are the most common cause of leaked credentials. Rotate them and prefer the options above.

In the AWS Management Console

  1. Open the account menu and note your account ID and the role or user you are signed in as.

  2. Use Security credentials (IAM user) to see access keys and MFA devices; for Identity Center users the AWS access portal page lists accounts and roles and offers Access keys for temporary credentials when you need a one-off.

With the AWS CLI

Create an SSO profile. The wizard asks for a session name, the portal start URL, the Identity Center Region and the registration scopes, opens the browser to sign in, then asks you to pick an account and role:

# One-time profile creation (interactive)
aws configure sso

# Sign in (and sign in again whenever the session expires)
aws sso login --profile bookshelf-dev

# Use the profile
aws sts get-caller-identity --profile bookshelf-dev

# Sign out
aws sso logout

References: Configure the AWS CLI to use IAM Identity Center, aws sso login.

The result is a block in ~/.aws/config. The values below are placeholders:

[sso-session bookshelf]
sso_start_url = https://d-xxxxxxxxxx.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

[profile bookshelf-dev]
sso_session = bookshelf
sso_account_id = 111122223333
sso_role_name = AdministratorAccess
region = us-east-1
output = json

If you sign in to the console with an IAM user or federated identity and want the CLI to reuse that session, use aws login:

# Opens the browser to authorize this CLI with your console sign-in
aws login

# A named profile
aws login --profile bookshelf-console

# Remove the cached login credentials
aws logout

References: Login for AWS local development using console credentials, Announcement: console credentials for the CLI and SDKs.

Profiles, configuration files and environment variables

The CLI keeps settings in two plain-text files under ~/.aws/:

  • config: non-secret settings such as region, output, SSO sessions, role chaining. Profile sections are named [profile name] (and [default] for the default).

  • credentials: long-lived keys and cached static credentials, in [name] sections. Prefer not to have this file at all.

Settings are resolved in a fixed order: command-line options override environment variables, which override the shared files, which override container or instance metadata. For credentials the chain is shown below; SDKs follow the same idea with minor differences per language.

flowchart TD A["Command-line options\n(--profile, --region, --output)"] --> B["Environment variables\n(AWS_PROFILE, AWS_ACCESS_KEY_ID,\nAWS_REGION ...)"] B --> C["Profile in shared config/credentials files\n(SSO, login, assume role, process, keys)"] C --> D["Container credentials\n(ECS task role, EKS Pod Identity)"] D --> E["Instance profile via IMDSv2\n(EC2)"] E --> F["Nothing found: error"]

Useful environment variables are AWS_PROFILE (pick a profile for a shell session), AWS_REGION or AWS_DEFAULT_REGION, AWS_DEFAULT_OUTPUT, AWS_PAGER (set to an empty string to disable the pager) and the credential triplet AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_SESSION_TOKEN for temporary credentials.

With the AWS CLI

# Create several profiles, one per account or role
aws configure sso --profile bookshelf-prod

# List profiles and show where each setting comes from
aws configure list-profiles
aws configure list --profile bookshelf-dev

# Read and write single settings
aws configure get region --profile bookshelf-dev
aws configure set region eu-west-1 --profile bookshelf-dev

# Use a profile for the whole shell session
export AWS_PROFILE=bookshelf-dev
export AWS_REGION=us-east-1

References: Configuration and credential file settings, Environment variables, aws configure.

The legacy approach, shown only so you recognise it in older material, asks for a key pair and writes it to the credentials file. Do it only as a last resort and delete the key when you are done:

aws configure
# AWS Access Key ID [None]: <your-access-key-id>
# AWS Secret Access Key [None]: <your-secret-access-key>
# Default region name [None]: us-east-1
# Default output format [None]: json

References: Configuration and credential file settings.

Using the CLI effectively

Every command follows the shape aws <service> <operation> [options]. The help system is built in: aws help, aws ec2 help and aws ec2 run-instances help each show the corresponding level, and aws <service> <operation> --generate-cli-skeleton prints an input template you can fill and pass back with --cli-input-json file://…​;.

Choosing the Region

--region on a command overrides AWS_REGION, which overrides the profile region. Resources live in a single Region, so keep this explicit in scripts. Region selection criteria (compliance, latency, service availability, price) are discussed in AWS Global Infrastructure; examples in this section use us-east-1 as a placeholder.

# Regions enabled for your account, then those that are opt-in
aws ec2 describe-regions --query "Regions[].RegionName" --output text
aws ec2 describe-regions --all-regions \
  --query "Regions[?OptInStatus=='not-opted-in'].RegionName" --output text

# One command in another Region
aws ec2 describe-instances --region eu-west-1

References: aws ec2 describe-regions.

Output formats and client-side filtering with --query

--output accepts json (default), yaml, yaml-stream, text, table and off. --query applies a JMESPath expression to the JSON response on the client after it is returned, which is the right tool to extract a single value for a script or shape a readable table.

# A single value, ready for a shell variable
aws ec2 describe-vpcs --query "Vpcs[0].VpcId" --output text

# Selected fields from a list, as a table
aws ec2 describe-instances \
  --query "Reservations[].Instances[].{id:InstanceId,type:InstanceType,state:State.Name}" \
  --output table

# Filter on the client with a JMESPath predicate
aws ec2 describe-volumes --query "Volumes[?Size>=\`100\`].VolumeId" --output text

References: Filtering AWS CLI output, Setting the output format, JMESPath.

Server-side filtering, pagination and dry runs

--filters (where a service supports it) filters on the server, which is faster and cheaper than downloading everything and then using --query. Large lists are paginated automatically by default; --max-items, --page-size and --no-paginate control this. --dry-run (supported by many EC2 operations) checks permissions and parameters without creating anything.

# Server-side filter, then client-side projection
aws ec2 describe-instances \
  --filters "Name=instance-state-name,Values=running" "Name=tag:Project,Values=bookshelf" \
  --query "Reservations[].Instances[].InstanceId" --output text

# Limit and pagination
aws s3api list-objects-v2 --bucket "$BUCKET" --max-items 50 --page-size 25

# Validate a call without performing it
aws ec2 run-instances --image-id ami-0123456789abcdef0 --instance-type t3.micro --dry-run

References: Filtering AWS CLI output, Pagination, aws ec2 run-instances.

Interactive aids

The auto-prompt mode completes services, commands and parameters as you type, and the wizard-style aws configure family and aws <service> wizard commands cover a few multi-step tasks:

aws --cli-auto-prompt
aws configure set cli_auto_prompt on-partial

References: Turning on auto-prompt in the AWS CLI.

SDKs and the default credential chain

The AWS SDKs are the way application code talks to AWS. Official SDKs exist for Java, JavaScript/TypeScript, Python (boto3), .NET, Go, Rust, Kotlin, Swift, Ruby, PHP and C++. In this section Java is the primary language, using the AWS SDK for Java 2.x; boto3 and the modular JavaScript SDK v3 appear only where the official example is clearly better. Lifecycle notes for older SDKs that tutorials still use:

  • AWS SDK for Java 1.x reached end of support on 2025-12-31. Use the 2.x line (package software.amazon.awssdk).

  • AWS SDK for JavaScript v2 reached end of support on 2025-09-08. Use v3 (modular @aws-sdk/client-* packages) on a supported Node.js release.

All current SDKs resolve credentials with a default credential provider chain (the same idea as the diagram above): explicit settings, environment variables, shared config including SSO and login profiles, container credentials, and finally the EC2 instance profile. That means the same code runs unchanged on a laptop with an SSO profile and in production on an ECS task role, a Lambda execution role, an EKS Pod Identity or an instance profile. Never put access keys in code, in application.properties or in a container image.

// build.gradle / pom.xml: software.amazon.awssdk:bom, then add the modules you need (sts, s3, ...)
import software.amazon.awssdk.regions.Region;
import software.amazon.awssdk.services.sts.StsClient;
import software.amazon.awssdk.services.sts.model.GetCallerIdentityResponse;

public class WhoAmI {
    public static void main(String[] args) {
        // Region and credentials come from the default chain (AWS_REGION, AWS_PROFILE, role, ...)
        try (StsClient sts = StsClient.builder().region(Region.US_EAST_1).build()) {
            GetCallerIdentityResponse id = sts.getCallerIdentity();
            System.out.println("Account: " + id.account());
            System.out.println("ARN: " + id.arn());
        }
    }
}

References: AWS SDK for Java 2.x Developer Guide, Credential provider chain (SDKs and Tools reference guide).

To run this locally with an SSO profile, set AWS_PROFILE=bookshelf-dev and run aws sso login --profile bookshelf-dev first; the SDK picks up the cached token. The Spring Boot libraries for AWS (Spring Cloud AWS 4.x for Spring Boot 4, 3.4.x for Spring Boot 3.5) build on the same chain and are used in later pages. Console-to-Code, CloudShell and the SDK are complementary: explore in the console, script in the CLI, and move repeatable infrastructure into code as shown in Infrastructure as Code. CI pipelines should obtain credentials by OIDC federation instead of stored keys, as shown in Developer Tools and DevOps.

Where to go next

References