AWS Secrets Manager rotation is a lifecycle pattern for credentials and secrets, not a checkbox that guarantees applications will survive credential changes. The system has to update the secret, update the target service, validate the new value, promote the new version, and ensure applications fetch credentials dynamically instead of caching them beyond the rotation window. The right pattern depends on whether AWS provides managed rotation for the secret type, whether a Lambda rotation function is required, and whether changing one credential causes downtime.<\/p>\n
Current AWS documentation distinguishes managed rotation from Lambda-function rotation. For Lambda templates, two common database strategies are single-user rotation and alternating-users rotation. Alternating users keeps two database users and rotates them in turn, which can improve availability because one set of credentials remains valid while the other is changed. AWS also notes that Amazon RDS Proxy does not support the alternating-users strategy.<\/p>\n
Secret rotation belongs inside AWS Security Engineering<\/a>.<\/p>\n Managed rotation reduces custom code when the secret-owning service and Secrets Manager support the integration.<\/p>\n AWS manages the rotation workflow according to the service’s documented behavior.<\/p>\n Use custom Lambda rotation only when the target or credential type requires logic that managed rotation does not provide.<\/p>\n Single-user rotation changes the password or secret for one target identity and stores the new value.<\/p>\n The pattern is straightforward but can create a brief risk window if clients continue using the old credential after the target has already changed.<\/p>\n Applications should retrieve credentials on demand or refresh them quickly enough to survive the change.<\/p>\n Alternating-users rotation maintains two database users with equivalent permissions and changes one at a time.<\/p>\n One user’s existing credential remains valid while the other is rotated.<\/p>\n This can reduce downtime for application credentials, at the cost of additional user lifecycle, permission consistency, and rotation-function complexity.<\/p>\n Lambda rotation functions implement the Secrets Manager rotation lifecycle through staged operations that create a pending secret, set it on the target, test it, and finish the version transition.<\/p>\n The function must be idempotent because retries can invoke a stage more than once.<\/p>\n Do not create new credentials repeatedly when the same rotation token already has a pending version.<\/p>\n The rotation Lambda needs permission to read and update the secret and to change the credential in the target service.<\/p>\n Give it only the permissions and network reachability required for that one rotation task.<\/p>\n Place database rotation functions in the appropriate VPC path when the database is private, and monitor networking as part of rotation health.<\/p>\n Secrets Manager supports recurring rotation schedules and current managed-rotation guidance allows schedules as frequent as every four hours in supported scenarios.<\/p>\n Shorter intervals reduce credential lifetime but create more rotation events, target changes, and operational dependence on the rotation pipeline.<\/p>\n Set the schedule according to threat model, compliance, target capability, and application refresh behavior.<\/p>\n Applications should use the secret ARN\/name and retrieve the current value rather than embedding credentials in images, environment files, or long-lived configuration.<\/p>\n Client-side caching can reduce API calls but should have a lifetime shorter than the period in which old credentials become invalid.<\/p>\n Connection pools should reconnect with the new credential when the target rejects an expired one.<\/p>\n Alert on rotation Lambda errors, target authentication failures, pending versions that never promote, access-denied events, and secrets that exceed their expected rotation age.<\/p>\nPrefer managed rotation where supported<\/h3>\n
Use single-user rotation for simpler credentials<\/h3>\n
Use alternating users for higher availability<\/h3>\n
Understand the Lambda rotation stages<\/h3>\n
Protect the rotation function<\/h3>\n
Choose schedules from risk and application behavior<\/h3>\n
Make applications consume the current secret<\/h3>\n
Monitor failed rotations<\/h3>\n