3.4.1.7. Automating Credential Rotation for Machine Identities (Secrets Manager)

3.4.1.7. Automating Credential Rotation for Machine Identities (Secrets Manager)

Machine credentials that never rotate are ticking time bombs. Secrets Manager automates rotation using Lambda functions.

Rotation architecture:

1. Secrets Manager triggers a Lambda rotation function on schedule (e.g., every 30 days)
2. Lambda creates a new credential in the target service (RDS, API, etc.)
3. Lambda updates the secret value in Secrets Manager
4. Applications retrieve the new credential on their next API call

Built-in rotation for supported services (RDS, Redshift, DocumentDB):

aws secretsmanager rotate-secret \
  --secret-id prod/database/password \
  --rotation-lambda-arn arn:aws:lambda:...:SecretsManagerRDSRotation \
  --rotation-rules '{"AutomaticallyAfterDays": 30}'

Custom rotation Lambda for other credential types must implement four steps: createSecret → setSecret → testSecret → finishSecret. Each step is invoked separately by Secrets Manager.

Multi-user rotation strategy: Alternates between two database users (appuser_1 and appuser_2). While one credential is being rotated, the other serves traffic — zero downtime during rotation.

Exam Trap: Applications must fetch secrets from Secrets Manager at runtime — not at deployment time. If your app caches the secret, it won't pick up the rotated credential and will fail after rotation. Use the Secrets Manager SDK with caching that respects TTL, or use the Secrets Manager caching library which automatically refreshes.