Secrets Manager & Parameter Store

## Two stores, one decision AWS ships two general-purpose places to keep configuration and credentials: **AWS Secrets Manager** and **AWS Systems Manager Parameter Store** (usually just "SSM Parameter Store"). They overlap heavily, which is exactly why the choice is an interview staple. Both are regional, both are fronted by IAM, both can encrypt a value with a KMS key, and both are read at runtime through an API call rather than being baked into an image. So the useful framing is not "which one is for secrets". It is: *what does Secrets Manager add on top of a key/value store, and is this particular value worth paying for it?* ## What Secrets Manager adds **Managed rotation.** A secret can carry a rotation schedule (`RotationRules`) and a rotation Lambda function. Secrets Manager invokes that function on schedule, and for common targets — RDS, Aurora, DocumentDB, Redshift — AWS supplies the rotation logic so you configure rather than write it. Parameter Store has no rotation concept at all; you would build the scheduler, the new-credential handoff and the rollback yourself. **A resource-based policy on the value itself.** You can attach a policy to a secret that names a principal in another account, which together with an allow in that account's role makes a cross-account read work. Parameter Store parameters do not carry their own resource policy, so cross-account access is normally done the long way round: the consumer assumes a role in the owning account and reads from there. One caveat that catches people: a cross-account secret must be encrypted with a **customer managed** KMS key, because the key policy of an AWS-managed key cannot be edited to allow the foreign principal. **Cross-Region replication.** Secrets Manager can maintain read replicas of a secret in other Regions and keep them in sync, which matters for multi-Region active/active services and for disaster recovery. In Parameter Store you copy values yourself. **A recovery window on delete.** Deleting a secret schedules it for deletion 7–30 days out (default 30) unless you pass `ForceDeleteWithoutRecovery`. That has saved more than one production outage. A deleted parameter is simply gone. ## What Parameter Store gives you **Price.** Standard-tier parameters and standard throughput carry no charge. That single fact decides most real estates: a service with dozens or hundreds of settings does not want a per-item monthly bill. **Hierarchies.** Parameter names are paths — `/myapp/prod/db/host` — and `GetParametersByPath` fetches a whole subtree in one call, recursively if you ask. That maps naturally onto per-environment configuration, and it makes IAM easy: a policy on `arn:aws:ssm:...:parameter/myapp/prod/*` scopes a role to one environment. **Three types.** `String` and `StringList` are stored in the clear; `SecureString` is encrypted with a KMS key, and reading the plaintext requires `WithDecryption` plus `kms:Decrypt` on that key. So Parameter Store can hold secrets perfectly well — it just will not rotate them for you. **Tiers.** Standard tier: values up to 4 KB and a five-figure cap on parameters per account per Region, free. Advanced tier: values up to 8 KB, a much higher cap, parameter policies (expiration and notification), and a per-parameter monthly charge. The tier is per parameter, so you can keep almost everything standard and promote the few oversized ones. ## The traps **Throughput.** Parameter Store's default steady-state request rate is low — 40 transactions per second across the account/Region at the time of writing — and shared by everything. A fleet of containers that reads its config on every request will throttle. Higher throughput is an opt-in, paid service setting; caching in the process is the cheaper fix. ```bash aws ssm put-parameter --name /myapp/prod/db/host --type String --value db.internal aws ssm get-parameters-by-path --path /myapp/prod/ --recursive --with-decryption ``` **Size.** Neither store is a config file service. A Secrets Manager secret value tops out at 64 KB; a standard parameter at 4 KB. A large JSON blob belongs in S3 with the credentials to read it in one of these stores. **The bridge.** Parameter Store can read a Secrets Manager secret through the reserved path `/aws/reference/secretsmanager/<secret-name>`, so code that already speaks one API can consume the other. Useful when a platform (an older deployment tool, for instance) only knows how to read parameters. ## How the choice usually lands Configuration — hostnames, feature flags, bucket names, tuning knobs — goes in Parameter Store as `String` under a per-environment path. Credentials that a managed rotation exists for, or that another account must read, or that must survive a Region loss, go in Secrets Manager. Everything in between is a cost call, and "it's a password, therefore Secrets Manager" is the answer that gets pushed back on: say what capability you are buying.