Create or import the secret in Secrets Manager, choosing the secret type that matches your resource (e.g., RDS credentials)
Create a Lambda rotation function using the AWS-provided rotation function template for your database engine, or author one implementing the four lifecycle steps: createSecret, setSecret, testSecret, and finishSecret
Grant the Lambda execution role permissions to call secretsmanager:GetSecretValue, secretsmanager:PutSecretValue, secretsmanager:UpdateSecretVersionStage, and secretsmanager:DescribeSecret on the target secret
Configure the secret's rotation schedule in the console or via CLI, specifying the rotation interval and the Lambda function ARN; Secrets Manager will invoke the function on schedule
In your application, always retrieve credentials by calling GetSecretValue at connection time (with a short in-process cache); do not bake credentials into environment variables or config files
Test the rotation manually by calling rotate-secret via the CLI and verifying your application can still connect after the rotation completes
Known gotchas
During rotation, Secrets Manager maintains two active versions (AWSPENDING and AWSCURRENT); applications that cache credentials aggressively may briefly use a stale password
If the Lambda function does not have network access to both Secrets Manager and the target database (e.g., missing VPC endpoint or security group rule), rotation will fail silently and the secret will remain unrotated
The Lambda must handle the case where the secret is already in the AWSPENDING stage (a previous rotation attempt that did not finish) without creating a third version
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp