How to rotate an AWS access key without downtime

Updated 22 October 2026

An IAM user can have two access keys at a time. That is what makes zero-downtime rotation possible: create the new key, move everything over to it, and only then switch the old one off.

If the key leaked publicly, skip the zero-downtime routine. Deactivate the old key immediately (step 3), accept a short outage, then create and deploy the new one. Waiting gives an attacker time.

1. Create the new key

In the IAM console, open Users, select the user, open the Security credentials tab and choose Create access key. Or with the AWS CLI:

aws iam list-access-keys --user-name deploy-bot
aws iam create-access-key --user-name deploy-bot

If the user already has two keys, you’ll need to delete one first. Save the new secret access key somewhere safe straight away: AWS shows it only once.

2. Deploy it everywhere

Update every place the old key is used: CI/CD secrets, servers, containers, serverless functions, local AWS profiles. To confirm the old key is no longer in use, check when it was last used:

aws iam get-access-key-last-used --access-key-id AKIA...OLDKEY

Wait until the last-used time stops moving before going on.

3. Deactivate the old key

Deactivating is reversible, so do it before deleting. Anything you missed will start failing, and you can switch the key back on briefly while you fix it.

aws iam update-access-key --user-name deploy-bot --access-key-id AKIA...OLDKEY --status Inactive

4. Delete the old key

Once nothing has broken for a while (a day is common for routine rotation), delete it:

aws iam delete-access-key --user-name deploy-bot --access-key-id AKIA...OLDKEY

If the key leaked: check what it did

CloudTrail records API calls made with each access key. Look up recent activity for the leaked key:

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIA...OLDKEY \
  --max-results 50

CloudTrail event history covers the last 90 days of management events in each region, so repeat the lookup in every region you use, and in regions you don’t: attackers often start instances in regions nobody looks at. Watch for:

new IAM users, access keys, roles or policies (an attacker’s way back in after you rotate);
EC2 instances, especially large GPU instances, in any region;
new Lambda functions, or changes to existing ones;
S3 bucket policy changes and large downloads.

Also check Billing for unexpected charges. AWS may already have emailed you and restricted the key if it found it on a public site such as GitHub. Follow the steps in that email too.

If you find anything you didn’t create, contact AWS Support. They can help you investigate and may review charges caused by the compromise.

Better than rotating: no long-lived keys

Access keys that never change are easy to leak and hard to track. Where you can, replace them with short-lived credentials:

IAM roles for EC2, ECS and Lambda: the SDK picks up temporary credentials automatically.
OIDC federation for CI: GitHub Actions and GitLab can assume an IAM role without storing any key.
IAM Identity Center for people: short-lived credentials on the command line via aws sso login.

And before you paste an AWS error into a chat or an issue, redact it. Access key IDs often appear in error messages and debug output.