Set Up AWS Secrets Manager
Rotation included.
Overview
AWS Secrets Manager is the managed-secrets path with rotation built in. The four properties below are what justify its cost over rolling your own KMS-plus-DynamoDB story.
- Rotation included. Automated rotation per secret. Database credentials rotate without downtime when the rotation Lambda is wired correctly.
- KMS encryption. Each secret encrypted with a KMS key. Compliance posture is one CloudTrail query.
- IAM-based access. Per-secret IAM policy. Workload identity decides who reads what.
- Cross-account plus audit trail. Resource-based policies enable cross-account access; CloudTrail logs every operation.
The approach
Three habits keep Secrets Manager operationally sound: rotation is the default, IAM controls access, and the rotation policy is documented per secret.
- Rotation by default. Every new secret carries a rotation policy. Manual rotation is the exception, not the default.
- IAM-controlled access. Per-secret IAM policy attached to workload roles. Long-lived API keys do not get to read.
- Per-secret KMS key. Sensitive secrets carry their own customer-managed key. Compromise of one key does not propagate.
- Cross-account resource policies. Multi-account access uses resource-based policies, not IAM-role-chaining gymnastics.
Why this compounds
Each rotated secret shrinks the blast radius of any credential leak. The compounding works because rotation lifetimes are measured in days or hours, not the years static credentials accumulate.
- Reduced credential exposure. Rotation caps the lifetime of any leaked secret. Most leaks become non-issues by the time they would be exploited.
- Audit-ready trail. CloudTrail captures every read. SOC2 evidence is one query, not a manual reconstruction.
- Faster incident response. Compromised credential? One API call rotates the secret and the leak is closed.
- Year-one investment, year-two habit. The first integration takes a sprint to wire correctly. By the third, the rotation Lambda is templated.