Best Practices for Managing AWS Configuration with Multiple Sets of Credentials

There are many reasons why you might have multiple sets of AWS credentials. Perhaps you have a personal account and a work account. Maybe you’re managing AWS accounts for different clients, or you just have several IAM users in a single account. You might be working across different regions as well, which adds more confusion into the mix.

I’ve been in this situation several times. Today, I’ll describe the ways I’ve found to best manage my AWS configuration and credentials on the AWS Console and in CLI.

AWS Console Best Practices

On the console, it all comes down to password managers and query parameters. A password manager is absolutely essential in 2020. With accounts scattered across hundreds of websites, it’s nigh impossible to remember logins for all of them without reusing the same password. If you aren’t using one right now, I recommend 1Password.

With 1Password, you can store your web and CLI credentials. For best results, update the website field accordingly:

  • Put the account ID in the url to automatically log in to the appropriate account. The format is
  • Enter the region that you’re most likely to use on this account as a query parameter, e.g.:

1Password configuration for an AWS account

You can have logins for all of your accounts and for IAM users.

When I want to log in, I just open my browser, type ⌘ / to open 1Password, search for the account, and press Enter to automatically open and fill the login form.

Additionally, I have multiple bookmarks (some even for the same AWS Service) that have the appropriate region in the query parameter. I keep these organized by account/project, and it makes navigating through the AWS console much easier because I don’t have to remember which region I need to be in for the item I’m looking for.

AWS CLI Best Practices

On the command line, I take advantage of AWS Named Profiles and direnv. I recommend leaving the default blank to ensure that you’re always handling profiles correctly (for example, if you’re working on a new project and haven’t initialized direnv yet).

My credential file (~/.aws/credentials) looks like this:

aws_access_key_id =
aws_secret_access_key =

aws_access_key_id = super secret
aws_secret_access_key = super secret

aws_access_key_id = super secret
aws_secret_access_key = super secret

And my config file (~/.aws/config) looks like this:

region = us-west-1
output = json

[profile atomic]
region = us-east-2
output = json

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

Note the slight difference in syntax between the config and credential files. That’s outlined in the docs. You can reference these profiles either with a --profile flag or with the AWS_PROFILE environment variable.

Direnv automatically loads and unloads environment variables upon entering and leaving directories, so I always have the following in my direnv config:

# .envrc

export AWS_PROFILE=personal

This works for the official AWS CLI and for most other tools that can run in a bash sub-shell. However, not all command line utilities will respect this environment variable (I’m looking at you, EB CLI). For this, I use this handy export_alias function from @zimbatm:

# .envrc

export_alias() {
  local name=$1
    local alias_dir=$PWD/.direnv/aliases
    local target="$alias_dir/$name"
    mkdir -p "$alias_dir"
    PATH_add "$alias_dir"
    echo "#!/usr/bin/env bash -e" > "$target"
    echo "$@" >> "$target"
    chmod +x "$target"

export_alias eb '~/.ebcli-virtual-env/executables/eb $@ --profile personal'
export_alias awslogs '/usr/local/bin/awslogs $@ --profile personal'
export AWS_PROFILE=personal

When I run eb, it’s always running with eb --profile personal set.

With these simple principles, I’m able to easily use AWS across multiple accounts and regions on both the web and command line. Let me know in the comments if there are any tips that you have for managing your credentials!

  • For keeping cloud credentials confidential, I like to protect them using tools such as (which protects both long-term credentials and session tokens, using the operating system’s secret manager).

    • Dan Kelch Dan Kelch says:

      Thanks for the tip! I’ve often doubted the security of plain-text passwords in my home directory, but never looked into it. This looks like a perfect solution, I’ll certainly give this a try.


  • Comments are closed.