Everything you need to know about AWS CLI Profiles

The AWS CLI uses two files in ~/.aws/:

• ~/.aws/credentials — access keys, one section per profile.
• ~/.aws/config — region, output format, SSO settings.

If you only have one AWS account this is overkill, but the moment you have a personal account and a work account — or several work accounts — profiles are what let you keep them all addressable from a single shell. Here's the lay of the land in 2026, starting with the legacy access-key flow and ending with IAM Identity Center, which is what you should actually be using.

Multiple profiles, the basics

Each section in ~/.aws/credentials is a profile. Add new ones beneath [default]:

In ~/.aws/config, the section names are prefixed profile (except for [default]):

These files are INI, despite the = syntax looking TOML-ish.

Switching profiles

Use --profile:

Or set AWS_PROFILE (AWS_DEFAULT_PROFILE is the older name and still works, but AWS_PROFILE wins if both are set):

If --profile is omitted and neither env var is set, the CLI uses [default].

Aliases are convenient when you switch between two or three profiles all day. Add to your shell rc file:

Then awspersonal s3 ls runs against the personal profile without changing the env for the rest of the shell.

IAM Identity Center: the right way in 2026

What used to be called "AWS SSO" was renamed IAM Identity Center in mid-2022. The CLI integration was overhauled at the same time — modern AWS CLI v2 (since 2.9) writes a separate [sso-session] block that profiles reference by name, rather than inlining the SSO settings into every profile.

Run:

The wizard prompts for an SSO session name first, then the start URL, region, account, and role:

It opens a browser, you click through the device-grant flow, and the wizard writes something like this to ~/.aws/config:

After that, aws s3 ls --profile work just works. When the SSO session expires (12 hours by default), you'll get a token error — re-authenticate with:

The CLI does not silently re-launch the browser flow on expiration; you have to ask.

The big win: no long-lived access keys on disk. Temporary credentials are fetched fresh per role assumption and cached under ~/.aws/sso/cache/ until the session expires.

When you're stuck with long-lived keys

Some CI runners, third-party tools, and bootstrap scripts still want raw AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY env vars. If you can't avoid them, get them out of the plaintext credentials file.

Option 1: credential_process. Point ~/.aws/config at a tool that returns credentials as JSON. The de-facto choices in 2026:

• aws-vault — stores keys in the OS keychain, vends short-lived session tokens to the CLI on demand.
• granted — same idea, plus per-tab role switching for the AWS console.
• Leapp — GUI alternative if you'd rather not drive it from the terminal.

These plug into the AWS CLI through credential_process, so every SDK that reads the shared config picks them up automatically.

Option 2: hand-rolled keychain export. Lower-level, no extra binaries. Stuff the keys into the OS keychain and export them in your shell:

secret-tool matches secrets by attribute key/value pairs — the service and account attributes have to be identical between the store and lookup calls. The actual secret is read from stdin during store.

Both options beat plaintext in ~/.aws/credentials. Both are still worse than IAM Identity Center.