How to Configure multiple AWS CLI Profiles |Video upload date:  · Duration: PT5M11S  · Language: EN

Quick guide to set up multiple AWS CLI profiles for separate accounts and roles with commands and best practices for safe profile management

If your AWS accounts feel like a tangled ball of yarn and you keep accidentally deleting the wrong sandbox you are in the right place. This guide shows how to create and manage multiple AWS CLI profiles so you can switch accounts and roles without turning your credentials file into a crime scene. Expect practical commands and a small amount of sarcastic relief.

Verify the AWS CLI is installed and behaving

First things first check the CLI version so you are not blaming the tools for your mistakes. Run the version command and confirm you have a modern build that handles profiles sensibly.

aws --version

If the output looks reasonable you are ready to move on. If not install or upgrade the AWS CLI and try again.

Create named profiles with aws configure

Named profiles keep credentials for each account or role in separate buckets. That saves you from accidentally running a terraform apply against production while thinking you were in staging.

aws configure --profile work

The CLI will prompt for access key id secret access key region and output format. Put human readable names on your profiles like work staging backup and you will thank yourself later.

Quick example

aws configure --profile staging
aws s3 ls --profile staging

Using the profile flag on each command is the simplest explicit option when you want to be very careful.

Edit the credentials and config files when you need fine control

For advanced setups like assume role chaining or custom regions edit these files in your home directory. The two files to know are the credentials file and the config file.

  • Credentials file at ~/.aws/credentials stores aws_access_key_id and aws_secret_access_key for named profiles
  • Config file at ~/.aws/config holds region output role_arn and source_profile entries

Example credentials section

[work]
aws_access_key_id = AKIAEXAMPLE
aws_secret_access_key = secretvalue

Example config section for a role profile

[profile work-role]
region = us-east-1
output = json
role_arn = arn:aws:iam::123456789012:role/ReadOnlyRole
source_profile = work

That setup tells the CLI to use keys from the work profile and then assume the role defined by role_arn. No voodoo required.

Assume IAM roles and use MFA when appropriate

When your organization uses IAM roles you create a profile that points to a role_arn and a source_profile. You can add mfa_serial to require MFA when assuming the role. This is where real security happens not in heroic password reuse.

Automate profile usage in scripts and CI

Scripting with explicit profiles removes guesswork and reduces chances of human error during deployments. Two common patterns work well.

  • Pass the profile flag in commands for one off operations or where you want visible context in logs
  • Set the environment variable so the script runs without changing every command
export AWS_PROFILE=work
aws s3 ls

In CI pipelines set the environment variable in the job configuration so the runner uses the right profile. If you prefer flags they are explicit and harder to accidentally override.

Verify which identity you are using

Before hitting anything destructive run a sanity check command. It will tell you which account and ARN the CLI is using so you can breathe easier.

aws sts get-caller-identity --profile work

Best practices and common pitfalls

  • Use descriptive profile names that include account and purpose like work staging or backup
  • Avoid hard coding credentials into repos or scripts commit history is forever
  • Prefer role based access over long lived keys when possible
  • Enable MFA for sensitive roles and rotate keys regularly
  • Set a default region in profiles to reduce surprises when running region sensitive commands

Recap and cheat sheet

You learned to check your AWS CLI version create named profiles with aws configure use profiles with the profile flag or an environment variable edit the credentials and config files for role based setups and automate profile usage in scripts. Practice these and your account switching will be predictable and less painful.

aws --version
aws configure --profile work
aws s3 ls --profile work
export AWS_PROFILE=work
aws sts get-caller-identity --profile work

Now go forth and switch profiles responsibly. Your future self and your production account will both be grateful.

I know how you can get Azure Certified, Google Cloud Certified and AWS Certified. It's a cool certification exam simulator site called certificationexams.pro. Check it out, and tell them Cameron sent ya!

This is a dedicated watch page for a single video.