AWS costs: KMS - the $1/key/month and the request charges

Every AWS KMS customer managed key costs a flat $1 a month, prorated by the hour, whether you use it once or a million times — that part is simple. The part almost nobody expects: an "AWS managed" key, the free one AWS creates for you automatically, is only free to store. The instant your application calls it more than 20,000 times a month, you pay the exact same per-request rate as a key you built yourself.

AWS Key Management Service, or KMS, is the AWS service that creates and stores the encryption keys other services use to protect your data — Amazon S3 objects, EBS volumes, RDS databases, Secrets Manager entries, and dozens more. You almost never touch KMS directly. It sits quietly underneath everything, which is exactly why its bill is so easy to lose track of: nothing about it shows up as a running instance or an active resource anywhere obvious.

The AWS KMS bill has exactly two moving parts: what it costs to have a key sitting in your account (key storage), and what it costs every time something asks that key to do work (key usage, billed per request). Get comfortable separating those two, because they behave completely differently — one is a flat, predictable fee, and the other can go from a rounding error to your biggest line item in a single busy afternoon.

The $1/month key storage fee, exactly as AWS bills it

This in one sentence, and it's worth reading exactly as written: every AWS KMS key you create costs $1 a month, prorated hourly, and that price is identical whether the key is symmetric, asymmetric, an HMAC key, holds imported key material, or lives in AWS CloudHSM or an external key store. There's no cheaper tier for a "small" key or a lightly used one. A key that has never once been asked to encrypt anything still costs $1 a month, because the charge is for having it, not for using it.

"Prorated hourly" is the detail people miss. If you create a key on the 28th of the month and delete it on the 30th, you're billed for roughly two days' worth of the fee, not a full month. That cuts both ways — a key you create and delete within the same billing cycle costs pennies, but a key you forget about for three years has been quietly billing $1 every single month of those three years, and nothing in the AWS console proactively tells you that.

Multi-Region keys: you're paying per key, not per "keypair"

If you've replicated a KMS key across regions for disaster recovery, AWS bills the primary key and every replica as separate keys, each carrying its own $1/month charge. A primary key in us-east-1 with replicas in us-west-2 and eu-west-1 isn't "one multi-Region key" on the bill — it's three keys, $3/month in storage before a single request happens. That's not a penalty for using the feature; it reflects the fact that each replica is genuinely stored and managed independently in its own region. Budget for it as three line items, not one.

AWS managed keys vs. customer managed keys — why "free" isn't the full story

KMS has three tiers of keys, and only one of them costs you the $1/month fee. AWS owned keys are a shared pool AWS manages entirely behind the scenes for baseline encryption in some services — you never see them, never pay for them, and can't control them. AWS managed keys are created automatically the first time a service like S3, EBS, or RDS needs to encrypt something on your behalf and you haven't specified your own key; these show up in your account with names like aws/s3 or aws/rds, and there is never a monthly storage charge for them. Customer managed keys are the ones you create yourself, and every one of those carries the $1/month fee, plus you control (and are responsible for) the key policy, rotation, and lifecycle.

Here's the part that trips people up: "no monthly charge" only covers storage. There is a catch here — while you aren't charged for the creation and storage of AWS managed keys, you are charged for any API request made to them. An AWS managed key sitting idle costs nothing. An AWS managed key backing a busy S3 bucket generates exactly the same per-request charges as if you'd built a customer managed key yourself, once you're past the shared 20,000-request free tier.

One more billing detail worth knowing before it surprises you: if a key is used from a different AWS account than the one that owns it — a shared key across a multi-account organization, for instance — AWS bills the account that makes the API request, not the account that owns the key. Ownership and usage cost are tracked separately.

Key rotation: the $1-to-$3 fee, and the change that made it cheaper

Automatic or on-demand rotation of a customer managed key adds to the storage fee, but the rule is narrower than most people assume: the first rotation adds $1/month, the second rotation adds another $1/month, and every rotation after that is free. A key that has rotated ten times over its life costs exactly the same as one that's rotated twice — $1 base plus $2 for the first two rotations, $3/month, permanently capped.

Rotation is a storage-side charge, not a usage-side one — AWS handles the actual work of generating new key material in the background, and it doesn't count against your request free tier. Since mid-2025, imported key material also supports on-demand rotation using the same pricing model, which matters if you bring your own key material for compliance reasons rather than letting AWS generate it.

Request charges: the 20,000 free calls, and what happens after

Every AWS account gets 20,000 free KMS requests a month, and that allowance is calculated across every region KMS is available in — it's one shared pool for the whole account, not 20,000 per region and not 20,000 per key. If you have five keys in three regions, they're all drawing from the same 20,000.

Past that free tier, standard symmetric operations — Encrypt, Decrypt, GenerateDataKey, GenerateDataKeyWithoutPlaintext, ReEncrypt, GenerateRandom, and HMAC operations like GenerateMac and VerifyMac — bill at $0.03 per 10,000 requests. That's the rate in this worked example: a key encrypting 10,000 files and then decrypting them 2,000,000 times a month racks up 1,990,000 billable requests after the free tier, which comes to $5.97, plus the $1 key fee, for a $6.97 total. It's a genuinely small number until the volume gets large — which, for anything touching S3 or a database at scale, it usually does.

Note the asterisk on that free tier: it explicitly excludes GenerateDataKeyPair, GenerateDataKeyPairWithoutPlaintext, and any Sign, Verify, Encrypt, Decrypt, or GetPublicKey call made against an asymmetric key. If your workload leans on asymmetric cryptography at all — code signing, certificate issuance, anything requiring a shareable public key — assume every one of those calls is billed from request one, with no free allowance to soften it.

Symmetric vs. asymmetric: why the price gap exists and when it matters

Symmetric keys use one key to both encrypt and decrypt, and they're what almost every AWS service defaults to for encrypting data at rest — S3 objects, EBS volumes, RDS storage. Asymmetric keys are a public/private pair: useful when you need to hand out a public key so someone outside AWS can encrypt something, or when you're digitally signing files and need a signature others can verify without ever touching your private key. A worked example prices signing 100,000 files with an ECC 256 key at $0.15 per 10,000 requests — $1.50 for the requests plus $1 for the key, $2.50 a month total.

The mistake that's easy to make once and expensive to repeat: choosing an asymmetric key for ordinary data-at-rest encryption inside AWS "because it sounds more secure." For anything staying inside AWS services — S3, EBS, RDS, Secrets Manager — a symmetric key does the job at a fraction of the per-request cost, with no security trade-off for that use case. Reach for asymmetric only when the workload genuinely needs a public/private pair: external verification, code signing, or client-side encryption where the encrypting party shouldn't hold decryption rights.

Where the real money goes: S3 encryption at scale

Here's the counterintuitive part in full: the $1/month key fee is the number people fixate on, and it's almost never the biggest number on the bill. When Amazon S3 encrypts objects with a KMS key (SSE-KMS) and you haven't turned on a specific optimization, S3 makes an individual call to KMS for every single object operation — every upload, every download, every copy. A bucket serving millions of reads a month can blow through the 20,000 free requests before lunch, and every request after that is billing at the standard rate.

The fix is a setting, not a redesign: S3 Bucket Keys. Instead of asking KMS for a fresh call on every object, S3 generates a short-lived, bucket-level key and reuses it to derive the encryption key for new objects during its lifecycle, cutting the number of calls that actually reach KMS. This can reduce KMS request costs on SSE-KMS buckets by up to 99 percent, and AWS's storage team has reported that Bucket Keys have saved customers more than $80 million since the feature launched at the end of 2020. It's a checkbox in the console, applies to new objects immediately, and existing objects can be brought in line using S3 Batch Operations with S3 Inventory to identify what still needs copying over.

1. Open the S3 console and select the bucket using SSE-KMS encryption.
2. Go to the bucket's Properties tab and find Default encryption.
3. Confirm the encryption type is set to a KMS key (either AWS managed or your own customer managed key).
4. Turn on Bucket Key — this applies to objects uploaded from this point forward with no application changes required.
5. For existing objects, use S3 Inventory to list which objects don't yet have a Bucket Key applied, then run an S3 Batch Operations copy job to bring them in line.
6. Check back in Cost Explorer after a billing cycle to confirm the KMS request line item actually dropped.

Cutting request volume with client-side data key caching

S3 Bucket Keys fix the S3-to-KMS traffic problem specifically. If your own application code — a Lambda function, an EMR job, a custom service — is calling KMS directly and generating a fresh data key for every operation, that's a separate problem with a separate, fix: data key caching in the AWS Encryption SDK.

The AWS Encryption SDK is a client-side library for encrypting data before it ever leaves your application. Normally it calls KMS's GenerateDataKey operation once per encryption and Decrypt once per decryption. Data key caching adds a local cache in front of those calls: your application checks the cache first, and only calls KMS when there's no usable cached key, governed by limits you set — a time-to-live, and a maximum number of times a cached key can be reused. Take a sample architecture (data producers writing to Kinesis, Lambda consumers reading from it) where adding a local cache reduced KMS calls to roughly 1 percent of what they were without one — from 500 requests per second per region down to 5.

This isn't only a cost optimization. Reach for caching specifically if you're hitting your KMS requests-per-second quota and a quota increase alone doesn't solve the underlying problem — high-throughput, high-concurrency workloads are exactly where this pays off. AWS's security team has also published a real account of the scale this reaches: a financial-crime detection platform processing millions of encrypted messages daily reduced its KMS costs by 77 percent by tuning how it cached data keys across a high-concurrency, multi-tenant system.

Ethan's take: "Caching a data key does mean reusing it more than a purist would like — encryption best practice generally leans toward using a key once and throwing it away. AWS is upfront that this is a genuine trade-off, not a free lunch. The SDK lets you set hard limits on how long a cached key lives and how many times it gets reused, so you're choosing exactly how much reuse you're comfortable with, not turning off the safety rails entirely."

Other AWS services quietly calling KMS on your behalf

S3 is the workload everyone thinks of first, but it isn't the only AWS service generating KMS traffic behind your back. Every time the value of a secret changes, Secrets Manager requests a brand-new data key from KMS to protect it — so a secret that's rotated frequently, or a fleet of secrets all rotating on a schedule, is a steady, recurring source of GenerateDataKey and Decrypt calls, not a one-time cost.

AWS Systems Manager Parameter Store behaves similarly for SecureString parameters: encrypting a standard SecureString needs kms:Encrypt permission, encrypting an advanced-tier SecureString needs kms:GenerateDataKey, and decrypting either type needs kms:Decrypt — every one of which is a billable request once you're past the free tier. Amazon EventBridge does something a little different: it defaults to an AWS owned key (genuinely free, no visibility) for encrypting connection credentials, and only starts generating billable, visible KMS traffic if you explicitly switch a connection to a customer managed key.

The pattern worth remembering

None of these services put "KMS charge" anywhere in their own console. The charge shows up only on the KMS line of your bill, attributed to whichever key each service was told to use. If you're trying to trace a KMS cost spike back to its source, don't stop at S3 — check whether a secret rotation schedule tightened, whether a new SecureString-heavy deployment went out, or whether a service that used to default to an AWS owned key got switched to a customer managed one.

CloudHSM and external key stores: a different order of magnitude

You can back a KMS key with a dedicated CloudHSM cluster or an external key manager instead of AWS's own hardware — a custom key store. Those keys still cost the same $1/month key fee, plus the same per-request rates, but there's a much larger charge sitting underneath: the CloudHSM cluster itself. A pricing example for exactly this setup — one KMS key, 10,000 files encrypted, 2,000,000 decrypt requests, with two HSMs running the entire month — comes to $2,387.77. Of that, $1 is the key fee, $5.97 is the request charges, and $2,380.80 is the two HSMs running around the clock for a 31-day month.

The lesson isn't "avoid CloudHSM" — some compliance frameworks genuinely require dedicated, single-tenant hardware, and that's what you're paying for. The lesson is to know which category you're in before you flip that switch: standard KMS pricing scales with usage in small dollar amounts, while a custom key store adds a large, mostly-fixed infrastructure cost that runs whether you use it heavily or barely touch it.

Finding the keys nobody remembers creating

A recurring question on community forums is some version of "why am I being charged for KMS when the console shows nothing running?" The pattern AWS support points to is consistent: a flat, unexplained monthly charge with no matching request volume almost always means a customer managed key exists somewhere in your account — created by you, by a developer who's since moved on, or by a CloudFormation template or Solutions Library stack you deployed once and forgot about. KMS is a regional service, so the key causing the charge might be sitting in a region you never look at.

Ethan's take: "The advice I see floating around — 'just delete every key you don't recognize' — is the wrong instinct, and it's the kind of advice that turns a $6 mystery charge into a Saturday spent restoring an EBS volume you can no longer decrypt. Check what's actually using a key before you touch it. It costs you nothing to look and everything to guess wrong."

1. Open the KMS console and switch through every region your account has ever used, not just your default.
2. For each customer managed key, open its details and check the Key usage and Aliases to see what name or purpose it was given.
3. Open AWS Cost Explorer, filter Usage Type to your region's KMS-Keys line, and group by API Operation to see current versus rotated key charges.
4. Turn on AWS CloudTrail if it isn't already, and check for recent Encrypt, Decrypt, or GenerateDataKey calls against the key's ARN — a key with zero recent activity in CloudTrail is a strong candidate for cleanup.
5. Before deleting anything, confirm no resource (an EBS snapshot, an S3 object, a Secrets Manager secret) still depends on that specific key for decryption.
6. Schedule deletion rather than deleting immediately — this gives you a waiting period (adjustable from a handful of days up to a month) during which the key doesn't bill, and you can still cancel if something turns out to depend on it.

A realistic monthly bill, worked out three ways

Numbers make more sense side by side than in isolation. These three are AWS's published pricing examples as of September 2026, not estimates.

The jump between rows two and three isn't KMS getting more expensive — the key and request charges are identical in both. It's the infrastructure underneath a custom key store, and it's why "should I use CloudHSM" is really a compliance question first and a cost question a distant second.

What to do when the KMS line item won't stop growing

Work down this in order — cheapest and least risky first:

1. Check for orphaned customer managed keys across every region — this is free to check and free to fix once you've confirmed nothing depends on them.
2. Turn on S3 Bucket Keys on any SSE-KMS bucket that hasn't got it — a settings change, no application code involved, and the single biggest lever for request-heavy workloads.
3. If your own application code calls KMS directly, look at data key caching in the AWS Encryption SDK for anything high-throughput — it addresses request volume that Bucket Keys can't touch.
4. Consolidate keys where your security policy allows it — one key per environment or workload rather than one per resource cuts the flat $1-to-$3 storage fee without touching your actual security posture.
5. Switch unnecessary asymmetric keys back to symmetric for anything that's pure data-at-rest encryption inside AWS, where the security is equivalent and the per-request rate is a fraction of the cost.
6. Only after that, look at whether a custom key store or CloudHSM is actually required by a compliance framework you're subject to — and if it isn't, standard KMS almost always costs less.

Frequently asked questions

Is AWS KMS free?

No, not entirely, but it can get close for light use. AWS managed keys cost nothing to store, and the first 20,000 requests a month across your whole account are free regardless of key type. Once you create a customer managed key, or you cross that request threshold, charges apply.

How much does an AWS KMS key cost per month?

A customer managed key costs $1.00/month, prorated hourly. If automatic or on-demand rotation is enabled, the first and second rotation each add $1/month, capping the total at $3/month no matter how many times it rotates after that. That cap only started the first week of May 2024 — before that, every rotation added another dollar with no ceiling, so a key with a long rotation history could have been billing far more.

Do AWS managed keys cost anything?

Storing them is always free. Using them past the 20,000-request free tier is not — AWS managed keys bill at the same per-request rates as a customer managed key once you're past that free allowance.

Why am I being charged for KMS when I'm not actively using any keys?

A flat monthly charge with little or no matching request activity almost always means a customer managed key exists somewhere in your account, often in a region you don't normally check. KMS bills for having a key, not just for using one.

What happens to the $1/month charge if I schedule a key for deletion?

No charge applies during the scheduled deletion waiting period. The key stops billing as soon as it's scheduled, not only once the deletion completes.

Does canceling a scheduled key deletion bring back charges?

Yes, in full. If you cancel the deletion, the key is billed exactly as if it had never been scheduled for deletion, with no discount for the time it spent waiting.

How many free KMS requests do I get per month?

20,000, shared across your entire account and every region KMS is available in — it isn't 20,000 per key or per region.

Does the free tier apply to asymmetric keys?

Not to most of what you'd actually do with one. GenerateDataKeyPair, GenerateDataKeyPairWithoutPlaintext, and Sign, Verify, Encrypt, Decrypt, or GetPublicKey calls against an asymmetric key are all excluded from the free tier and billed from the first request.

Why do asymmetric operations cost more than symmetric ones?

Standard symmetric operations bill at $0.03 per 10,000 requests. Most other asymmetric operations bill at $0.15 per 10,000 — five times the rate — reflecting the heavier computational cost of asymmetric cryptography and the fact that they sit outside the free tier entirely.

Are multi-Region KMS keys billed as one key or several?

Several. The primary key and every replica are each billed as their own customer managed key, each carrying its own $1/month fee.

How can I reduce KMS request charges on S3?

Turn on S3 Bucket Keys on any bucket using SSE-KMS encryption. It's a setting, not a code change, and AWS claims it can cut KMS request traffic from that bucket by up to 99 percent.

What is data key caching, and does it actually save money?

It's a feature in the AWS Encryption SDK that reuses a data key from a local cache instead of calling KMS for every single encrypt or decrypt operation. There is an example where adding a local cache cut KMS calls to roughly 1 percent of the original volume, and AWS's security team has documented a real workload that cut KMS costs by 77 percent using it.

Does data key caching weaken my encryption security?

It involves a genuine trade-off — reusing a key is generally discouraged in encryption best practice — but the Encryption SDK lets you set hard limits on how long a cached key lives and how many times it can be reused, so you control exactly how much reuse you're accepting rather than removing the limits entirely.

Do other AWS services like Secrets Manager and Parameter Store add their own KMS charges?

Yes. Secrets Manager requests a new data key from KMS every time a secret's value changes, and Parameter Store SecureString parameters generate a billable KMS call on every encrypt or decrypt. Neither service shows this as its own line item — it only appears under KMS on your bill.

Is CloudHSM or a custom key store more expensive than standard KMS?

Usually, by a wide margin. The key and request charges stay identical to standard KMS, but a dedicated CloudHSM cluster adds its own hourly infrastructure cost on top — in the published example, two HSMs running for a month cost well over two thousand dollars, dwarfing the KMS charges underneath it.

How do I find out which KMS keys are actually being used before I delete anything?

Check the key's activity in AWS CloudTrail for recent Encrypt, Decrypt, or GenerateDataKey calls, and check whether any current resource — an EBS volume, an S3 object, a Secrets Manager secret — still references that key's ARN. Schedule deletion rather than deleting immediately so you have a window to cancel if something turns out to depend on it.

Revision note. Written Sep 2026, covering current AWS KMS pricing for customer managed keys, AWS managed keys, key rotation, request charges, data key caching, and CloudHSM/custom key stores. Rates and free tier limits are set by AWS and can change without notice, so cross-check the figures against AWS's own KMS pricing page before budgeting a large workload against them. If you've been staring at an unexplained KMS charge wondering what you broke — you probably didn't break anything, and it's almost always fixable in less time than it took to find it.Happy learning