AWS Access Keys Explained: Risks, Rotation, and Safer Alternatives

Simple explanation

The access key ID is a 20-character string starting with AKIA (for permanent keys) or ASIA (for temporary credentials from STS). The secret access key is a 40-character string that AWS shows you exactly once, at creation time. If you lose the secret, there is no way to recover it. You must delete the key and create a new one.

How access keys work

When you run an AWS CLI command or make an SDK call, the tool uses your secret access key to compute an HMAC-SHA256 signature over the request details: the action, timestamp, headers, and payload. This signature is sent along with your access key ID in the request headers. AWS looks up the secret associated with your key ID, computes the same signature, and compares the two. If they match, the request is authenticated.

The secret access key never travels over the network after creation. Every API call uses it locally to sign requests, and AWS verifies the signature on its end. This is why losing the secret means it is gone forever.

Access keys can belong to two types of identities:

• IAM users (the common case). Each IAM user can have up to two access keys.
• The root user (the account owner). Root keys exist but should never be created. They have unrestricted access to everything in the account and cannot be scoped down with policies.

When to use access keys

Access keys are appropriate when your code runs outside of AWS and cannot use an IAM role:

• Local development. Running CLI commands or scripts on your laptop where no instance profile or execution role is available. Even here, IAM Identity Center is often better if your organization supports it.
• On-premises servers. Applications on physical servers or non-AWS virtual machines that need to call AWS APIs. Consider IAM Roles Anywhere as a newer alternative that provides temporary credentials to on-prem workloads.
• Legacy integrations. Older tools or third-party services that only support static credentials and cannot use OIDC federation or role assumption.
• Terraform or IaC running locally. Infrastructure-as-code tools on a developer machine, though named profiles with Identity Center are preferable when available.

When not to use access keys

If your workload runs inside AWS, there is almost always a role-based alternative that eliminates the need for long-lived keys. Embedding access keys in AWS-hosted applications adds risk with no benefit. For the full picture on why, see why long-lived access keys are dangerous.

• EC2 instances. Use an IAM role attached through an instance profile. The SDK picks up temporary credentials automatically from the instance metadata service.
• Lambda functions. Use an execution role. Lambda populates temporary credentials in the function’s environment automatically. There is no reason to embed access keys in Lambda code or environment variables.
• ECS and Fargate tasks. Use a task role. The ECS agent provides temporary credentials to each container.
• EKS pods. Use IAM Roles for Service Accounts (IRSA) or EKS Pod Identity to bind an IAM role to a Kubernetes service account.
• GitHub Actions and CI/CD. Use OIDC federation to assume an IAM role directly, with no stored secrets. GitHub, GitLab, and most CI providers support this natively.
• Cross-account access. Use role assumption instead of sharing access keys between accounts.

Access keys vs IAM roles vs IAM Identity Center vs IAM Roles Anywhere

Choosing the right credential type depends on where your code runs and what your organization supports.

Creating access keys

Access keys are created for IAM users. You must have an IAM user before you can create one. You can do this through the IAM console, the CLI, or the API. For more on managing IAM resources from the command line, see managing IAM with the AWS CLI.

Via the AWS CLI

aws iam create-access-key --user-name alice

The response includes both the access key ID and the secret:

{
  "AccessKey": {
    "UserName": "alice",
    "AccessKeyId": "AKIAIOSFODNN7EXAMPLE",
    "Status": "Active",
    "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "CreateDate": "2026-03-15T10:00:00Z"
  }
}

Via the console

In the IAM console, navigate to Users, select the user, choose the Security credentials tab, and click Create access key. The console shows the secret key once. Download the CSV or copy both values before closing.

Configuring the AWS CLI

The most common use case for access keys is configuring the AWS CLI on a local machine. The aws configure command prompts for the key and stores it in ~/.aws/credentials:

aws configure
# AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
# AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
# Default region name [None]: us-east-1
# Default output format [None]: json

This writes two files:

# ~/.aws/credentials
[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

# ~/.aws/config
[default]
region = us-east-1
output = json

Named profiles

If you work with multiple AWS accounts, use named profiles to keep credentials separate:

aws configure --profile staging
aws configure --profile production

Then target a specific account by passing the profile name:

aws s3 ls --profile production

You can also set the AWS_PROFILE environment variable to avoid passing —profile on every command:

export AWS_PROFILE=production
aws s3 ls

Environment variables

The CLI also reads credentials from environment variables, which override the credentials file:

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
export AWS_DEFAULT_REGION=us-east-1

Managing access keys

List access keys

aws iam list-access-keys --user-name alice

This shows key IDs, status, and creation date, but never the secret. Use the IAM credential report to audit key age and last usage across all users:

aws iam generate-credential-report
aws iam get-credential-report --output text --query Content | base64 --decode

Deactivate a key

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

Deactivating prevents a key from being used without deleting it permanently. This is useful when you suspect a key may be compromised but need time to investigate.

Delete a key

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

How to rotate access keys safely

Because each IAM user can have two active access keys at a time, you can rotate without downtime. Follow this sequence:

1. Create a new access key for the user while the old one is still active.
2. Update all applications and scripts to use the new key.
3. Verify the new key works by confirming successful API calls.
4. Deactivate the old key. Do not delete it yet.
5. Wait 24 to 48 hours to confirm nothing still relies on the old key.
6. Delete the old key once you are confident it is no longer in use.

What to do if an access key is exposed

If you discover that an access key has been committed to a public repository, posted in a message, or otherwise leaked, act immediately:

1. Deactivate the key. Run aws iam update-access-key —status Inactive or use the console. Do this first, before anything else.
2. Check CloudTrail. Review CloudTrail logs for unauthorized API calls made with the compromised key. Filter by access key ID to see exactly what was done.
3. Assess the damage. Look at what resources the key had access to. Check for new IAM users, modified policies, launched instances, or unexpected data access. The guide on detecting suspicious activity covers what to look for.
4. Create a replacement key if the application still needs one, and update all references.
5. Delete the compromised key once all applications are updated.
6. Remove the leaked copy. If the key was committed to Git, rewriting history may be necessary. If it was posted publicly, assume it has been scraped and act accordingly.