Credential Rotation

Credential Rotation means periodically replacing credentials with new values. If a credential was compromised without detection, rotation limits the attacker's window of access. It is also the discipline that keeps a leaked credential from being a permanent skeleton key: a key that rotates every 90 days is a much smaller prize than one minted in 2019 and still active.

What to Rotate and How

• IAM access keys: rotate every 90 days (CIS benchmark); use aws iam create-access-key then delete the old one
• Database passwords: Secrets Manager can rotate RDS passwords automatically on a schedule
• KMS keys: automatic rotation on a configurable schedule (90 days to 7 years, default annual; new key material, old data still decryptable)
• TLS certificates: ACM handles renewal automatically for AWS-issued certificates

The Access Key Rotation Workflow

IAM allows a maximum of two access keys per user, and that limit exists precisely to enable zero-downtime rotation. The workflow is: create the second key with aws iam create-access-key, deploy it everywhere the old key was used, verify the old key has gone quiet, deactivate the old key with aws iam update-access-key --status Inactive, wait long enough to confirm nothing broke, then delete it. The deactivation step is the safety net: an inactive key can be reactivated instantly if some forgotten batch job starts failing, while a deleted key is gone for good. Skipping straight to deletion is how rotation gets a reputation for causing outages.

Automated Rotation with Secrets Manager

For database credentials and API secrets, AWS Secrets Manager runs rotation through a Lambda function on a schedule you define, either a fixed interval or a cron expression. You can also trigger a rotation on demand:

aws secretsmanager rotate-secret --secret-id prod/db/appuser --rotation-lambda-arn arn:aws:lambda:eu-west-1:123456789012:function:my-rotation-fn --rotation-rules "ScheduleExpression=cron(0 4 ? * SUN *),Duration=2h"

The --rotation-rules structure accepts AutomaticallyAfterDays (1 to 1000) or a ScheduleExpression using cron or rate syntax, plus an optional rotation window Duration. By default the command rotates immediately as well as configuring the schedule; pass --no-rotate-immediately to only set the schedule and let the first rotation happen in the next window.

How It Goes Wrong in Practice

Two patterns account for most rotation failures. The first is rotation theater: a team runs the create-new-key step religiously but never deletes the old key, so every user permanently carries two active keys, one of which nobody remembers deploying. The attack surface doubled and the compliance dashboard still says "rotated". The second is the silently failing rotation Lambda. Secrets Manager rotation functions run inside your account, and when one cannot reach the database (missing VPC configuration, security group change, no route to the Secrets Manager endpoint from a private subnet), rotation attempts fail quietly in the background. Months later, an engineer finds the secret's last rotated date is from three quarters ago, or worse, an application breaks because a half-completed rotation left the secret and the database out of sync. Alert on rotation failures explicitly (CloudWatch alarms on the rotation function's errors) instead of assuming the schedule is being honored.

Frequently Asked Questions

How many access keys can an IAM user have?

Two at most. That is a hard IAM limit, designed so you can run the old and new key side by side during a rotation. If a user already has two keys, you must delete one before creating a replacement.

Does rotating a KMS key re-encrypt my existing data?

No. Automatic KMS key rotation generates new key material for future encryption operations, while all previous key material is retained under the same key ID so existing ciphertext remains decryptable. Nothing is re-encrypted, and applications referencing the key ARN or alias notice no change.

Is rotation still necessary if I use IAM roles instead of access keys?

Roles largely remove the need: they issue temporary credentials that expire on their own, typically within an hour to twelve hours, which is rotation built into the credential model. The rotation discipline then applies to what remains: the few unavoidable long-lived secrets such as third-party API keys, database passwords, and any legacy IAM user keys you have not yet eliminated.

How often should I rotate?

The CIS AWS Foundations Benchmark uses 90 days for IAM access keys, which is a reasonable ceiling. For secrets with automated rotation the honest answer is: as often as your tooling can handle reliably, because with Secrets Manager doing the work, a 30-day schedule costs no more effort than a yearly one.