Bird
Raised Fist0
AWScloud~15 mins

Using profiles for multiple accounts in AWS - Deep Dive

Choose your learning style10 modes available

Start learning this pattern below

Jump into concepts and practice - no test required

or
Recommended
Test this pattern10 questions across easy, medium, and hard to know if this pattern is strong
Overview - Using profiles for multiple accounts
What is it?
Using profiles for multiple accounts means setting up separate named configurations to access different AWS accounts or roles from the same computer. Each profile stores unique credentials and settings, so you can switch between accounts easily without mixing them up. This helps manage access securely and efficiently when working with multiple AWS environments.
Why it matters
Without profiles, you would have to constantly change your credentials manually or risk mixing up access between accounts, which can cause security risks or accidental changes in the wrong environment. Profiles make it simple and safe to work across many AWS accounts, saving time and preventing costly mistakes.
Where it fits
Before learning this, you should understand basic AWS account concepts and how to use the AWS CLI with a single account. After this, you can learn about advanced access management like roles, federation, and automation using profiles in scripts or CI/CD pipelines.
Mental Model
Core Idea
Profiles are like separate ID cards stored on your computer, each letting you enter a different AWS account without confusion.
Think of it like...
Imagine you have several keys on a keyring, each opening a different door to a house you own. Instead of carrying one master key that opens all doors (which is risky), you carry labeled keys so you always pick the right one for the door you want to open.
┌───────────────┐
│ AWS CLI Tool  │
└──────┬────────┘
       │ uses
       ▼
┌───────────────┐      ┌───────────────┐      ┌───────────────┐
│ Profile: dev  │─────▶│ AWS Account 1 │      │               │
├───────────────┤      ├───────────────┤      ├───────────────┤
│ Profile: prod │─────▶│ AWS Account 2 │      │               │
└───────────────┘      └───────────────┘      └───────────────┘
Build-Up - 6 Steps
1
FoundationWhat is an AWS profile
🤔
Concept: Introduce the idea of named profiles in AWS CLI to store different credentials and settings.
AWS CLI uses a default profile if none is specified. A profile is a named set of credentials and configuration stored in files like ~/.aws/credentials and ~/.aws/config. You can create multiple profiles to switch between accounts or roles easily.
Result
You understand that profiles are separate named configurations that let you manage multiple AWS identities on one machine.
Knowing that profiles are just named sets of credentials helps you see how AWS CLI can switch contexts without confusion.
2
FoundationHow to create and use profiles
🤔
Concept: Learn the commands and file edits needed to add and select profiles.
You create profiles by adding sections in ~/.aws/credentials and ~/.aws/config files with names like [dev] in credentials and [profile dev] in config. Then you use the AWS CLI with --profile dev to run commands under that profile. For example: [credentials file] [dev] aws_access_key_id=DEVKEY aws_secret_access_key=DEVSECRET [config file] [profile dev] region=us-west-2 Command: aws s3 ls --profile dev
Result
You can run AWS CLI commands using different profiles to access different accounts or settings.
Understanding the file structure and command flag lets you control which AWS identity you use at any time.
3
IntermediateSwitching profiles in scripts and environment
🤔Before reading on: do you think setting AWS_PROFILE environment variable or using --profile flag is better for automation? Commit to your answer.
Concept: Explore ways to switch profiles automatically in scripts or terminal sessions.
You can set the AWS_PROFILE environment variable to a profile name so all AWS CLI commands in that session use it by default. Alternatively, you can specify --profile on each command. For example: export AWS_PROFILE=prod aws ec2 describe-instances or aws ec2 describe-instances --profile prod Scripts often set AWS_PROFILE to avoid repeating --profile everywhere.
Result
You can automate profile switching, making scripts cleaner and reducing errors.
Knowing environment variables control default profiles helps you write flexible automation that adapts to different accounts.
4
IntermediateUsing profiles with roles and MFA
🤔Before reading on: do you think profiles can store temporary credentials from roles or MFA? Commit to your answer.
Concept: Profiles can be configured to assume roles or require multi-factor authentication (MFA) for added security.
In ~/.aws/config, you can define a profile that assumes a role in another account: [profile crossaccount] role_arn=arn:aws:iam::123456789012:role/RoleName source_profile=default You can also require MFA by adding mfa_serial and using aws sts get-session-token. This setup lets you switch securely between accounts with extra verification.
Result
You can use profiles to manage complex access patterns securely, including temporary credentials and MFA.
Understanding role assumption and MFA integration with profiles unlocks secure multi-account workflows.
5
AdvancedProfiles in shared and team environments
🤔Before reading on: do you think sharing profiles across users is safe or risky? Commit to your answer.
Concept: Learn best practices for managing profiles when multiple people or systems share access.
Profiles store sensitive credentials locally, so sharing them directly is risky. Instead, teams use centralized credential management, environment variables, or AWS Single Sign-On (SSO). Profiles can be templated or generated dynamically in CI/CD pipelines to avoid exposing secrets.
Result
You know how to handle profiles safely in collaborative or automated environments.
Recognizing the security risks of static profiles prevents accidental credential leaks in teams.
6
ExpertAdvanced profile chaining and credential process
🤔Before reading on: do you think profiles can execute external programs to fetch credentials? Commit to your answer.
Concept: Profiles can use the credential_process setting to run external commands that supply credentials dynamically.
In ~/.aws/config, you can add: [profile dynamic] credential_process=/path/to/script This script outputs JSON with temporary credentials. This allows integration with custom authentication systems or vaults. Profiles can chain by using source_profile and role_arn to assume roles automatically.
Result
You can integrate AWS CLI with custom or enterprise credential providers seamlessly.
Knowing about credential_process reveals how AWS CLI can fit into complex security infrastructures beyond static files.
Under the Hood
AWS CLI reads profile data from two files: ~/.aws/credentials for keys and ~/.aws/config for settings. When you specify a profile, the CLI loads its credentials and configuration, then uses them to sign API requests. For role assumption, the CLI calls AWS Security Token Service (STS) to get temporary credentials, caching them locally. Environment variables can override profiles. Credential_process runs external programs to fetch credentials dynamically.
Why designed this way?
Profiles were designed to separate credentials and configuration for flexibility and security. Using files allows easy editing and version control. Role assumption and credential_process support complex enterprise needs without changing CLI code. This modular design balances simplicity for beginners and power for experts.
┌───────────────┐
│ AWS CLI Start │
└──────┬────────┘
       │ reads
       ▼
┌───────────────┐
│ ~/.aws/config │
└──────┬────────┘
       │ reads
       ▼
┌───────────────┐
│ ~/.aws/credentials │
└──────┬────────┘
       │ loads profile
       ▼
┌───────────────┐
│ Credentials   │
│ (static or    │
│ temporary)    │
└──────┬────────┘
       │ used to sign
       ▼
┌───────────────┐
│ AWS API Calls │
└───────────────┘
Myth Busters - 4 Common Misconceptions
Quick: Does setting AWS_PROFILE override all other credential sources? Commit yes or no.
Common Belief:Setting AWS_PROFILE always guarantees the CLI uses that profile's credentials.
Tap to reveal reality
Reality:Environment variables like AWS_ACCESS_KEY_ID or explicit command flags can override profiles. Also, some SDKs prioritize environment variables over profiles.
Why it matters:Assuming AWS_PROFILE always wins can cause confusion when commands use unexpected credentials, leading to access errors or security issues.
Quick: Can you store multiple profiles in the same credentials file? Commit yes or no.
Common Belief:You must have separate files for each profile's credentials.
Tap to reveal reality
Reality:Multiple profiles are stored as separate sections in the same ~/.aws/credentials file.
Why it matters:Thinking you need multiple files complicates setup and management unnecessarily.
Quick: Does using a profile with role_arn mean your access keys are sent to AWS? Commit yes or no.
Common Belief:Role assumption sends your long-term access keys to AWS for verification.
Tap to reveal reality
Reality:Role assumption uses your keys locally to request temporary credentials from AWS STS; keys are never sent directly.
Why it matters:Misunderstanding this can cause unnecessary fear about security or misuse of roles.
Quick: Does credential_process only work on Linux? Commit yes or no.
Common Belief:credential_process is a Linux-only feature.
Tap to reveal reality
Reality:credential_process works on all platforms supported by AWS CLI, including Windows and macOS.
Why it matters:Assuming platform limits restricts use of powerful dynamic credential features.
Expert Zone
1
Profiles can cache temporary credentials from role assumption, reducing repeated STS calls and improving performance.
2
The order of precedence for credentials is complex: environment variables override profiles, which override container or instance roles.
3
Profiles can be nested by chaining source_profile and role_arn, enabling multi-account access with minimal manual switching.
When NOT to use
Avoid static profiles when working in automated environments or teams; use AWS Single Sign-On (SSO), IAM roles for EC2, or dynamic credential providers instead for better security and scalability.
Production Patterns
In production, profiles are often generated dynamically by CI/CD pipelines or credential helpers. Teams use profiles with role chaining to access multiple accounts securely. Credential_process is used to integrate with enterprise vaults or identity providers.
Connections
SSH Configurations
Profiles in AWS CLI are similar to named host entries in SSH config files.
Understanding how SSH uses named configurations to manage multiple servers helps grasp how AWS profiles manage multiple accounts.
User Identity Management
Profiles relate to managing multiple user identities securely in software systems.
Knowing identity management principles clarifies why profiles separate credentials and how they improve security.
Keyring and Password Managers
Profiles act like entries in a keyring storing different secrets for different services.
Recognizing profiles as secret containers helps appreciate the importance of secure storage and access control.
Common Pitfalls
#1Using the default profile for all accounts without separation.
Wrong approach:aws s3 ls # Always uses default profile, mixing accounts
Correct approach:aws s3 ls --profile dev # Explicitly uses dev profile for correct account
Root cause:Not understanding that default profile is a single shared identity leads to accidental cross-account actions.
#2Hardcoding credentials in scripts instead of using profiles.
Wrong approach:aws configure set aws_access_key_id ABC123 aws configure set aws_secret_access_key XYZ789 aws s3 ls
Correct approach:aws s3 ls --profile prod # Credentials managed securely in profile files
Root cause:Lack of knowledge about profiles causes insecure and inflexible credential management.
#3Editing ~/.aws/config without [profile] prefix causing profile not found errors.
Wrong approach:[prod] region=us-east-1 # Missing 'profile' keyword causes CLI to ignore this config
Correct approach:[profile prod] region=us-east-1 # Correct syntax for named profile
Root cause:Misunderstanding AWS config file syntax leads to silent failures in profile usage.
Key Takeaways
AWS profiles let you manage multiple accounts by storing separate credentials and settings under named identities.
Profiles are configured in two files: credentials for keys and config for settings, and you select them with --profile or AWS_PROFILE.
Profiles support advanced features like role assumption, MFA, and dynamic credential fetching for secure multi-account workflows.
Using profiles prevents credential mixing, reduces errors, and enables automation and team collaboration safely.
Understanding profile internals and best practices helps avoid common mistakes and unlocks powerful AWS CLI capabilities.

Practice

(1/5)
1. What is the main purpose of using AWS profiles when working with multiple accounts?
easy
A. To store different account credentials separately on the same computer
B. To speed up AWS CLI commands by caching results
C. To automatically switch regions without user input
D. To encrypt data stored in AWS S3 buckets

Solution

  1. Step 1: Understand AWS profiles

    AWS profiles allow you to save different sets of credentials and settings for multiple accounts on one computer.
  2. Step 2: Identify the purpose

    This separation helps you choose which account to use without mixing credentials.
  3. Final Answer:

    To store different account credentials separately on the same computer -> Option A
  4. Quick Check:

    Profiles separate credentials = B [OK]
Hint: Profiles separate accounts by credentials [OK]
Common Mistakes:
  • Thinking profiles speed up commands
  • Confusing profiles with region switching
  • Assuming profiles encrypt data
2. Which AWS CLI command syntax correctly uses a profile named dev-account to list S3 buckets?
easy
A. aws s3 ls dev-account --profile
B. aws --profile s3 ls dev-account
C. aws --profile dev-account s3 ls
D. aws s3 ls dev-account

Solution

  1. Step 1: Recall AWS CLI profile usage

    The correct syntax places --profile dev-account as a global option right after aws, before the service s3 ls.
  2. Step 2: Match syntax to options

    aws --profile dev-account s3 ls correctly uses the profile flag.
  3. Final Answer:

    aws --profile dev-account s3 ls -> Option C
  4. Quick Check:

    Correct flag placement = A [OK]
Hint: --profile after aws, before service [OK]
Common Mistakes:
  • Placing --profile after profile name
  • Swapping command and profile flag order
  • Omitting --profile flag
3. Given these AWS CLI commands run on the same machine:
aws --profile prod s3 ls
aws --profile dev s3 ls
What will happen if the prod profile has access to 5 buckets and dev profile has access to 2 buckets?
medium
A. Both commands fail due to profile conflict
B. The first command lists 5 buckets; the second lists 2 buckets
C. Both commands list 5 buckets only
D. Both commands list 7 buckets combined

Solution

  1. Step 1: Understand profile isolation

    Each profile uses its own credentials and permissions, so commands run under different profiles see different resources.
  2. Step 2: Apply to bucket listing

    The prod profile lists 5 buckets it can access; the dev profile lists 2 buckets it can access.
  3. Final Answer:

    The first command lists 5 buckets; the second lists 2 buckets -> Option B
  4. Quick Check:

    Profiles isolate access = D [OK]
Hint: Profiles show only their own account's buckets [OK]
Common Mistakes:
  • Assuming buckets combine across profiles
  • Expecting profile conflicts cause failure
  • Thinking both profiles show same buckets
4. You run the command aws --profile test ec2 describe-instances but get an error: Could not find credentials for profile: test. What is the most likely cause?
medium
A. The EC2 service is down in your region
B. The AWS CLI version is outdated
C. You forgot to specify the region with --region
D. The profile test is not configured in your AWS credentials file

Solution

  1. Step 1: Analyze error message

    The error says credentials for profile test are missing, meaning AWS CLI cannot find that profile in config files.
  2. Step 2: Identify cause

    This usually happens if the profile was never added or misspelled in ~/.aws/credentials or ~/.aws/config.
  3. Final Answer:

    The profile test is not configured in your AWS credentials file -> Option D
  4. Quick Check:

    Missing profile config = A [OK]
Hint: Check profile exists in credentials file [OK]
Common Mistakes:
  • Blaming AWS CLI version
  • Assuming region missing causes credential error
  • Thinking service outage causes credential error
5. You want to run an AWS CLI command that uses the prod profile but also specify the region us-west-2 without changing your default region. Which command correctly does this?
hard
A. aws --profile prod --region us-west-2 s3 ls
B. aws s3 ls --region us-west-2 --profile prod
C. aws s3 ls --profile prod region us-west-2
D. aws s3 ls prod --region us-west-2

Solution

  1. Step 1: Understand flag order and usage

    Global options like --profile and --region must be placed after aws but before the service name. Their relative order does not matter.
  2. Step 2: Check options for correctness

    Only aws --profile prod --region us-west-2 s3 ls correctly places both flags before the service.
  3. Final Answer:

    aws --profile prod --region us-west-2 s3 ls -> Option A
  4. Quick Check:

    Global flags before service = C [OK]
Hint: Global flags (--profile, --region) after aws before service [OK]
Common Mistakes:
  • Omitting --profile or --region flags
  • Placing profile name without --profile flag
  • Using incorrect flag syntax