Secrets Manager vs Parameter Store (2026)

AWS Secrets Manager and Systems Manager Parameter Store store the same kinds of string. Secrets Manager charges $0.40 per secret per month and standard Parameter Store parameters cost nothing, and AWS's own pricing examples put the gap at $604.50 a month for fifteen hundred secrets against zero. The difference in what you get is real but narrower than that ratio suggests, and there is one configuration change on the free side that starts billing without warning.

Does AWS Secrets Manager cost money?

Yes, on two meters, and the first one runs whether or not anything reads the secret. The Secrets Manager pricing page works four examples, all of them computing against $0.40 per secret per month and $0.05 per 10,000 API calls. Its mid-size example: "1,500 secrets @ $0.40 / secret" is $600.00, and "900,000 API calls (1,500 secrets * 20 API calls/day * 30 days) @ $0.05/10,000 calls" is $4.50, for "$604.50" a month.

Three details change the arithmetic more than people expect:

• Replicas are secrets. AWS states that "a replica secret is considered a distinct secret and will also be billed" at the per-secret rate "per replica per month". Replicating 1,500 secrets to a second Region doubles the storage charge to $1,200.
• Storage is prorated hourly. "For secrets that are stored for less than a month, the price is prorated (based on the number of hours.)" AWS's ephemeral example computes the hourly rate directly: "$0.40 * 1 hour / (30 days * 24 hours) = $0.00056 / secret/ hour". That still adds up: five million one-hour tokens a month is "$2,800.00".
• Rotation does not add a storage charge. "Rotating a secret creates a new version of the secret. You are not charged for creating new versions." The rotation Lambda's own invocations and the API calls it makes are billed normally.

Is AWS Systems Manager Parameter Store free?

The standard tier is, with two asterisks. The Systems Manager pricing page is unambiguous on the storage side: "standard parameters are available at no additional charge", against "$0.05 per advanced parameter per month (prorated hourly if the parameter is stored less than a month)".

The first asterisk is how an interaction is counted, which is not per API call: "a Parameter Store API interaction is defined as an interaction between an API request and an individual parameter. For example, if a Get request returns ten parameters, that counts as ten Parameter Store API interactions." A single GetParameters batch call for ten advanced parameters is ten billable interactions, so batching reduces requests and not cost.

The second is encryption. A SecureString parameter is not encrypted by Parameter Store, per the KMS encryption documentation: "Parameter Store does not perform any cryptographic operations. Instead, it relies on AWS KMS to encrypt and decrypt SecureString parameter values. When you create or change a standard SecureString parameter value, Parameter Store calls the AWS KMS Encrypt operation." Reads call decrypt. So every read of an encrypted parameter is a KMS request on your bill.

The key itself is free, because it is an AWS managed key: the KMS pricing page lists "creation and storage of AWS managed or AWS owned KMS keys" among the things "you are not charged for", and by default "Parameter Store uses the AWS managed key that Systems Manager automatically creates in your account. This KMS key has the aws/ssm alias." The requests are not free past "a free tier of 20,000 requests/month calculated across all Regions that the service is available". A fleet re-reading encrypted parameters on every task start passes that quickly, and the request rates are in what AWS KMS costs at scale.

How much does the same set of secrets cost in each?

Taking AWS's own example workloads and pricing the Parameter Store equivalent at its published rates:

The Secrets Manager column is AWS's arithmetic: "$6.02", "$604.50" and "$4,060.00" are the totals from its examples 1, 3 and 4. The Parameter Store columns are ours, applying the published $0.05 per parameter and $0.05 per 10,000 interactions to the same counts. Standard-tier storage is genuinely zero; what you would still pay is KMS requests on any SecureString reads, which are not shown here because they depend on your read pattern rather than on your secret count.

Note the 10,000-secret row: standard parameters cap out at exactly that number. The parameter tier documentation gives "maximum parameters (per AWS account and AWS Region)" as 10,000 standard and 100,000 advanced, so a workload at that scale is choosing between the advanced tier and Secrets Manager, not between advanced and free.

What does Parameter Store not do that Secrets Manager does?

Three things, and only the first is a real gap for most teams.

• Managed rotation. Secrets Manager rotates a credential on a schedule and coordinates the change with the service that owns it. The rotation function is a Lambda, so it carries Lambda's meters too, including the initialization time that became billable in August 2025. Parameter Store stores whatever you put in it. If you have a compliance requirement to rotate database credentials, this is the whole argument and price does not enter into it.
• Cross-Region replication. Built in, and billed as a second secret per Region.
• Larger values and parameter policies. These are the advanced tier's job on the Parameter Store side: "maximum value size" is 4 KB standard against 8 KB advanced, and parameter policies are "not supported" on standard and "supported" on advanced. Secrets Manager sits well above both: its quotas put the "maximum size of an encrypted secret value" at 65,536 bytes.

What Parameter Store does that Secrets Manager does not is hierarchy. A name like /prod/api/db-password is a path, and AWS names the payoff in the parameter hierarchies documentation: "another benefit of using hierarchies is the ability to query for all parameters under a certain level in a hierarchy by using the GetParametersByPath API operation." That is how most configuration loading works in practice. Just remember the interaction counting rule above: fetching a path with fifty advanced parameters under it is fifty interactions.

Why is upgrading a Parameter Store parameter a one-way door?

Because AWS will not convert it back. From the tier documentation: "you can change a standard parameter to an advanced parameter, but you can't change an advanced parameter to a standard parameter." Three reasons are given, and they are all structural rather than policy:

"Changing the parameter to the standard tier would truncate the parameter value from 8 KB to 4 KB, resulting in data loss. Changing the parameter to the standard tier would remove any policies attached to the parameter. Advanced and standard parameters use a different form of encryption."

The only exit is deletion: "if you no longer need an advanced parameter, or if you no longer want to incur charges for an advanced parameter, delete it and recreate it as a new standard parameter." For a parameter referenced by running workloads, that is a change with a blast radius, which is why advanced parameters accumulate.

The setting that creates them in bulk is the account default tier: "you can set the default to Standard, Advanced, or Intelligent-Tiering". Set it to Advanced once, and every parameter created without an explicit tier from then on is $0.05 a month forever. AWS notes the default "affects only new parameters that you create without specifying a tier" and that "existing parameters aren't affected", so putting the default back does not undo anything already created.

When does higher throughput start billing your standard parameters?

The moment you enable it, and it is an account-level switch that changes the price of parameters you were not thinking about. AWS's example:

"Assume you have 5,000 parameters, 500 of which are advanced parameters. Assume that you have enabled higher throughput limits and interact with each parameter 24 times per day, equating to 3,600,000 interactions per 30-day month. Because you have enabled higher throughput, your API interactions will be charged for standard and advanced parameters."

The result is "$25 + $18 = $43", where the $18 is 3.6 million interactions across all 5,000 parameters, not just the 500 advanced ones. The contrasting example has higher throughput disabled and 50 million interactions, of which "only 20 million interactions are with advanced parameters", so only those 20 million are billed.

That is the trap: a throughput setting turned on to fix a rate-limit error quietly converts your free standard parameters into billed ones. It is reversible, unlike the tier change, but nothing tells you the bill has changed shape.

Which should you use, Secrets Manager or Parameter Store?

• Credentials that must rotate: Secrets Manager. The $0.40 a month buys managed rotation, and rebuilding that on Parameter Store costs more in engineering than it saves.
• Application configuration: Parameter Store, standard tier. Endpoints, feature flags, ARNs and non-secret settings have no business costing $0.40 each. This is the case where the free tier is genuinely free.
• Under 10,000 items and under 4 KB each: stay standard. The advanced tier is a one-way door and the limits it lifts are ones most teams never reach.
• Cache reads rather than batching them. Batching does not reduce interaction count, and for SecureString parameters each read is also a KMS request. Reading once at startup rather than per request is what actually moves the number.
• Audit for replicas. A replicated secret is a second full-price secret, and multi-Region replication tends to be enabled once and never reviewed.

Whichever you pick, both charges are small per unit and large in aggregate, which makes them exactly the kind of spend that never appears in a top-ten services list and never gets attributed to a team. If you are trying to split them by owner, the mechanics are the same as everywhere else: why cost allocation tags show up empty and, for charges shared across teams, AWS Cost Categories split charge rules.