Welcome to the glorious world of AWS profiles where credentials can be organized or they can breed like rabbits. This quick guide shows how to create and switch named AWS CLI profiles so your scripts do not accidentally run against prod while you were aiming for dev. You will learn how to create profiles, run commands under a chosen account and region, use temporary session variables, edit the config files like a grown up, and wire up assume role entries for cross account access.

Create a named profile the easy way

If you want a profile called dev, run the configure helper and answer a few prompts. This stores access keys and defaults for that profile in your user aws folder so you do not have to memorize credentials or write them on sticky notes.

aws configure --profile dev

When prompted give your access key id, secret access key, default region and output format. The CLI will save those values to ~/.aws/credentials and ~/.aws/config as appropriate.

Run commands under a specific profile

When you want a command to use a named profile just add the flag like you mean it. This is the least dramatic way to keep things safe.

aws s3 ls --profile dev

Quick one off sessions using an environment variable

For a single command or a short lived shell session you can set the AWS_PROFILE environment variable. On Linux or macOS do this in the same line if you are feeling lazy.

AWS_PROFILE=dev aws sts get-caller-identity

On Windows PowerShell you can set the session variable and then run commands in that same shell.

$env:AWS_PROFILE = "dev"
aws sts get-caller-identity

Edit the credentials and config files when needed

Advanced users who like direct control can edit these files by hand. They live under your home directory. The credentials file stores keys that should be treated like nuclear codes. The config file stores profile settings like default region and assume role entries.

~/.aws/credentials
[dev]
aws_access_key_id = AKIA...
aws_secret_access_key = abc123...

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

Use plain text editing for custom fields such as role_arn and source_profile when setting up cross account roles.

Create assume role profiles for safer cross account access

If you hate long lived keys in ten different places use a source profile with long lived credentials and then assume role entries for short lived access. This keeps your life cleaner and your audit logs less weepy.

~/.aws/config
[profile analytics]
role_arn = arn:aws:iam::123456789012:role/AnalyticsRole
source_profile = dev
region = us-east-1
output = json

After that you can call the analytics profile exactly like any other profile. The CLI will use the source_profile to get credentials then assume the role and hand you short lived session tokens.

Troubleshooting and best practices

• Give profiles clear names that reflect purpose such as dev prod analytics. Ambiguous names lead to sad surprises.
• Prefer short lived credentials with assume role entries rather than scattering long lived keys everywhere.
• Double check the file locations if things stop working, ~/.aws/credentials and ~/.aws/config are your two holy grails.
• Use the --profile flag in scripts to avoid surprise environment bleed from a developer terminal.

Follow these steps and your multi account workflow will be less painful and less likely to cause an epileptic reaction in your CI system. Now go forth and configure responsibly. If you break something blame your past self and then fix it with a new tidy profile.