Business Challenge
A platform team inherited a rule written by somebody sensible three years earlier: secrets go in Secrets Manager. It is good advice. The problem is what happened to the word “secret” over three years and forty microservices.
By the time anyone looked, Secrets Manager held about 1,400 entries. Perhaps 200 were credentials. The rest were feature flags, log levels, queue names, an S3 bucket name, a timeout in milliseconds, and a great many endpoint URLs — values that are neither secret nor rotated, sitting in a store that bills $0.40 per secret per month whether the value changes or not.
The same values in Parameter Store standard parameters would have cost nothing at all. Not less — nothing. That gap is worth understanding precisely, because the naive correction overshoots and creates a worse problem than the one it fixes.
Secrets Manager is $0.40 per secret per month, prorated hourly, plus $0.05 per 10,000 API calls. An advanced parameter is $0.05 per parameter per month — one eighth. A standard parameter carries no additional charge, and neither do its API calls at standard throughput.
So the interesting comparison is not Secrets Manager against Parameter Store. It is Secrets Manager against free, for every value that did not need to be there.
FixAudit by asking what rotates, not by asking what sounds sensitive. A queue name is not a secret because it lives next to one.
The premium is not storage — both services store a string, encrypted, with IAM on the front. It is managed rotation: Secrets Manager will rotate a credential on a schedule and version it as it goes, and AWS notes that you are not charged for creating new versions. Parameter Store has no equivalent. Rotating a parameter means writing and operating that machinery yourself.
For a database credential an auditor expects to see rotating every 30 days, $0.40 is cheap. For a log level, you are paying a rotation premium on something that will never rotate.
FixMake rotation the single deciding question. If the answer is no, the value does not belong in Secrets Manager.
The obvious correction is to move everything to Parameter Store and reach for the advanced tier because it has bigger limits. That upgrade is permanent. AWS is explicit that you can't change an advanced parameter to a standard parameter, and gives three reasons: it would truncate the value from 8 KB to 4 KB, it would remove any attached policies, and the two tiers use a different form of encryption.
The documented way back is to delete the parameter and recreate it as standard — which is a change to something live, coordinated with everything that reads it.
FixDefault to standard and upgrade individual parameters on evidence: a value over 4 KB, or a policy you actually need.
Parameter Store has an account-and-Region default tier setting, separate from any
individual parameter's tier, and it accepts Standard, Advanced
or Intelligent-Tiering. Set to Intelligent-Tiering, new parameters created
without an explicit tier are promoted to advanced when they need it.
That is convenient and it is also how a monthly charge appears without anyone choosing it,
on parameters that are now through the one-way door. Changing the default back to
Standard later does not help: AWS notes the default tier affects only new
parameters, and existing parameters aren't affected.
Check the default tier per account and Region with get-service-setting. Set it deliberately rather than discovering it.
Architecture
The placement rule, in one question
Most of the confusion here comes from treating this as a sensitivity question. Sensitivity
does not distinguish the two services: Parameter Store SecureString parameters
are KMS-encrypted, and both sit behind IAM. The distinguishing capability is rotation.
Does this value need to change on a schedule, without a deployment? If yes,
that is Secrets Manager, and the $0.40 is buying the thing you actually need. If no, it is a
parameter — a SecureString one if it is sensitive, a plain one if it is
not, and standard tier either way until something forces otherwise.
What pushes a parameter to advanced
Only three things should. A value larger than 4 KB, since standard tops out there. A parameter policy — expiry, or a notification when a value goes stale — which standard does not support. Or sharing across accounts, which is advanced-only.
Hitting the 10,000 parameter ceiling is a fourth, but it is worth treating as a signal rather than a limit. Ten thousand parameters in one account and Region usually means configuration that belongs in a deployment artefact has ended up in a runtime store.
Tiers are not throughput
These are two separate settings that both cost money, and conflating them produces surprising bills. AWS states it directly: parameter tiers are different from parameter throughput. Tiers control parameter storage attributes, whereas throughput controls request rate.
The billing follows that split. Standard parameters at standard throughput are free, including their API calls. Advanced parameters cost $0.05 per 10,000 API interactions. And once higher throughput is switched on, that same per-10,000 charge applies even to standard parameters. A service that polls its configuration in a tight loop can therefore turn a free tier into a metered one without a single parameter changing tier.
Why This Architecture Holds Up
The per-item pricing rewards deletion, not optimisation
Both services bill per stored item per month, prorated hourly. There is no volume discount to engineer toward and no tiering to tune. The only lever is how many items exist, which makes the highest-return activity deleting things that should never have been stored — duplicated per-environment copies of an identical value, entries for services that were decommissioned, secrets created by a pipeline that no longer runs.
This is unusual and worth naming, because most AWS cost work is about choosing a better shape for the same data. Here the correct move is usually to have less data.
Rotation is the capability you cannot retrofit cheaply
Everything else on the Secrets Manager side of the ledger has a Parameter Store equivalent or near-equivalent. Rotation does not, and building it yourself is not a weekend job: it needs a scheduler, a rotation function per credential type, versioning so readers do not break mid-rotation, and a rollback path for a rotation that half-succeeded.
That asymmetry is why the rule is worth applying strictly in both directions. Putting non-rotating values in Secrets Manager wastes money; putting genuinely rotating credentials in Parameter Store to save $0.40 buys you an operational problem worth far more than that.
The one-way door is the part that needs a policy
Cost mistakes here are reversible — delete the entry, stop the charge. The tier upgrade is not, and it is the only decision in this post that outlives the person who made it. A parameter promoted to advanced during an incident, because a value would not fit, is still advanced two years later, still billed, and now read by things nobody remembers.
Treat the tier as an explicit field in whatever creates parameters, never left to the account default, and review it the way you would review an IAM policy rather than a config value.
Key Architecture Decisions
| Value | Where it belongs | Because |
|---|---|---|
| Database credentials, rotating API keys | Secrets Manager | Managed rotation and versioning is the capability being bought. $0.40 is cheap for it. |
| Log levels, feature flags, timeouts, endpoint URLs | Parameter Store, standard | No additional charge for the parameter or its API calls. Nothing here rotates. |
| Sensitive but static values | Parameter Store, standard, SecureString | KMS encryption without the rotation premium. Sensitivity is not the deciding factor. |
| Values over 4 KB, or needing policies | Parameter Store, advanced | The only legitimate reasons to cross into the paid tier. Upgrade the individual parameter, not the default. |
| Config shared across accounts | Parameter Store, advanced | Cross-account sharing is advanced-only. Weigh it against publishing the value another way. |
| Anything read in a tight polling loop | Cache it in the application | Higher throughput bills per 10,000 interactions even for standard parameters. |
The audit that pays for itself
List every secret and every parameter with its last-changed date, then sort by age. Entries
that have not changed since creation are, almost by definition, not rotating — and every
one of those sitting in Secrets Manager is $4.80 a year for a feature nobody is using. In the
same pass, run get-service-setting against the default parameter tier in each
account and Region, so you know whether new parameters are quietly being promoted.
Closing Thought
“Secrets go in Secrets Manager” is a good rule that fails quietly, because the word does the damage. Everything in a config file starts to feel sensitive when it sits beside a password, and the cost of being wrong is forty cents — too small to argue about individually and large enough to matter fourteen hundred times over.
The better rule is narrower and harder to misread: rotating credentials go in Secrets Manager, everything else is a parameter. It costs nothing to apply, it survives being quoted out of context, and it leaves the only irreversible decision in the system — the advanced tier — as something you have to ask for on purpose.
Comments