How to Rotate AWS Access Keys Without Causing Downtime

Before creating a new key, find every place the old key is used. Rotating without this step leads to missed consumers that break after the old key is deactivated.

Identify the key to rotate:

# List all access keys for an IAM user
aws iam list-access-keys --user-name myuser
# Output shows: AccessKeyId, Status (Active/Inactive), CreateDate, LastUsed

# Check the last-used timestamp for the key
aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE
# Output includes: LastUsedDate, ServiceName, Region

CloudTrail: find recent API calls made with this key:

# Search CloudTrail for the access key ID used in the last 90 days
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \
  --start-time $(date -u -d '90 days ago' +%Y-%m-%dT%H:%M:%SZ) \
  --query 'Events[*].{Time:EventTime,Event:EventName,Source:EventSource,User:Username,Region:CloudTrailEvent}' \
  --output table | head -50

The CloudTrail results show which services were called and from which source: this tells you whether the key is used by EC2 instances, Lambda functions, a CI/CD pipeline, a developer's local machine, or all of the above.

Common locations to check for hardcoded keys:

# Search git history for the access key ID (run in each relevant repo)
git log --all -p | grep -F 'AKIAIOSFODNN7EXAMPLE'

# Search the local filesystem for the key ID
grep -r 'AKIAIOSFODNN7EXAMPLE' ~/.aws/ /etc/ /home/ /var/app/ 2>/dev/null

# Check CI/CD environment variables
# GitHub Actions: Settings > Secrets and variables > Actions
# Jenkins: Manage Jenkins > Credentials
# GitLab: Settings > CI/CD > Variables
# These must be updated manually after creating the new key

# Create a new access key for the user
# Note: this outputs the SecretAccessKey ONCE: capture it immediately
aws iam create-access-key --user-name myuser

Output:

{
    "AccessKey": {
        "UserName": "myuser",
        "AccessKeyId": "AKIANEWKEYEXAMPLE",
        "Status": "Active",
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYNEWKEYEXAMPLE",
        "CreateDate": "2026-06-26T10:00:00Z"
    }
}

The SecretAccessKey is shown exactly once. If you close the terminal without saving it, you must delete this key and create another.

At this point you have two active keys: the old key still works while you update consumers.

Store the new credentials securely before proceeding:

# Update your local AWS credentials profile
aws configure set aws_access_key_id AKIANEWKEYEXAMPLE --profile rotation-test
aws configure set aws_secret_access_key wJalrXUtnFEMI/K7MDENG/bPxRfiCYNEWKEYEXAMPLE --profile rotation-test

# Verify the new key works before updating any production consumers
aws sts get-caller-identity --profile rotation-test

Update each consumer identified in Step 1 to use the new key. Do not deactivate the old key until all consumers are updated and confirmed working.

Update AWS CLI credentials file:

# ~/.aws/credentials
[default]
aws_access_key_id = AKIANEWKEYEXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYNEWKEYEXAMPLE

Update EC2 instance user data or instance profile: If the key is used directly on EC2 instances, the correct long-term fix is to replace the hardcoded key with an IAM instance profile: the instance assumes an IAM role, no key required. For immediate rotation, update the key in the configuration management system (Ansible, Chef, SSM Parameter Store) that provisions the instance.

Update application secrets stores:

# AWS Secrets Manager: update an existing secret
aws secretsmanager put-secret-value \
  --secret-id myapp/aws-credentials \
  --secret-string '{"aws_access_key_id":"AKIANEWKEYEXAMPLE","aws_secret_access_key":"wJalr..."}'

# AWS Systems Manager Parameter Store
aws ssm put-parameter \
  --name /myapp/aws_access_key_id \
  --value AKIANEWKEYEXAMPLE \
  --type SecureString \
  --overwrite

Update CI/CD pipelines:

• GitHub Actions: Settings > Secrets > AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY
• GitLab CI: Settings > CI/CD > Variables
• CircleCI: Project Settings > Environment Variables
• Jenkins: Credentials manager

After updating each consumer, trigger a test run or make a test API call to verify the new key is being used correctly before moving to the next consumer.

After updating all consumers, verify the old key has stopped being used before deactivating it.

Check last-used timestamp for the old key:

aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

If LastUsedDate is not updating beyond the timestamp when you started rotation, all consumers have been migrated. Wait at least 24 hours after the last update before deactivating: some consumers (cron jobs, monthly batch processes) only run periodically.

Deactivate the old key (not delete yet: deactivation is reversible):

aws iam update-access-key \
  --user-name myuser \
  --access-key-id AKIAIOSFODNN7EXAMPLE \
  --status Inactive

Monitor for breakage for 24-48 hours. Any consumer that was missed will start failing after deactivation. Reactivating the old key (--status Active) immediately restores service while you find and update the missed consumer.

After confirming no breakage: delete the old key:

aws iam delete-access-key \
  --user-name myuser \
  --access-key-id AKIAIOSFODNN7EXAMPLE

# Verify only the new key remains
aws iam list-access-keys --user-name myuser

The long-term fix: eliminate long-lived keys entirely: For most AWS use cases, IAM roles with temporary STS credentials are the right solution instead of long-lived access keys:

• EC2 instances: IAM instance profiles (no keys needed)
• Lambda functions: Lambda execution roles (no keys needed)
• ECS/EKS: task roles and pod identity
• CI/CD: OIDC federation (GitHub Actions, GitLab CI, CircleCI all support AWS OIDC: no stored keys)

Any new system should use roles, not keys. Reserve long-lived keys for the specific cases where role-based auth is not available.