RDS Credential Rotation for MCP Servers

AWS-provided rotation Lambda ARNs by engine

Secrets Manager's managed rotation functions are AWS-owned Lambdas deployed into your account when you enable rotation in the console. They are also available as CDK constructs. The specific SAR (Serverless Application Repository) function depends on engine and strategy:

Each function is deployed into your VPC via AWS SAR when you enable rotation. The deployment creates a Lambda function named SecretsManager-{engine}-{strategy}-{suffix} in your account. You do not manage this Lambda's code — AWS handles updates.

Configuring rotation via CDK (recommended)

CDK's Secrets Manager constructs handle the SAR function deployment and VPC configuration in one call:

from aws_cdk import (
    aws_secretsmanager as sm,
    aws_rds as rds,
    aws_ec2 as ec2,
    Duration,
)

# Aurora PostgreSQL cluster for MCP server
db_cluster = rds.DatabaseCluster(
    self, "MCPDatabase",
    engine=rds.DatabaseClusterEngine.aurora_postgres(
        version=rds.AuroraPostgresEngineVersion.VER_15_4
    ),
    vpc=vpc,
    vpc_subnets=ec2.SubnetSelection(subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS),
)

# The cluster auto-creates a secret for the master password
# Add a separate application user secret with rotation
app_secret = sm.Secret(
    self, "MCPAppSecret",
    description="MCP server application user credentials",
    generate_secret_string=sm.SecretStringGenerator(
        secret_string_template='{"username": "mcp_app_a"}',
        generate_string_key="password",
        exclude_characters="/@\"\\",
    ),
)

# For MultiUser rotation, create a master secret first
master_secret = sm.Secret(
    self, "MCPMasterSecret",
    description="RDS admin credentials for rotation",
    secret_string_value=SecretValue.unsafe_plain_text(
        '{"username": "mcp_admin", "password": "change-me"}'
    ),
)

# Enable MultiUser rotation — CDK deploys the SAR rotation Lambda automatically
app_secret.add_rotation_schedule(
    "AppSecretRotation",
    hosted_rotation=sm.HostedRotation.postgre_sql_multi_user(
        master_secret=master_secret,
        vpc=vpc,
        vpc_subnets=ec2.SubnetSelection(subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS),
        security_groups=[rotation_lambda_sg],
    ),
    automatically_after=Duration.days(30),
)

The rotation_lambda_sg security group must have an outbound rule to the RDS security group on port 5432 (PostgreSQL). The RDS security group must have an inbound rule from the rotation Lambda security group on port 5432. Without this explicit security group wiring, the rotation Lambda's setSecret call times out.

VPC network requirements for the rotation Lambda

The rotation Lambda must be able to reach two endpoints:

1. The RDS instance/cluster — to connect and change the password. Requires network access on the database port (typically 5432 for PostgreSQL, 3306 for MySQL) from the rotation Lambda's subnet/SG to the RDS SG.
2. The Secrets Manager API — to call GetSecretValue and PutSecretValue. Requires either a VPC interface endpoint for Secrets Manager (com.amazonaws.{region}.secretsmanager) or a NAT gateway/instance with internet access.

For MCP servers that already use a VPC endpoint for Secrets Manager (to cache secrets without NAT), the rotation Lambda can share the same endpoint. No additional endpoint is needed — just ensure the rotation Lambda's subnet can reach the existing endpoint's network interface.

MultiUser rotation — how the alternating users work

MultiUser rotation maintains two database users (conventionally mcp_app_a and mcp_app_b) and alternates between them on each rotation cycle:

# Initial state
AWSCURRENT → { "username": "mcp_app_a", "password": "pw-abc123" }
AWSPREVIOUS → { "username": "mcp_app_b", "password": "pw-xyz789" }
(both users exist in the database with their respective passwords)

# Rotation cycle triggered
# createSecret: generate new password for mcp_app_b (the AWSPREVIOUS user)
AWSPENDING → { "username": "mcp_app_b", "password": "pw-new456" }

# setSecret: update mcp_app_b's password in RDS using the master secret's admin credentials
# testSecret: connect to RDS using AWSPENDING credentials (mcp_app_b / pw-new456) → verify
# finishSecret: promote AWSPENDING to AWSCURRENT

# Final state
AWSCURRENT → { "username": "mcp_app_b", "password": "pw-new456" }
AWSPREVIOUS → { "username": "mcp_app_a", "password": "pw-abc123" }
# mcp_app_a still exists in the database with its old password (still valid)

During the entire rotation window, mcp_app_a remains a valid database user with an unchanged password. Lambda functions with cached mcp_app_a credentials continue to authenticate successfully. After finishSecret, new cache fetches return mcp_app_b credentials. Old cached credentials (mcp_app_a) remain valid until the next rotation, when mcp_app_a's password is updated.

The master secret — containing admin credentials for the database — must be stored as a separate Secrets Manager secret. Its ARN must be set in the rotating secret's metadata. If the master secret's password has also rotated, verify the master secret's AWSCURRENT value can actually connect to the database before triggering application secret rotation.

Testing rotation without affecting production traffic

To verify rotation works before relying on it in production:

# 1. Trigger an immediate rotation (without waiting for the schedule)
aws secretsmanager rotate-secret \
  --secret-id "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/mcp-server/database-AbCdEf"

# 2. Monitor the rotation Lambda's CloudWatch logs in real time
aws logs tail \
  /aws/lambda/SecretsManager-RDSPostgreSQL-MultiUser-AbCdEf \
  --follow \
  --filter-pattern "ERROR"

# 3. Describe the secret to verify version stage transition
aws secretsmanager describe-secret \
  --secret-id "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/mcp-server/database-AbCdEf" \
  --query "VersionIdsToStages"
# Expected after successful rotation: {"new-version-id": ["AWSCURRENT"], "old-version-id": ["AWSPREVIOUS"]}

# 4. Verify the new credential actually works
python3 -c "
import boto3, json, psycopg2
client = boto3.client('secretsmanager', region_name='us-east-1')
resp = client.get_secret_value(SecretId='arn:...', VersionStage='AWSCURRENT')
creds = json.loads(resp['SecretString'])
conn = psycopg2.connect(host=creds['host'], user=creds['username'], password=creds['password'])
print('Connection successful')
conn.close()
"

Run these steps in a staging environment first. The most common failure mode is a rotation that Secrets Manager marks as successful but that leaves the database in an inconsistent state (e.g., the new user was created but not granted the necessary schema permissions). Always verify that the application can actually query data with the new credential, not just that the connection authenticated.

Common failures