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.
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.
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.
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.
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.
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.
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.
Scripting with explicit profiles removes guesswork and reduces chances of human error during deployments. Two common patterns work well.
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.
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
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.