AWS CLI v2 first steps: profiles, IAM Identity Center sign-in and checking who you are

The AWS CLI does exactly what you ask, in whichever account and region your shell is pointing at. Getting that pointing right is most of what a beginner needs to learn.

#Install and check

Install AWS CLI v2 from the AWS documentation for your OS, or open CloudShell in the console, which is already signed in.

aws --version          # should start with aws-cli/2.

#Sign in with IAM Identity Center (recommended)

Ask your admin for the start URL and SSO region. Then:

aws configure sso
# SSO session name: corp
# SSO start URL: https://d-1234567890.awsapps.com/start
# SSO region: eu-west-1
# then pick an account and role, a default region and output format
# and name the profile, e.g. dev-admin

Later sign-ins:

aws sso login --sso-session corp
aws sts get-caller-identity --profile dev-admin

Tokens expire after the session duration your admin set. When commands start failing with Token has expired, run aws sso login again.

Warning

Avoid aws configure with long-lived access keys for people. Keys in ~/.aws/credentials end up in backups, screenshots and Git repos. Use Identity Center for humans and IAM roles for workloads.

#Profiles: one per account and role

~/.aws/config ends up looking like this:

[sso-session corp]
sso_start_url = https://d-1234567890.awsapps.com/start
sso_region = eu-west-1
sso_registration_scopes = sso:account:access

[profile dev-admin]
sso_session = corp
sso_account_id = 111111111111
sso_role_name = AdministratorAccess
region = eu-west-1
output = json

[profile prod-readonly]
sso_session = corp
sso_account_id = 222222222222
sso_role_name = ReadOnlyAccess
region = eu-west-1

Use a profile per command, or for the whole shell:

aws s3 ls --profile prod-readonly
export AWS_PROFILE=dev-admin          # bash
$env:AWS_PROFILE = "dev-admin"        # PowerShell

#Always check who and where

aws sts get-caller-identity
aws configure get region
aws configure list

get-caller-identity returns the account ID and the role ARN. Make it a reflex before any create, change or delete.

A stray AWS_ACCESS_KEY_ID in the environment beats your profile and is a classic "why am I in the wrong account" cause:

env | grep ^AWS_

#Output and filtering

aws ec2 describe-instances --output table
aws ec2 describe-instances --query "Reservations[].Instances[].[InstanceId,State.Name,InstanceType]" --output table
aws ec2 describe-instances --filters "Name=tag:env,Values=dev" --query "Reservations[].Instances[].InstanceId" --output text

--filters runs on the server (less data back); --query trims the result locally. Combine them.

#Helpful defaults

export AWS_PAGER=""                 # stop output opening in less
aws configure set cli_auto_prompt on-partial --profile dev-admin   # interactive prompts

#A safe first session

aws sso login --sso-session corp
export AWS_PROFILE=dev-admin
aws sts get-caller-identity --query "[Account,Arn]" --output text
aws s3 mb s3://my-cli-lab-$RANDOM --region eu-west-1
aws s3 ls

#Common first-week errors

#Prevent it next time

• Put the profile and account in your shell prompt.
• Keep production profiles read-only by default; use a separate, deliberately chosen profile for changes.
• In scripts, pass --profile and --region explicitly and stop on errors (set -euo pipefail).