AWS KMS API request cost shows up when the application asks KMS for a cryptographic operation on every object. The monthly key charge is one dollar and easy to find. The request charge is a fraction of a cent per call, and it disappears into the noise until a hot path multiplies it by millions. A per-object encrypt, or a per-object data key, is that multiplier. The key did not get more expensive. The code called it once per file.
Rutagon treats the line as a call pattern. KMS encryption evidence is how the client shows an auditor which keys protect which stores. This article is the request meter on the hot path.
Where AWS KMS API request cost is published
The KMS pricing page prices key storage and key use apart. Each customer managed KMS key costs $1 a month, prorated hourly. That dollar is the same for symmetric keys, asymmetric keys, HMAC keys, multi-Region keys (each primary and each replica), keys with imported material, and keys whose origin is CloudHSM or an external key store. Automatic or on-demand rotation adds $1 a month, prorated hourly, for the first rotation and again for the second. The increase stops at the second rotation. Later rotations are not billed. Keys you schedule for deletion drop the monthly charge. Cancel the deletion and the charge returns as though the key was never scheduled.
You are not charged for creating or storing AWS managed keys or AWS owned keys. You are charged for API requests against AWS managed keys. A team that switches from a customer managed key to aws/s3 removes the $1 storage line and keeps the request line. There is no monthly charge for the data keys KMS generates, beyond the charge for the API call that created them.
The free tier is 20,000 requests a month, counted across all Regions where KMS is offered. Requests to GenerateDataKeyPair and GenerateDataKeyPairWithoutPlaintext are outside that free tier. So are Sign, Verify, Encrypt, Decrypt, and GetPublicKey when they reference an asymmetric KMS key. Symmetric encrypt and decrypt traffic in the published examples does use the free tier. When you call a KMS key in another account, the account that makes the API request pays for the use.
The page's Amazon S3 example is the per-object pattern with the arithmetic written out. One KMS key encrypts 10,000 files and those files are decrypted 2,000,000 times in the month. That is 10,000 encrypt requests and 2,000,000 decrypt requests. The example subtracts the 20,000 free requests from 2,010,000 and prices the remaining 1,990,000 at $0.03 per 10,000 requests, which it totals at $5.97. The key storage is $1. The month is $6.97. An EBS example on the same page creates 250 encrypted volumes and counts three API requests each, 750 requests, all inside the free tier, so the request charge is $0 and the bill is the $1 key. A signing example uses one ECC 256 key to sign 100,000 files at $0.15 per 10,000 requests, $1.50 of requests plus the $1 key, $2.50 for the month. That signing traffic is the asymmetric case the free tier excludes, and the example does not subtract 20,000.
key_storage: $1 per customer managed key per month, prorated hourly
rotation: first and second each add $1 per month, then the add stops
free_tier: 20,000 requests per month across Regions
s3_example: $0.03 per 10,000 encrypt or decrypt requests after the free tier
asymmetric_sign_example: $0.15 per 10,000, outside the free tier
per_object: one KMS call per file, unless a cache reuses the data keyThose rates are the published examples. A different operation can have a different row, and the signing example already does. We use $0.03 per 10,000 for the encrypt and decrypt shape the S3 example prices. We use $0.15 per 10,000 for the ECC signing shape. We do not blend them into one rate and call it KMS.
A per-object call, and a data-key cache
The data key caching documentation describes the default that creates this bill. The AWS Encryption SDK generates a new data key for every encryption operation unless you turn caching on. That default matches the practice of a unique data key per object. It is also one KMS request per object, in the same family as the S3 example's 10,000 encrypts. Decrypting each object later is another request, and the example's 2,000,000 decrypts are where the $5.97 comes from.
Data key caching stores the data key and the related material in a local cache. On the next encrypt or decrypt, the SDK looks for a match and uses the cached key when it finds one. The cache is optional. The SDK gives you a local cache and a caching cryptographic materials manager that enforces security thresholds you set. The documentation says to use caching when you need it for performance, cost, or a requests-per-second limit, and to keep the thresholds at the smallest reuse that meets that goal. We set those thresholds in the same change that turns the cache on, and we write down the maximum age and the maximum number of messages you accepted.
A hot path that calls Encrypt on the KMS key for every object never builds a data key at all. Each object is a KMS round trip on the way in and, if you decrypt through KMS too, on the way out. The S3 example is that shape with the service's own encryption: one encrypt per file, then a decrypt per read. Application-level encryption with a fresh GenerateDataKey per object is the same request count on the write. The data key itself has no monthly storage price. The API call does.
Cross-account keys move the request charge to the caller. A producer account that encrypts with a key in a security account pays the API request. The security account pays the $1 if it owns the customer managed key. We split those two lines so the team that owns the loop is the team that sees the $0.03.
Rotation changes storage. Two rotations add two extra key-months, capped there. A third rotation does not add another dollar under the current page, and it does not shrink the per-object request line. Database encryption key rotation is the separate control for keys that wrap a database. The hot-path cache does not replace that rotation. It stops the application from calling KMS once per row.
What we change on the path
The diagnostic is CloudTrail on the KMS key, grouped by event name and by caller. Encrypt, Decrypt, and GenerateDataKey from one role, at a rate that matches object writes, is the pattern. Cost Explorer shows the request line after the fact. The trail shows which function issued it. We compare the call count to the 20,000 free requests before anyone discusses the $0.03. Under the allotment, the month is the $1 key, as in the EBS example. Over it, the S3 example is the slope.
The fix on an application that can reuse a data key is the caching cryptographic materials manager, with thresholds written down. The fix on a path that should not reuse a data key is to stop calling KMS per object in a way the threat model does not require: envelope-encrypt a batch, or let S3, EBS, or RDS use the key the way the EBS example does, a handful of requests per volume. We do not cache a data key across tenants. We do not cache one forever to make the request line zero. The documentation's caution is the constraint we keep.
We leave per-object keys in place when the object is large, rare, and worth a unique key. Ten thousand files in the example are $5.97 of requests only because they were also read two million times. A key used a few hundred times a month is the EBS example: inside the free tier, $1 of storage, and no cache required. The hot path is the one we change.
Rutagon runs this as a short bill review. We count customer managed keys at $1, rotations at the capped add, and API calls against the 20,000 free requests. We price the overflow from the example that matches the operation: $0.03 per 10,000 for the S3 encrypt and decrypt shape, $0.15 per 10,000 for the ECC signing shape. Then we either cache a data key inside a threshold or we remove the per-object call. The pricing page is the source for the dollars. The Encryption SDK page is the source for the default of one data key per operation.
Frequently Asked Questions
What is included before AWS KMS API request cost starts?
The free tier is 20,000 requests a month across Regions. The S3 example subtracts that allotment before it applies $0.03 per 10,000 requests. Asymmetric Sign, Verify, Encrypt, Decrypt, and GetPublicKey, plus the data-key-pair APIs, are excluded from the free tier. The signing example prices 100,000 requests at $0.15 per 10,000 with no free-tier subtraction.
Does a customer managed key include the API calls?
Key storage is $1 a month, prorated hourly, for a customer managed key, and API requests are a separate charge. AWS managed keys skip the storage charge and still bill API requests. Data keys have no monthly storage charge beyond the API call, so removing the $1 line leaves the request line in place.
When does data key caching change the request count?
By default the AWS Encryption SDK generates a new data key for every encryption, which is a KMS request per object. A caching cryptographic materials manager reuses a cached data key and skips that call when the cache hits, inside thresholds you set. The documentation treats caching as optional and says to keep the reuse as small as the cost or latency goal requires.
Do key rotations add request fees?
The pricing page prices rotation as extra key storage: $1 a month for the first rotation and $1 a month for the second, then no further storage add. That is independent of the $0.03 request example. A rotation does not refund decrypt calls against older ciphertext. Schedule a key for deletion and the monthly storage charge stops until you cancel the deletion.
Who pays when the key lives in another account?
The account that makes the API request pays for the key use. The account that owns a customer managed key pays the $1 storage charge. A producer that encrypts with a central key should expect the request line on the producer bill. We split the two charges in the review so the hot path has an owner.
Ask for an AWS bill review that separates the $1 key from per-object API calls. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.