DEV Community: Himanshu Maheshwari

AWS IAM Policies-Simple & Easy

Himanshu Maheshwari — Wed, 14 Jan 2026 13:50:39 +0000

Imagine you're running a company building, and you need to control who can access different rooms. Some employees can only view the conference room schedule, while others can book rooms, and managers can access the server room. AWS IAM Policies work exactly like this - they're the security system that controls who can do what in your AWS environment.

In this guide, I'll break down IAM policies in simple terms, so even if you're new to AWS, you'll understand how to control access to your cloud resources.

What are IAM Policies?

Think of IAM policies as permission slips in AWS. Just like a parent gives permission to a teacher to take their child on a field trip, IAM policies give permission to users or applications to access AWS resources.

The Structure of an IAM Policy

An IAM policy is like a recipe card with specific ingredients:

{
  "Version": "2012-10-17",
  "Id": "s3-account-permissions",
  "Statement": [
    {
      "Sid": "1",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::mybucket/*"
    }
  ]
}

Breaking It Down (in Simple Terms)

1. Version - Like a Date Stamp on a Document

Always use "2012-10-17" (the latest version)
Think of it as the "policy format version"
This tells AWS which rules to follow when reading your policy

2. Id (Optional) - A Nickname for Your Policy

Example: "s3-account-permissions"
Helps you identify what this policy does
Like naming a document "Sales_Team_Permissions" instead of "Document1"

3. Statement - The Actual Rules (The Important Part!)

This is where you define WHO can do WHAT
You can have multiple statements in one policy
Each statement is like a separate rule

4. Sid (Optional) - Statement ID

A label for each individual permission rule
Example: "AllowReadAccess" or "DenyDeleteOperations"
Useful when you have multiple rules and need to identify them

5. Effect - The Decision: Allow or Deny

"Allow" = Yes, you can do this ✅
"Deny" = No, you cannot do this ❌
Deny always wins if there's a conflict

6. Principal - WHO Gets the Permission

The person, role, or service getting access
Example: "arn:aws:iam::123456789012:root" (an AWS account)
Think of it as the "name on the permission slip"

7. Action - WHAT They Can Do

Specific tasks allowed/denied
Example: "s3:GetObject" (download files), "s3:PutObject" (upload files)
You can use wildcards: "s3:*" means all S3 actions

8. Resource - WHERE They Can Do It

Which AWS resources this applies to
Example: "arn:aws:s3:::mybucket/*" (all files in "mybucket")
Like saying "only in this specific room"

9. Condition (Optional) - WHEN This Applies

Extra rules like time of day, IP address, etc.
Example: Only allow access from the office IP
Adds an extra layer of security

Real-World Example: Photo Storage App

Let's say you're managing a photo storage app. You want photographers to upload and download photos, but only from your office network:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowUserToUploadPhotos",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::987654321098:user/photographer"
      },
      "Action": [
        "s3:PutObject",
        "s3:GetObject"
      ],
      "Resource": "arn:aws:s3:::customer-photos/*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "203.0.113.0/24"
        }
      }
    }
  ]
}

Translation in Plain English:

Who: The photographer user
Can do what: Upload (PutObject) and download (GetObject) photos
Where: In the customer-photos bucket
When: Only when connected from the office IP address (203.0.113.0/24)

More Policy Examples

Example 1: Read-Only Access to EC2 Instances

Scenario: You want your intern to view all EC2 instances but not make any changes.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EC2ReadOnly",
      "Effect": "Allow",
      "Action": [
        "ec2:Describe*",
        "ec2:Get*"
      ],
      "Resource": "*"
    }
  ]
}

What it means:

The intern can see (Describe and Get) all EC2 information
They cannot create, modify, or delete instances
The * wildcard means all EC2 resources

Use case: Perfect for team members who need to monitor servers but shouldn't change anything.

Example 2: Developer Access with Restrictions

Scenario: You want developers to work freely in the development environment but stay away from production.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowDevelopmentEnvironment",
      "Effect": "Allow",
      "Action": [
        "ec2:*",
        "s3:*",
        "lambda:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-west-2"
        }
      }
    },
    {
      "Sid": "DenyProductionAccess",
      "Effect": "Deny",
      "Action": "*",
      "Resource": [
        "arn:aws:s3:::production-*",
        "arn:aws:ec2:*:*:instance/i-prod*"
      ]
    }
  ]
}

What it means:

First statement: Developers can do anything with EC2, S3, and Lambda in the us-west-2 region
Second statement: But they are explicitly blocked from any production resources (buckets starting with "production-" and instances starting with "i-prod")
Deny wins, so even if allowed elsewhere, production is off-limits

Use case: Gives developers freedom to experiment while protecting critical production systems.

Example 3: Time-Based Access

Scenario: Contractors should only access resources during business hours.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "BusinessHoursOnly",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::project-files/*",
      "Condition": {
        "DateGreaterThan": {
          "aws:CurrentTime": "2024-01-01T09:00:00Z"
        },
        "DateLessThan": {
          "aws:CurrentTime": "2024-12-31T17:00:00Z"
        }
      }
    }
  ]
}

What it means:

Contractors can access project files
Only between 9 AM and 5 PM
Automatically enforced by AWS

Example 4: Multi-Factor Authentication (MFA) Required

Scenario: For sensitive operations, require MFA.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowWithMFA",
      "Effect": "Allow",
      "Action": [
        "ec2:StopInstances",
        "ec2:TerminateInstances"
      ],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": {
          "aws:MultiFactorAuthPresent": "true"
        }
      }
    }
  ]
}

What it means:

Users can stop or terminate EC2 instances
Only if they've authenticated with MFA
Prevents accidental or unauthorized shutdowns

Common IAM Policy Patterns

Pattern 1: Least Privilege Principle

Concept: Give users the minimum permissions they need to do their job.

Bad Example ❌:

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

This gives full access to everything - dangerous!

Good Example ✅:

{
  "Effect": "Allow",
  "Action": [
    "s3:GetObject",
    "s3:ListBucket"
  ],
  "Resource": [
    "arn:aws:s3:::my-bucket",
    "arn:aws:s3:::my-bucket/*"
  ]
}

This gives only read access to a specific bucket.

Pattern 2: Using Deny for Extra Security

Concept: Explicitly deny critical actions to prevent accidents.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowMostS3Actions",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::my-bucket/*"
    },
    {
      "Sid": "NeverAllowDelete",
      "Effect": "Deny",
      "Action": [
        "s3:DeleteBucket",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

What it means: Users can do most S3 operations, but deletion is always blocked.

Understanding Policy Evaluation

When you make a request to AWS, here's how it decides if you're allowed:

By default, everything is denied 🚫
Check for explicit Allow ✅
Check for explicit Deny ❌
Deny always wins 🏆

Example Decision Flow:

Request: Delete S3 object
   ↓
Is there an Allow? → Yes (s3:* is allowed)
   ↓
Is there a Deny? → Yes (s3:DeleteObject is denied)
   ↓
Result: DENIED ❌ (Deny wins)

Policy Variables for Dynamic Permissions

You can use variables to create flexible policies:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowUserToAccessTheirOwnFolder",
      "Effect": "Allow",
      "Action": "s3:*",
      "Resource": "arn:aws:s3:::shared-bucket/${aws:username}/*"
    }
  ]
}

What it means:

Each user can only access their own folder
${aws:username} automatically inserts the user's name
John can access /shared-bucket/john/*
Sarah can access /shared-bucket/sarah/*

Testing Your Policies

Use the IAM Policy Simulator

AWS provides a tool to test policies before applying them:

Go to IAM Policy Simulator
Select a user or role
Choose a service (like S3)
Select an action (like GetObject)
Click "Run Simulation"

This shows you if the action would be allowed or denied.

Common Mistakes to Avoid

Mistake 1: Using `*` Too Broadly

{
  "Effect": "Allow",
  "Action": "*",
  "Resource": "*"
}

Problem: Gives full access to everything in AWS
Solution: Be specific about actions and resources

Mistake 2: Forgetting Resource ARNs

{
  "Effect": "Allow",
  "Action": "s3:GetObject"
  // Missing "Resource" field!
}

Problem: Policy won't work without specifying resources
Solution: Always include the Resource field

Mistake 3: Not Testing Policies

Problem: Policies might not work as expected
Solution: Always test with IAM Policy Simulator before applying

Best Practices

1. Start Small, Then Expand

Begin with minimal permissions
Add more as needed
Don't start with full access

2. Use Groups for Common Permissions

Create groups like "Developers", "Admins", "Readers"
Assign policies to groups
Add users to groups

3. Regular Audits

Review policies quarterly
Remove unused permissions
Update for new requirements

4. Document Your Policies

Add comments explaining why policies exist
Use descriptive Sid values
Keep a change log

5. Use Managed Policies When Possible

AWS provides pre-built policies
Examples: ReadOnlyAccess, PowerUserAccess
Easier to maintain

Quick Reference

Policy Template

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DescriptiveName",
      "Effect": "Allow|Deny",
      "Principal": { "AWS": "arn:..." },
      "Action": ["service:Action"],
      "Resource": "arn:...",
      "Condition": { ... }
    }
  ]
}

Common Actions

S3: s3:GetObject, s3:PutObject, s3:DeleteObject, s3:ListBucket
EC2: ec2:RunInstances, ec2:StopInstances, ec2:DescribeInstances
Lambda: lambda:InvokeFunction, lambda:CreateFunction, lambda:UpdateFunctionCode
IAM: iam:CreateUser, iam:AttachUserPolicy, iam:GetUser

Conclusion

IAM policies are the foundation of AWS security. By understanding how to structure and apply them, you can:

✅ Control who accesses your resources

✅ Specify exactly what actions are allowed

✅ Add conditions for extra security

✅ Follow the principle of least privilege

✅ Keep your AWS environment secure

Key Takeaways:

Version: Always use "2012-10-17"
Effect: Allow or Deny
Principal: Who gets access
Action: What they can do
Resource: Where they can do it
Condition: When it applies
Deny always wins in conflicts

Remember: Good IAM policies are specific, tested, and regularly reviewed. Start with minimal permissions and add more only when needed.

Additional Resources

Pro Tip: Always test your policies in a non-production environment first. Use the IAM Policy Simulator to verify they work as expected before applying them to real users!

Stay secure! 🔒

Managing Multiple AWS Accounts Like a Pro: A Complete Guide

Himanshu Maheshwari — Tue, 13 Jan 2026 14:44:35 +0000

Imagine you have multiple email accounts - one for work, one personal, and maybe one for side projects. You switch between them throughout the day without any hassle. AWS accounts work the same way!

As developers, we often juggle multiple AWS accounts:

🏢 Company account for work projects
👤 Personal account for side projects
💼 Client accounts for freelance work
🧪 Separate accounts for development and production

Switching between these accounts shouldn't be complicated. In this guide, I'll show you exactly how to manage multiple AWS accounts on a single machine, making it as easy as switching browser tabs.

Why Multiple AWS Accounts?

Before we dive in, let's understand why you might need multiple accounts:

Separation of Concerns

Keep work and personal projects separate
Avoid accidental changes to the wrong environment
Separate billing for different projects

Security & Isolation

Limit the blast radius if credentials are compromised
Different security requirements for different projects
Client data stays in client accounts

Cost Management

Track costs per project or client
Separate billing for better accounting
Avoid surprise bills mixing personal and work usage

The AWS Credentials Setup

Understanding the File Structure

AWS stores your credentials in two files on your computer:

~/.aws/credentials - Contains your access keys (the passwords)
~/.aws/config - Contains configuration settings (regions, output formats)

Think of it like this:

credentials = Your passport (proves who you are)
config = Your travel preferences (where you want to go, how you want to travel)

The Credentials File

Here's what a typical ~/.aws/credentials file looks like:

[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[work-project]
aws_access_key_id = AKIAI44QH8DHBEXAMPLE
aws_secret_access_key = je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

[personal]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[client-xyz]
aws_access_key_id = AKIAI44QH8DHBEXAMPLE
aws_secret_access_key = je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

Important Security Notes:

⚠️ Never share these credentials with anyone
⚠️ Never commit them to Git or GitHub
⚠️ Rotate them regularly (every 90 days recommended)
⚠️ The keys shown above are fake examples only

The Config File

Create or edit ~/.aws/config:

[default]
region = us-east-1
output = json

[profile work-project]
region = us-west-2
output = json

[profile personal]
region = eu-west-1
output = json

[profile client-xyz]
region = ap-southeast-1
output = table

Important: In the config file, profile names need the profile prefix (except for default).

Step-by-Step: Setting Up Multiple Profiles

Step 1: Check Your Current AWS Account

Before making changes, let's see which account you're currently using:

aws sts get-caller-identity

This command shows you:

{
  "UserId": "AIDAI23HXD2WQ4EXAMPLE",
  "Account": "123456789012",
  "Arn": "arn:aws:iam::123456789012:user/johndoe"
}

Translation:

UserId: Your unique user ID in AWS
Account: The AWS account number you're connected to
Arn: Your full AWS identity path

Step 2: Create a New Profile

Let's add a new AWS account profile:

aws configure --profile my-new-project

You'll be prompted for:

AWS Access Key ID [None]: AKIAI44QH8DHBEXAMPLE
AWS Secret Access Key [None]: je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY
Default region name [None]: us-west-2
Default output format [None]: json

Where to get these values:

Log into AWS Console
Go to IAM → Users → Your User
Click "Security credentials" tab
Click "Create access key"
Save the Access Key ID and Secret Access Key

Step 3: Verify the New Profile

Test that your new profile works:

aws sts get-caller-identity --profile my-new-project

If you see account information, you're all set! 🎉

Switching Between AWS Accounts

Now that you have multiple profiles, here are three ways to switch between them:

Method 1: Set Profile for Your Entire Terminal Session

# Switch to work-project account
export AWS_PROFILE=work-project

# Verify the switch
aws sts get-caller-identity

# All subsequent commands use work-project
aws s3 ls
aws ec2 describe-instances
aws lambda list-functions

Use case: You're working on one project for several hours.

Tip: To see which profile you're using:

echo $AWS_PROFILE

To switch back to default:

unset AWS_PROFILE

Method 2: One-Time Use for a Single Command

# Use work-project for this command only
aws s3 ls --profile work-project

# Use personal for this command only
aws s3 ls --profile personal

# Use client-xyz for this command only
aws ec2 describe-instances --profile client-xyz

Use case: You need to quickly check something in another account without switching your entire session.

Method 3: Automatic Switching Based on Folder (The Smart Way!)

This is the most convenient method for developers working on multiple projects.

Install direnv (auto-loads environment variables per folder):

# Install on macOS
brew install direnv

# Install on Linux
sudo apt-get install direnv

# Add to your shell configuration
# For zsh (~/.zshrc):
echo 'eval "$(direnv hook zsh)"' >> ~/.zshrc

# For bash (~/.bashrc):
echo 'eval "$(direnv hook bash)"' >> ~/.bashrc

# Reload your shell
source ~/.zshrc  # or source ~/.bashrc

Set up automatic profile switching:

Create a .envrc file in your project folder:

# Navigate to your work project
cd ~/projects/work-app

# Create .envrc file
cat > .envrc << 'EOF'
export AWS_PROFILE=work-project
export AWS_REGION=us-west-2
EOF

# Allow direnv to load this file
direnv allow

Now, every time you cd into this folder, it automatically uses the work-project profile!

Set it up for all your projects:

# Work project
cd ~/projects/work-app
echo "export AWS_PROFILE=work-project" > .envrc
direnv allow

# Personal project
cd ~/projects/my-blog
echo "export AWS_PROFILE=personal" > .envrc
direnv allow

# Client project
cd ~/freelance/client-xyz
echo "export AWS_PROFILE=client-xyz" > .envrc
direnv allow

How it works:

# You're using default profile
aws sts get-caller-identity
# Shows default account

cd ~/projects/work-app
# direnv automatically sets AWS_PROFILE=work-project
aws sts get-caller-identity
# Shows work account!

cd ~/projects/my-blog
# direnv automatically sets AWS_PROFILE=personal
aws sts get-caller-identity
# Shows personal account!

Visual Indicator in Your Terminal

Want to always see which AWS profile you're using? Add this to your terminal prompt!

For Zsh (~/.zshrc)

# Function to show current AWS profile
aws_profile() {
  if [ -n "$AWS_PROFILE" ]; then
    echo "☁️ [$AWS_PROFILE]"
  fi
}

# Add to your prompt
setopt PROMPT_SUBST
PS1='$(aws_profile) '$PS1

For Bash (~/.bashrc)

# Function to show current AWS profile
aws_profile() {
  if [ -n "$AWS_PROFILE" ]; then
    echo "☁️ [$AWS_PROFILE]"
  fi
}

# Add to your prompt
PS1='$(aws_profile) '$PS1

Reload your shell:

source ~/.zshrc  # or source ~/.bashrc

Your terminal will now show:

☁️ [work-project] mahesh@macbook ~/projects/work-app %

When you're not using a specific profile, the cloud icon disappears.

Managing Your Profiles

List All Configured Profiles

aws configure list-profiles

Output:

default
work-project
personal
client-xyz

View Configuration for a Specific Profile

# See all settings
aws configure list --profile work-project

# Get specific setting
aws configure get region --profile work-project
aws configure get output --profile work-project

Update a Profile Setting

# Change region
aws configure set region us-east-1 --profile work-project

# Change output format
aws configure set output table --profile personal

Test Profile Credentials

# Test if credentials work
aws sts get-caller-identity --profile work-project

# List S3 buckets to verify access
aws s3 ls --profile work-project

# Check which region is configured
aws configure get region --profile work-project

Real-World Workflow Example

Let's say you're working on three different projects in a day:

Morning: Work Project (Company Account)

cd ~/projects/company-app
# direnv automatically sets AWS_PROFILE=work-project

# Deploy to work infrastructure
aws s3 sync ./build s3://company-website-bucket
aws cloudfront create-invalidation --distribution-id E123456 --paths "/*"

# Check logs
aws logs tail /aws/lambda/company-function --follow

Afternoon: Personal Blog (Personal Account)

cd ~/projects/my-blog
# direnv automatically sets AWS_PROFILE=personal

# Deploy your blog
aws s3 sync ./public s3://my-personal-blog
aws cloudfront create-invalidation --distribution-id E789012 --paths "/*"

# Check visitor stats
aws cloudwatch get-metric-statistics --namespace AWS/S3 \
  --metric-name NumberOfObjects --dimensions Name=BucketName,Value=my-personal-blog \
  --statistics Average --start-time 2024-01-01T00:00:00Z --end-time 2024-01-31T23:59:59Z \
  --period 86400

Evening: Client Work (Client Account)

cd ~/freelance/client-xyz
# direnv automatically sets AWS_PROFILE=client-xyz

# Deploy client application
aws ecs update-service --cluster client-cluster --service client-app \
  --force-new-deployment

# Check deployment status
aws ecs describe-services --cluster client-cluster --services client-app

Notice: You never had to manually switch profiles! Each folder automatically uses the correct account.

Best Practices

1. Never Commit Credentials to Git

Always add these to your .gitignore:

# AWS Credentials
.env
.envrc
.aws/credentials
.aws/config
*.pem
*.key

# Environment files
.env.local
.env.production

2. Use Meaningful Profile Names

Bad ❌:

profile1
profile2
test
prod

Good ✅:

company-production
company-development
personal-projects
client-acme-prod
client-acme-dev
startup-staging

3. Document Profile Usage

Add to your project's README.md:

## AWS Configuration

This project uses the `work-project` AWS profile.

### Setup

1. Configure the AWS profile:

bash
aws configure --profile work-project


2. Set environment variables:

bash
export AWS_PROFILE=work-project
export AWS_REGION=us-west-2


3. Verify setup:

bash
aws sts get-caller-identity


### Required Permissions

This project requires access to:
- S3 bucket: `company-assets`
- Lambda functions: `company-api-*`
- CloudFront distribution: `E123456`

4. Create Helper Scripts

Create ~/bin/aws-switch.sh:

#!/bin/bash

echo "🌥️  AWS Profile Switcher"
echo "======================="
echo ""
echo "Available profiles:"
aws configure list-profiles | nl

echo ""
read -p "Enter profile name: " profile_name

export AWS_PROFILE=$profile_name
echo ""
echo "✅ Switched to: $AWS_PROFILE"
echo ""
aws sts get-caller-identity

Make it executable:

chmod +x ~/bin/aws-switch.sh

Use it:

~/bin/aws-switch.sh

5. Rotate Access Keys Regularly

# Create new access key (do this in AWS Console)
# Then update your credentials file

# Test new credentials
aws sts get-caller-identity --profile work-project

# If working, delete old access key in AWS Console

Set a calendar reminder to rotate keys every 90 days.

Troubleshooting Common Issues

Issue 1: "Unable to locate credentials"

Symptoms:

Unable to locate credentials. You can configure credentials by running "aws configure".

Solutions:

# Check if credentials file exists
ls -la ~/.aws/credentials

# Check if profile exists
aws configure list-profiles

# Verify profile name matches
echo $AWS_PROFILE

# Re-configure if needed
aws configure --profile work-project

Issue 2: "Access Denied" Errors

Symptoms:

An error occurred (AccessDenied) when calling the ListBuckets operation: Access Denied

Solutions:

# Verify you're using the correct profile
aws sts get-caller-identity

# Check if credentials are valid
aws sts get-caller-identity --profile work-project

# If invalid, create new access keys and update credentials file

Issue 3: Wrong Region Being Used

Symptoms:

Could not connect to the endpoint URL: "https://s3.us-west-2.amazonaws.com/my-bucket"

Solutions:

# Check current region
aws configure get region --profile work-project

# Set correct region
aws configure set region us-east-1 --profile work-project

# Or set via environment variable
export AWS_REGION=us-east-1

Issue 4: direnv Not Working

Symptoms:
.envrc file exists but profile not switching automatically

Solutions:

# Check if direnv is installed
which direnv

# Check if direnv hook is in your shell config
cat ~/.zshrc | grep direnv

# If missing, add it
echo 'eval "$(direnv hook zsh)"' >> ~/.zshrc
source ~/.zshrc

# Allow direnv in your project
cd /path/to/project
direnv allow

Advanced: Using AWS SSO (Single Sign-On)

If your company uses AWS SSO, here's how to set it up:

Configure SSO Profile

aws configure sso

Follow the prompts:

SSO start URL [None]: https://my-company.awsapps.com/start
SSO Region [None]: us-east-1
SSO registration scopes [None]: sso:account:access

Your browser will open for authentication.

Use SSO Profile

# Login to SSO
aws sso login --profile company-sso

# Use the profile
export AWS_PROFILE=company-sso
aws s3 ls

# Session expires after a few hours, re-login with:
aws sso login --profile company-sso

Auto-refresh SSO Sessions

Add to your ~/.zshrc:

# Auto-refresh AWS SSO session
aws_sso_refresh() {
  if [ -n "$AWS_PROFILE" ]; then
    aws sso login --profile $AWS_PROFILE 2>/dev/null
  fi
}

# Run before each command (optional)
# precmd() { aws_sso_refresh }

Quick Reference Cheat Sheet

# List all profiles
aws configure list-profiles

# Check current account
aws sts get-caller-identity

# Check current profile
echo $AWS_PROFILE

# Set profile for session
export AWS_PROFILE=work-project

# Unset profile (back to default)
unset AWS_PROFILE

# Use profile for single command
aws s3 ls --profile personal

# Configure new profile
aws configure --profile new-project

# Test profile credentials
aws sts get-caller-identity --profile work-project

# Get profile configuration
aws configure list --profile work-project

# Set specific configuration
aws configure set region us-east-1 --profile work-project

# Get specific configuration
aws configure get region --profile work-project

Understanding Credential Priority

AWS looks for credentials in this order:

Command line options (--profile)
Environment variables (AWS_PROFILE, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
Credentials file (~/.aws/credentials)
Config file (~/.aws/config)
IAM role (when running on EC2, ECS, Lambda)

Example:

# Even if AWS_PROFILE=personal is set
export AWS_PROFILE=personal

# This command uses work-project (command line wins)
aws s3 ls --profile work-project

Conclusion

Managing multiple AWS accounts doesn't have to be complicated. With proper setup:

✅ Switch between accounts seamlessly

✅ Automate profile selection per project

✅ See which account you're using at a glance

✅ Keep credentials secure and organized

✅ Never accidentally work in the wrong account

Key Takeaways:

Use named profiles for different AWS accounts
Use direnv for automatic profile switching per project
Add visual indicators to your terminal prompt
Never commit credentials to version control
Rotate access keys every 90 days
Document which profile each project uses
Test credentials regularly

Recommended Setup:

# 1. Install direnv
brew install direnv

# 2. Add to shell
echo 'eval "$(direnv hook zsh)"' >> ~/.zshrc

# 3. Add profile indicator to prompt
echo 'aws_profile() { [ -n "$AWS_PROFILE" ] && echo "☁️ [$AWS_PROFILE]"; }' >> ~/.zshrc
echo 'setopt PROMPT_SUBST' >> ~/.zshrc
echo 'PS1='"'"'$(aws_profile) '"'"'$PS1' >> ~/.zshrc

# 4. Reload shell
source ~/.zshrc

# 5. Set up project folders with .envrc
cd ~/projects/work-app
echo "export AWS_PROFILE=work-project" > .envrc
direnv allow

Remember: Organization leads to productivity. Spend 30 minutes setting this up, and you'll save hours of frustration and prevent costly mistakes!

Additional Resources

Pro Tip: Consider using AWS Vault for even better security - it stores your credentials in your system's encrypted keychain instead of plain text files!

Happy cloud computing! ☁️

DEV Community: Himanshu Maheshwari

AWS IAM Policies-Simple & Easy

What are IAM Policies?

The Structure of an IAM Policy

Breaking It Down (in Simple Terms)

1. Version - Like a Date Stamp on a Document

2. Id (Optional) - A Nickname for Your Policy

3. Statement - The Actual Rules (The Important Part!)

4. Sid (Optional) - Statement ID

5. Effect - The Decision: Allow or Deny

6. Principal - WHO Gets the Permission

7. Action - WHAT They Can Do

8. Resource - WHERE They Can Do It

9. Condition (Optional) - WHEN This Applies

Real-World Example: Photo Storage App

More Policy Examples

Example 1: Read-Only Access to EC2 Instances

Example 2: Developer Access with Restrictions

Example 3: Time-Based Access

Example 4: Multi-Factor Authentication (MFA) Required

Common IAM Policy Patterns

Pattern 1: Least Privilege Principle

Pattern 2: Using Deny for Extra Security

Understanding Policy Evaluation

Example Decision Flow:

Policy Variables for Dynamic Permissions

Testing Your Policies

Use the IAM Policy Simulator

Common Mistakes to Avoid

Mistake 1: Using * Too Broadly

Mistake 2: Forgetting Resource ARNs

Mistake 3: Not Testing Policies

Best Practices

1. Start Small, Then Expand

2. Use Groups for Common Permissions

3. Regular Audits

4. Document Your Policies

5. Use Managed Policies When Possible

Quick Reference

Policy Template

Common Actions

Conclusion

Key Takeaways:

Additional Resources

Managing Multiple AWS Accounts Like a Pro: A Complete Guide

Why Multiple AWS Accounts?

Separation of Concerns

Security & Isolation

Cost Management

The AWS Credentials Setup

Understanding the File Structure

The Credentials File

The Config File

Step-by-Step: Setting Up Multiple Profiles

Step 1: Check Your Current AWS Account

Step 2: Create a New Profile

Step 3: Verify the New Profile

Switching Between AWS Accounts

Method 1: Set Profile for Your Entire Terminal Session

Method 2: One-Time Use for a Single Command

Method 3: Automatic Switching Based on Folder (The Smart Way!)

Visual Indicator in Your Terminal

For Zsh (~/.zshrc)

For Bash (~/.bashrc)

Managing Your Profiles

List All Configured Profiles

View Configuration for a Specific Profile

Update a Profile Setting

Test Profile Credentials

Real-World Workflow Example

Morning: Work Project (Company Account)

Afternoon: Personal Blog (Personal Account)

Evening: Client Work (Client Account)

Best Practices

1. Never Commit Credentials to Git

2. Use Meaningful Profile Names

3. Document Profile Usage

4. Create Helper Scripts

5. Rotate Access Keys Regularly

Troubleshooting Common Issues

Mistake 1: Using `*` Too Broadly