Secrets Manager vs Parameter Store: Where Should Each Value Live?

Both services store configuration values and secrets encrypted with KMS, retrievable via the same AWS SDKs. The exam distinction comes down to three things: automatic rotation, cost model, and purpose-built secret features.

Parameter Store — the config workhorse

• Free standard tier: config values, feature flags, AMI IDs, plain strings
• SecureString tier encrypts with your KMS key — good enough for many secrets
• Hierarchical paths (/prod/db/host) with IAM-controlled access per path
• No built-in rotation — you'd wire EventBridge + Lambda yourself
• Advanced tier ($) raises the 4KB limit to 8KB and adds parameter policies

Secrets Manager — secrets with lifecycle

The rule of thumb: rotating credentials for AWS databases → Secrets Manager, no contest. Plain configuration and non-rotating values → Parameter Store's free tier. SecureString covers the middle ground when you need encryption but not rotation.

• Automatic rotation built in for RDS/Redshift/DocumentDB — Lambda-based for others
• Random secret generation, cross-account access to secrets, and fine-grained resource policies
• $0.40 per secret per month + API calls — priced for real secrets, not config sprawl
• Version staging labels (AWSCURRENT/AWSPREVIOUS) let apps roll through rotations safely

Decision shortcuts

• 'Automatically rotate RDS credentials' → Secrets Manager (Parameter Store can't)
• 'Store non-secret config cheaply' → Parameter Store
• 'Encrypted value, no rotation needed, cost-sensitive' → Parameter Store SecureString
• 'Share a secret across AWS accounts' → Secrets Manager resource policy
• 'Lambda needs a secret at runtime' → either works via SDK; rotation need decides