AWS CLI profiles and SSO: a hands-on guide for engineers

The problem with shared keys

Most teams start with AWS by creating one IAM user, generating access keys, and sharing them around. A developer needs to deploy; they copy the keys into their laptop. Someone spins up a test environment; they get the same keys. Before long, you've got long-lived credentials scattered across devices, CI/CD systems, and Slack messages. One compromised laptop puts your entire AWS estate at risk. AWS CLI profiles and SSO: a hands-on guide for engineers shows you how to move past this.

Why profiles matter

Named profiles let you configure multiple AWS identities on a single machine. Instead of one set of credentials doing everything, you can switch contexts with a flag. This is the first step toward sanity.

Without profiles, the AWS CLI looks for credentials in a fixed order: environment variables, then ~/.aws/credentials, then IAM instance metadata. You end up with one identity active at a time, usually the default. If you need to work across multiple accounts—dev, staging, production—you're either overwriting credentials constantly or using environment variables as a workaround.

Profiles change that. Each profile in ~/.aws/config and ~/.aws/credentials is a named configuration. You invoke the one you need with --profile prod or AWS_PROFILE=prod.

Here's a basic setup:

# ~/.aws/config
[profile dev]
region = us-east-1
output = json

[profile staging]
region = us-east-1
output = json

[profile prod]
region = us-east-1
output = json

Then in ~/.aws/credentials, you'd store keys for each:

[dev]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

[staging]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

[prod]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

Now you can switch contexts in one command:

aws s3 ls --profile dev
aws s3 ls --profile prod
aws ec2 describe-instances --profile staging

Or set the environment variable once in your shell session:

export AWS_PROFILE=prod
aws s3 ls
aws ec2 describe-instances

All subsequent commands use the prod profile until you change it. This is much cleaner than juggling environment variables.

Short-lived credentials with SSO

Profiles are useful, but storing long-lived IAM user keys on your laptop is still a risk. AWS SSO (now part of AWS IAM Identity Center) solves this by giving you short-lived credentials that expire after a few hours.

SSO works through your corporate identity provider—Okta, Azure AD, or even AWS's own identity store. You log in once, the CLI gets temporary credentials, and you're good to go. When they expire, you log in again. No keys to leak.

Setting it up is straightforward:

aws configure sso

The CLI prompts you for your SSO start URL (something like https://my-org.awsapps.com/start) and the region where your identity center lives. It opens a browser, you log in, and the CLI stores the configuration.

SSO start URL [None]: https://my-org.awsapps.com/start
SSO region [None]: us-east-1
SSO account ID [None]: 123456789012
SSO role name [None]: DeveloperAccess
CLI default client Region [None]: us-east-1
CLI default output format [None]: json
CLI profile name [None]: prod

This creates a profile in ~/.aws/config that points to SSO:

[profile prod]
sso_start_url = https://my-org.awsapps.com/start
sso_region = us-east-1
sso_account_id = 123456789012
sso_role_name = DeveloperAccess
region = us-east-1
output = json

No credentials file needed. When you use this profile, the CLI checks for cached temporary credentials. If they've expired, it prompts you to log in:

aws s3 ls --profile prod

If credentials have expired, you'll see:

To use SSO profiles, run: aws sso login --profile prod

Run that command, authenticate in your browser, and you're back in business:

aws sso login --profile prod
Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use the alternate flow, enter the following URL:
https://device.sso.us-east-1.amazonaws.com/...

Successfully logged in via SSO.

The credentials are cached locally and automatically refreshed when needed. If your identity provider revokes your access or you leave the company, AWS revokes those credentials server-side immediately. Long-lived keys can sit on stolen laptops for weeks before anyone notices.

No keys on your laptop

The shift from long-lived keys to short-lived SSO credentials changes your security posture dramatically. A developer's laptop is not a secure vault. It gets stolen, it runs untrusted software, it connects to public WiFi. If it contains AWS keys, it's a liability.

Short-lived credentials limit the blast radius. If your laptop is compromised tomorrow, an attacker gets credentials that expire in four hours. If they get your IAM user's long-lived key, they can drain your AWS account until someone notices.

SSO also gives you audit trails. Every login is logged. You know who accessed what, when, and from where. With shared keys, you lose that visibility entirely.

The workflow becomes: log in once per day with SSO, use your laptop for work, and when you're done, your credentials naturally expire. You're never storing sensitive keys at rest.

Even better, you can combine SSO profiles with role chaining for cross-account access without ever touching keys directly.

Role chaining for cross-account work

In larger organizations, you often have separate AWS accounts for different environments or teams. You might have a central identity account where SSO lives, a dev account, and a prod account. You need to access resources in prod, but your user is in the identity account.

Role chaining (or role assumption) solves this. You log in with your SSO identity in the identity account, then assume a role in the prod account. The prod account trusts the identity account and allows the assumption.

First, set up your SSO profile to the identity account:

[profile identity]
sso_start_url = https://my-org.awsapps.com/start
sso_region = us-east-1
sso_account_id = 111111111111
sso_role_name = IdentityAccess
region = us-east-1

Then create a profile that assumes a role in the prod account:

[profile prod]
role_arn = arn:aws:iam::222222222222:role/CrossAccountProdAccess
source_profile = identity
region = us-east-1

Now when you use the prod profile, the CLI:

1. Authenticates with SSO using the identity profile
2. Calls sts:AssumeRole to get temporary credentials for the prod role
3. Passes those credentials to your command

aws s3 ls --profile prod

You're accessing the prod account without ever handling its keys. The prod account's security team controls the trust relationship and can revoke access at any time. This scales to dozens of accounts and roles.

You can even chain assumptions: assume a role in an intermediate account to assume a role in a third account. This is useful for strict separation of duties.

Common mistakes

Storing SSO credentials in version control: Your ~/.aws/config is fine to commit (no secrets). Your ~/.aws/credentials should never be. If you're using SSO, credentials are cached in ~/.aws/sso/cache/—keep your entire .aws/ directory out of git.

Forgetting to set up role trust relationships: If you define a role ARN in a profile but the target account's role doesn't trust your identity account, assumption fails silently. Check the role's trust policy before debugging the CLI.

Mixing SSO and IAM user keys: Don't set up both in the same profile. Choose one method per profile. If you have legacy systems that need long-lived keys, isolate them in a dedicated profile and restrict those keys heavily.

Not rotating SSO credentials during testing: SSO caches credentials. If you're testing permission changes, you may need to log out and log back in for the new permissions to take effect. Run aws sso logout --profile prod to clear the cache.

Assuming you can't use profiles in CI/CD: You can. CI/CD systems can run aws sso login using a service account, or better yet, use IAM roles attached to EC2 instances, ECS tasks, or Lambda functions. No credentials needed at all.

Key takeaways

• Named profiles let you manage multiple AWS identities on one machine and switch between them with --profile or AWS_PROFILE.
• SSO replaces long-lived IAM user keys with short-lived credentials that expire after a few hours, dramatically reducing the risk from laptop compromise.
• Use aws configure sso to set up a profile, then aws sso login --profile name to authenticate and cache temporary credentials.
• Role chaining (assuming roles across accounts) lets you access resources in other AWS accounts without handling their keys directly.
• Never store IAM user keys on developer laptops when SSO is available; the temporary credentials are more secure and easier to audit.
• Combine profiles, SSO, and role chaining to build a scalable credential management system that works across accounts and environments.