Access Keys & Rotation

An access key is a long-lived credential that lets code talk to AWS without a password. It is the machine equivalent of a username and password: a public part (the access key ID) and a secret part (the secret access key). Scripts, the AWS CLI (Command Line Interface), and SDKs (Software Development Kits) use these keys to sign every API call. They are powerful and convenient — and because they never expire on their own, they are also the single most common way AWS credentials get leaked. This page explains what access keys are, when you actually need them, how to rotate them safely, and how to avoid the mistakes that end up in security headlines.

What an access key is

An access key has two parts that always go together:

• Access key ID — looks like AKIA0A1B2C3D4E5F6G7H. This part is not secret; it identifies which key is being used and shows up in logs.
• Secret access key — looks like wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY. This is the password half. AWS shows it to you exactly once, at creation time, and never again.

Together they let any caller sign requests as the IAM user (Identity and Access Management user) the key belongs to. There is no expiry built in — a key keeps working until you deactivate or delete it. That permanence is exactly why a leaked key is so dangerous: an attacker who finds it can use it for months until someone notices.

Each IAM user can have at most two access keys at a time. That limit is not arbitrary — it exists specifically so you can rotate keys without downtime, which we cover below.

When to use access keys — and when NOT to

This is the part most tutorials skip. In 2026, access keys are not the default way to authenticate. They are the fallback for when nothing better fits.

Approach	Use it for	Avoid it for
IAM role	Anything running on AWS — EC2 instances, Lambda functions, containers (ECS/EKS)	External systems that can’t assume a role
IAM Identity Center (SSO)	Humans running the CLI/SDK on their laptops	Machine-to-machine automation
Access keys	An on-premises server, a CI runner that can’t use OIDC, a legacy script in a non-AWS environment	Workloads on AWS, human console users

The rule of thumb:

• If the code runs on AWS, use an IAM role via an instance profile or execution role. AWS hands the code short-lived, auto-rotating credentials — there is no key to store or leak.
• If a human runs the CLI, use IAM Identity Center (aws sso login). It gives temporary credentials that expire in hours.
• Only create an access key when neither fits, such as an on-premises server or a third-party tool that can only authenticate with static keys.

The number one breach cause. Long-lived access keys committed to Git, baked into a Docker image, or pasted into a CI config are the most common source of AWS account compromises. Every key you create is a key that can leak. If you can use a role or SSO instead, do — there is then no long-lived secret to lose.

Creating an access key

Only do this if a role truly will not work.

Console steps

1. Open the IAM console at https://console.aws.amazon.com/iam/.
2. Choose Users, then click the user’s name.
3. Open the Security credentials tab and scroll to Access keys.
4. Choose Create access key, pick the use case (for example Command Line Interface (CLI)), acknowledge the recommendation to use alternatives, and choose Next.
5. Choose Create access key, then Download .csv file. This is the only time the secret is shown.

CLI command

aws iam create-access-key --user-name ci-deploy-bot

Output:

{
    "AccessKey": {
        "UserName": "ci-deploy-bot",
        "AccessKeyId": "AKIA0A1B2C3D4E5F6G7H",
        "Status": "Active",
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "CreateDate": "2026-06-15T10:43:02+00:00"
    }
}

Save the secret immediately. The SecretAccessKey appears only at creation. Store it in a secrets manager (such as AWS Secrets Manager) or your CI’s encrypted variables — never in a plaintext file in a repo. If you lose it, delete the key and make a new one.

The two-key rotation procedure

Rotation means replacing a key with a fresh one on a schedule, so that even if an old key has quietly leaked, it stops working. Because a user can hold two keys at once, you can rotate with zero downtime. The order matters: create the new key first, switch over, then remove the old one.

Step 1 — Create a second key. The user now has two active keys.

aws iam create-access-key --user-name ci-deploy-bot

Step 2 — Update every app, script, and CI secret to use the new key ID and secret. Deploy and confirm everything still works with the new key.

Step 3 — Deactivate the old key (do not delete yet). Deactivating keeps it around so you can re-enable it instantly if something was missed.

aws iam update-access-key \
  --user-name ci-deploy-bot \
  --access-key-id AKIAOLDKEY1234567890 \
  --status Inactive

Step 4 — Verify nothing broke. Check when the old key was last used:

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

Output:

{
    "UserName": "ci-deploy-bot",
    "AccessKeyLastUsed": {
        "LastUsedDate": "2026-06-15T09:01:44+00:00",
        "ServiceName": "s3",
        "Region": "us-east-1"
    }
}

If the LastUsedDate stops advancing after you deactivate it, nothing depends on the old key anymore.

Step 5 — Delete the old key once you are confident.

aws iam delete-access-key \
  --user-name ci-deploy-bot \
  --access-key-id AKIAOLDKEY1234567890

You can list a user’s keys and their ages at any time:

aws iam list-access-keys --user-name ci-deploy-bot

Detecting and responding to a leak

If a key is exposed, treat it as an emergency: deactivate it first (instant kill switch), then delete it and rotate. AWS also helps you find stale keys — a key not used in 90 days is a prime candidate for deletion. GitHub and AWS run automated secret scanning that can quarantine an AKIA... key pushed to a public repo, but you should never rely on that catching it in time.

Cost note

Access keys and IAM itself are free — AWS does not charge for credentials. The cost of a leaked key, however, can be enormous: attackers commonly spin up expensive GPU or compute fleets for crypto mining, running up bills in the tens of thousands of dollars within hours. The safer alternatives (roles, Identity Center) are also free, so there is never a cost reason to keep risky long-lived keys.

Best Practices

• Prefer IAM roles for AWS workloads and IAM Identity Center for humans, so there are no long-lived keys to leak.
• Create access keys only when a role or SSO genuinely cannot be used.
• Rotate keys on a regular schedule using the create-new-then-remove-old procedure, never with a gap in coverage.
• Never commit keys to Git or bake them into images; store them in a secrets manager or encrypted CI variables.
• Deactivate before deleting, and use get-access-key-last-used to confirm a key is truly unused.
• Treat any exposed key as compromised: deactivate immediately, then delete and rotate.
• Require multi-factor authentication (MFA) on users that have keys, and grant each key only the permissions it needs (least privilege).

Related Topics

• IAM Users
• IAM Roles
• EC2 Instance Profiles
• IAM Identity Center
• Least Privilege