Ten thousand secrets: what Secrets Manager, Key Vault and Secret Manager charge

The meter that decides a secrets bill is storage, not traffic

AWS publishes two meters for Secrets Manager and nothing else: $0.40 per secret per month and $0.05 per 10,000 API calls. A replica secret is treated as a distinct secret and billed at the same $0.40 per replica per month, and secrets held for less than a month are prorated by the hour. There are no upfront costs and no long-term contracts on the page.

The ratio between the two meters is the whole story. At 10,000 secrets the storage line is $4,000 a month before a single read. AWS's fourth worked example assumes an organisation with a monthly AWS spend above $250,000 holding 10,000 secrets, each touched 40 times a day, which comes to 12 million API calls a month and $60 at the published rate. Storage is roughly 66 times the call charge in that estate.

That inverts the intuition most platform teams bring from compute, where utilisation drives the invoice. Here the count of secrets and the count of replicas set the floor, and the read volume barely moves it. A team that consolidates 10,000 short-lived tokens into one store pays for the tokens, not for the traffic.

What 10,000 secrets and a million reads actually cost

Run the published numbers on the estate in the newsletter item. Ten thousand secrets at $0.40 is $4,000 a month. One million API calls at $0.05 per 10,000 is $5. The combined figure is $4,005 a month, or about $48,060 a year, and 99.9% of it is the storage meter.

AWS's own examples show the same shape at smaller sizes. A production web application with 15 secrets and 4,040 API calls a month pays $6.00 for secrets and roughly $0.02 for calls. An organisation with 1,500 secrets touched 20 times a day, 900,000 calls a month, pays $600 for storage and $4.50 for calls. The call meter only becomes visible when reads run into the tens of millions.

Ephemeral secrets are the exception worth modelling. AWS prices a token stored for one hour at $0.40 multiplied by one hour over 30 days of 24 hours, which is $0.00056 per secret per hour. Five million tokens a month retrieved twice each is 10 million API calls, $50, and the storage charge is prorated to the hour each token lives. Short-lived secrets move the bill from the storage meter to the call meter, which is the one case where the two lines trade places.

Where the managed route stops being cheaper than running your own

The AWS page does not price a self-managed alternative, and neither of the other two vendors' pages in this pack publishes a per-seat figure for a self-hosted deployment. That comparison is quote-only in the material available, and the number to ask a vendor for is the fully loaded annual cost of the control plane: compute, storage backend, high-availability replicas, upgrade labour and the on-call rota that keeps it up. AWS's page makes the counter-argument explicit, stating that with Secrets Manager you pay for usage without incurring costs related to infrastructure, licensing and personnel required to ensure your secrets are reliably and highly available.

The crossover is arithmetic once that figure exists. At $0.40 per secret per month, 10,000 secrets cost $48,000 a year. If a self-managed deployment costs less than that fully loaded, the managed route is the more expensive one at that count; if it costs more, the managed route wins on price as well as on operations. The break-even secret count is the self-managed annual cost divided by $4.80.

Rotation frequency does not appear as a separate charge on the AWS page, which notes that rotating a secret creates a new version and that you are not charged for creating new versions. What rotation does add is API calls: AWS's first example counts 7 API calls per database credential per week to rotate credentials safely. At $0.05 per 10,000 calls, a weekly rotation across 10,000 credentials is 3.64 million calls a year, about $18. Cheap, but it belongs in the model rather than being assumed away.

How the shortlist compares on the meters that move

Three managed stores are the realistic shortlist for a team already running a hyperscaler estate: AWS Secrets Manager, Azure Key Vault and Google Cloud Secret Manager. The AWS page publishes both of its meters in full, including the replica rule and the hourly proration. The Azure and Google pages in this pack are navigation and service-catalogue text; they do not state a per-secret or per-call price in the material available, so those figures are unpublished here and the request to each vendor is the same: the per-secret monthly rate, the per-10,000-operation rate, whether replicas or versions are billed separately, and how short-lived secrets are prorated.

The criteria that separate them are not feature names. They are whether replicas are billed as distinct secrets, whether a secret held for an hour is charged as a month, whether rotation creates a billable event, and whether the store sits inside the cloud account the workload already runs in, because a cross-cloud store adds an egress and latency line the per-secret meter does not show.

For a 10,000-secret estate the AWS arithmetic is settled: $4,000 a month in storage, $60 for 12 million calls, $4,005 total. A buyer comparing against Key Vault or Secret Manager needs the equivalent two numbers from each vendor before the comparison means anything, and a vendor that will not put them in writing is a finding in itself.

The replica rule is the line most estates miss

AWS states that a replica secret is considered a distinct secret and is billed at $0.40 per replica per month. A team that replicates every secret into three regions for latency or residency reasons has multiplied its storage meter by three before any workload reads anything. At 10,000 secrets that is $12,000 a month, not $4,000, and the call meter is unchanged.

This is the single design decision that moves the bill most, and it is made by the platform team rather than by procurement. The question to settle in an architecture review is which secrets genuinely need a replica in each region and which can be fetched from the primary store, because the per-replica charge is the same as the per-secret charge and applies to every copy.

The same logic applies to versioning. AWS does not charge for new versions created by rotation, so a rotation policy that keeps many versions does not add to the storage meter on the published terms. A team that has been rationing rotations to control cost is optimising the wrong line.

What to verify before the renewal call

Ask for the secret count and the replica count separately, because they are billed on the same meter and reported together in most inventories. A 10,000-secret estate with two replicas each is a 30,000-secret bill at $12,000 a month, and the inventory that says 10,000 is not wrong, just incomplete.

Ask for the API call volume over the last twelve months, not the last month, because ephemeral token patterns spike and AWS's own example shows a token estate generating 10 million calls a month from five million tokens. At $0.05 per 10,000 calls that is $50, which is small, but a token estate at 100 million calls is $500 and worth knowing before the commitment.

Then ask each alternative vendor for the two published meters and the replica rule in writing. The AWS page gives all three. The Azure and Google pages in this pack do not, so the comparison is only as good as the rate cards a buyer can extract from them.

The decision rule

Choose AWS Secrets Manager if the estate already runs on AWS, the secret count is in the low thousands, and the team would rather pay $0.40 a secret than staff a control plane, because at 1,500 secrets the published bill is $600 a month for storage and $4.50 for 900,000 calls. Choose a self-managed store if the fully loaded annual cost of running it is below $4.80 per secret per year and the team already has the on-call capacity to keep it highly available, since that is the break-even the AWS meter sets.

Wait on a cross-cloud decision until Key Vault and Secret Manager have put their per-secret, per-operation and replica terms in writing, because a comparison against unpublished meters is a guess dressed as a shortlist. If the estate is dominated by short-lived tokens rather than long-lived credentials, model the hourly proration first, since that is the one pattern where the call meter overtakes the storage meter.