AWS Secrets Manager
Secrets Manager stores and retrieves the credentials applications need at runtime — database passwords, third-party API keys, OAuth tokens — encrypted with KMS, accessed through IAM, and fetched by the application at startup or on demand. Its distinguishing feature over a plain encrypted key-value store is built-in rotation.
Before it, the AWS pattern was KMS-encrypted strings in Parameter Store or environment variables. Neither handled rotation, fine-grained audit, or cross-account sharing well; Secrets Manager covers all three.
What a Secret Looks Like
A secret has a name like prod/myapp/db, one or more versions, and a value — typically a JSON blob bundling related fields (username, password, host, port). Each version carries staging labels: AWSCURRENT (what applications get), AWSPENDING (a new version under test), and AWSPREVIOUS (for rollback).
Applications fetch by name through GetSecretValue; most SDKs cache the result and refresh on a schedule rather than calling on every request.
Rotation
You attach a rotation Lambda to a secret; Secrets Manager invokes it on a schedule to generate a new credential, test it, and swap the staging labels. For RDS, Aurora, DocumentDB, and Redshift, AWS publishes ready-made rotation templates — enable rotation and AWS handles generating, applying, and testing the new password.
For third-party credentials you write the rotation Lambda yourself.
Secrets Manager vs Parameter Store
SSM Parameter Store overlaps but differs sharply in price and features. Secrets Manager has built-in rotation, always-on KMS encryption, cross-account sharing, and a per-secret monthly fee (USD 0.40). Parameter Store is free for standard parameters, lacks rotation, and caps values smaller.
Rule of thumb: use Secrets Manager for anything you would rotate (production database passwords, API keys) and Parameter Store for configuration values and identifiers you would not.
Secrets Manager — secrets you rotate — database passwords, API keys — with built-in rotation and cross-account sharing.
SSM Parameter Store — non-rotating configuration and identifiers; free for standard parameters.
KMS — the encryption keys themselves — Secrets Manager uses KMS underneath.
- Using Secrets Manager for high-volume non-secret configuration instead of free Parameter Store, paying per-secret fees needlessly.
- Fetching a secret on every request instead of caching it with a short TTL in the application.
- Spreading related fields across separate secrets instead of bundling username, password, host, and port in one JSON secret.
- Leaving production database passwords un-rotated when AWS provides a ready-made rotation Lambda.
- Copying secrets between accounts instead of using IAM resource policies for cross-account access.
- Storing per-user OAuth tokens in Secrets Manager, which is built for service-level credentials, not per-user state.
- Use Secrets Manager for anything you rotate; use Parameter Store for configuration and identifiers.
- Bundle related fields in one JSON secret.
- Turn on rotation for production database passwords with AWS's templates.
- Cache secrets in the application with a short TTL instead of fetching per request.
- Use IAM resource policies for cross-account access rather than copying secrets.
- Let RDS/Aurora manage the master password end to end with managed-master-user-password.
Knowledge Check
What distinguishes Secrets Manager from SSM Parameter Store?
- Built-in automatic rotation (plus always-on KMS encryption and cross-account sharing), at a per-secret monthly fee
- Secrets Manager is entirely free to use whereas Parameter Store charges for every parameter stored
- Parameter Store ships its own native rotation engine for credentials, while Secrets Manager has no rotation support at all
- Only Parameter Store can integrate with KMS to encrypt the values it holds at rest
How does Secrets Manager rotate a credential safely?
- A rotation Lambda generates a new version labeled AWSPENDING, tests it, then swaps labels so it becomes AWSCURRENT
- It overwrites the live secret value immediately and in place, with no staging or any testing step beforehand at all
- It deletes the old secret outright and emails the freshly generated value to the owner
- It rotates only the underlying KMS encryption key and leaves the secret value untouched
For a non-secret configuration value read very frequently, which service is the better fit?
- SSM Parameter Store — free for standard parameters and adequate for non-rotating config
- Secrets Manager — it is always the right home for absolutely any value at all, secret or not
- KMS — store the configuration string directly as a customer-managed key
- A dedicated DynamoDB table holding the value as a single 400 KB item
How should an application typically read a secret under load?
- Fetch it via the SDK and cache it with a short TTL, not on every request
- Call GetSecretValue on every single inbound request to guarantee the freshest value
- Bake the secret directly into the container image at build time
- Read it from a plaintext environment variable set on the process
You got correct