Keep permissions aligned for alternating Secrets Manager database users

Alternating credentials introduce a second database user whose permissions need an explicit maintenance owner.

Paired infrastructure paths converging on a stable recovered service.
DSE visual intelligenceContinuity & recoveryGuide · 2 min read
Executive summary

What you need to know

Alternating credentials introduce a second database user whose permissions need an explicit maintenance owner.

Potentially affected

This concerns documented Lambda database-rotation strategies. It does not establish that a particular database permission model is suitable, or that every application avoids authentication failures during rotation.

DSE recommendation

DSE recommends reviewing the database’s ownership and permission model before selecting alternating users.

Alternating credentials introduce a second database user whose permissions need an explicit maintenance owner.

Source facts

For Lambda-based database rotation, Secrets Manager supports single-user and alternating-user strategies. The alternating strategy creates a clone and switches which user’s password is updated. It needs privileged credentials in a separate secret. AWS states that later permission changes to the original user must also be made to the clone. AWS recommends single-user rotation where cloned users do not have equivalent permissions.

Source: AWS — Lambda function rotation strategies.

Applicability

This concerns documented Lambda database-rotation strategies. It does not establish that a particular database permission model is suitable, or that every application avoids authentication failures during rotation.

DSE recommendation

DSE recommends reviewing the database’s ownership and permission model before selecting alternating users. Put both user identities in the access review and link permission changes to both when that strategy is used. Identify the owner of the privileged rotation secret and keep application permissions separate from rotation permissions. Plan retry and recovery behavior with the application owner rather than assuming the rotation strategy eliminates every interruption. Keep the clone identity in the database permission-change checklist after the first rotation. Require the owner to explain how a later grant or revocation will be applied and verified for both users before selecting this strategy for a long-lived application.

Verification

Proposed verification: in a permitted test database, inspect both users’ effective privileges and run representative allowed and denied operations after rotation. Apply an approved permission change and confirm the intended alignment. Retain identity names and outcomes, with no passwords or secret values in the evidence record.

Official reference

AWS — Lambda function rotation strategies. Reviewed October 20, 2026.

Primary reference

Review the official source

AWS — Lambda function rotation strategies · Verified October 20, 2026

Open official reference ↗
Plan the next step

Need help applying this guidance safely?

DSE can help confirm applicability, protect service continuity, and validate the result across physical security and IT systems.

Talk with DSE