AWS KMS Pricing for Multi-Account Teams in 2026

A $1 key rarely makes the service expensive. A busy data pipeline can issue millions of cryptographic operations, turning a small line item into a FinOps investigation.

For multi-account organizations, AWS Key Management Service (AWS KMS) pricing depends on where keys live and which accounts make requests. Fixed costs are predictable, but AWS KMS pricing often shifts with request volume, not just key count. Customer managed keys, AWS managed keys, and AWS owned keys each have different cost considerations.

Start with a model that separates fixed key fees and key rotation from variable usage charges.

Key Takeaways

• AWS KMS costs combine fixed customer managed key charges, rotation fees, request charges, and optional custom key store infrastructure. Customer managed keys cost $1 per key per month, while the first two rotation events can increase the capped monthly charge to $3 per key.
• KMS request volume can exceed key storage costs, especially for high-volume Amazon S3 SSE-KMS reads. Standard symmetric requests cost $0.03 per 10,000 requests after the shared 20,000-request monthly allowance.
• In multi-account environments, the account that owns a customer managed key pays storage and rotation charges, while the account generating cross-account requests pays the usage charges. Use separate ledgers for fixed ownership costs and workload-driven request costs.
• S3 bucket keys can reduce KMS requests for SSE-KMS workloads by up to 99%, but teams must test encryption-context conditions, replication, cross-account access, and existing-object migration before enabling them broadly.
• Price asymmetric operations, multi-Region replicas, AWS CloudHSM custom key stores, and external key stores separately because their rates and infrastructure costs differ from standard symmetric KMS usage.

AWS KMS pricing: build the cost model first

AWS prices vary by Region, so treat the figures below as standard commercial AWS reference rates. Confirm the selected Region on the official AWS KMS pricing page before approving a forecast. GovCloud, China Regions, and custom hardware options require their own rate cards.

The fixed-cost model starts with customer managed keys. Variable API requests and custom infrastructure complete the forecast.

The base model has two parts:

Monthly KMS cost = key storage and key rotation charges + request charges + custom key store infrastructure

Custom key stores and AWS CloudHSM infrastructure need separate forecasting. Those hardware security modules can add costs outside the basic model.

The pricing examples below cover the charges that affect most platform teams.

Customer managed keys: key storage and rotation charges

A $1 monthly charge applies to each customer managed key, prorated by the hour. That fee applies to symmetric keys, asymmetric keys, imported key material, replicated key types, keys in custom key stores, and keys backed by an external key store.

Multi-Region keys aren’t a single $1 item. The primary and every replica are billed as separate customer managed keys.

Key rotation also changes the fixed cost. The first and second rotations each add $1 per month, whether they use automatic key rotation or on-demand rotation. AWS caps the combined charge at $3 per key per month, even after later rotations.

For example, assume a security account owns 60 customer managed keys across all Regions. Twelve keys have been rotated once.

Fixed monthly charge = (60 x $1) + (12 x $1) = $72 per month

That $72 is predictable. The request component needs closer attention.

AWS managed keys are created and controlled by AWS services. AWS owned keys are also service-controlled, and AWS services may use AWS owned keys without exposing them to your team. Neither type has a monthly storage charge, although usage beyond the monthly allowance can still be billable. The AWS KMS key documentation explains the operational distinction between customer managed, AWS managed, and AWS owned keys.

API request charges and the 20,000-request allowance

Most common cryptographic operations use the standard request rate for symmetric keys. This category includes calls such as Encrypt, Decrypt, ReEncrypt, GenerateDataKey, and GenerateDataKeyWithoutPlaintext.

After the free tier, the calculation is:

Standard API requests charge = (eligible requests above 20,000 / 10,000) x $0.03

If one account makes 9,000,000 eligible symmetric requests in a month:

(9,000,000 - 20,000) / 10,000 x $0.03 = $26.94

Treat the free tier as shared across the account’s Regions. Don’t allocate 20,000 free requests to every Region in a chargeback model.

Asymmetric keys need a separate line in the forecast. AWS does not apply that allowance to asymmetric Encrypt, Decrypt, Sign, Verify, GetPublicKey, GenerateDataKeyPair, or GenerateDataKeyPairWithoutPlaintext requests. Pricing also depends on the algorithm and operation.

RSA key-pair generation can cost as much as $12 per 10,000 requests in the commercial KMS rate card. That is materially different from the $0.03 standard symmetric rate. Record asymmetric signing, verification, encryption, decryption, and key-pair generation as separate usage categories instead of applying the symmetric request rate to all cryptographic calls.

Allocate KMS costs across AWS accounts before centralizing keys

AWS Organizations makes it possible to centralize key administration, but it doesn’t automatically centralize every KMS cost. The security account that owns customer managed keys pays its monthly key storage and rotation fees. The account making a cross-account KMS request pays the request charge.

That split can surprise teams after they move keys into a central security account. Security sees a stable key-storage bill, while application accounts retain the variable cost of data access.

A good internal model separates costs into two ledgers:

• The security or shared-services account owns fixed charges for customer managed keys, replicas, and rotations. It controls the central key rotation schedule and any automatic key rotation settings.
• Application accounts own request charges caused by their workloads, including AWS service calls on their behalf.
• The platform team reports both views, because a key’s ownership account alone doesn’t explain the total business cost.

Replicas of multi-Region keys remain separate billable resources, even when administration is centralized. Don’t assign AWS managed keys or AWS owned keys the same ownership and storage treatment as customer-managed resources. AWS managed keys are managed by AWS within an account, while AWS owned keys are controlled by AWS services. AWS owned keys therefore don’t create a separate customer account storage charge.

The following pricing examples assume a centralized security account owns the 60 keys from the earlier example. Application account A makes 9 million standard symmetric requests; other accounts remain within their free tier allowance, not duplicated per Region.

This example excludes asymmetric requests, CloudHSM infrastructure, third-party key-store costs, and service-specific charges. It also assumes all 9 million requests qualify for the standard symmetric rate.

Use account boundaries to make ownership clear, not to conceal demand. A workload team should see the cost of retrieving encrypted objects, even when a security team manages the key policy and rotation schedule.

Key policies need careful design. Grant only the application roles and AWS service principals that need the key, then restrict access with conditions such as organization ID, encryption context, source account, and source ARN where supported. These key policies are resource-based controls, unlike identity-based IAM policies. Broad cross-account key policies can turn a central key into an untraceable shared dependency.

Amazon S3 can turn KMS request volume into the main bill

Amazon S3 with SSE-KMS is a frequent source of KMS cost spikes. The trigger is often a wide analytics read, not a new encryption project.

A distributed Spark, Trino, Athena, or ETL job can open huge numbers of Parquet files. Reading an encrypted object can cause S3 to request Decrypt from KMS, generating KMS API requests. Small files, repeated scans, retries, and wide partition layouts multiply that traffic.

Encryption settings affect both visibility and billing. The result differs for customer managed keys, AWS managed keys, and AWS owned keys. Key rotation changes key material, but it doesn’t reduce excessive object-read request volume.

Suppose a workload causes one standard billable KMS request for each of 200 million object reads. The two pricing examples below use the 20,000-request free tier:

(200,000,000 - 20,000) / 10,000 x $0.03 = $599.94

That calculation is only a workload estimate. Actual calls depend on access patterns, caching, retries, service behavior, and encryption setup. Still, it shows why a $1 key can sit beside a much larger KMS request charge.

Use S3 bucket keys for high-volume SSE-KMS data

S3 bucket keys reduce the number of KMS requests that S3 sends for SSE-KMS objects. Instead of calling KMS for every object-level encryption operation, Amazon S3 uses a bucket-level key to derive a data encryption key for each object. AWS states that this can reduce KMS request costs by up to 99%.

If the same 200 million-read workload achieved a 99% reduction in KMS calls, the directional estimate becomes:

Estimated requests after reduction = 200,000,000 x 1% = 2,000,000

(2,000,000 - 20,000) / 10,000 x $0.03 = $5.94

The savings depend on the actual access pattern, so measure before using the result as a budget commitment.

S3 bucket keys change the KMS encryption context from an object ARN to a bucket ARN. Key policies that require an object-level S3 encryption context can block access after the change.

Enable S3 bucket keys for new writes, then test application access, replication, cross-account reads, and restrictive encryption conditions. Existing SSE-KMS objects don’t gain Bucket Key behavior merely because you update bucket defaults.

Re-encrypting old objects requires a copy or rewrite operation. For large estates, Amazon S3 Batch Operations can manage that work. Forecast the migration because copying objects creates S3 activity and can create temporary KMS request volume.

For application-side encryption, data key caching with the AWS Encryption SDK can reduce requests when your applications use envelope encryption directly. The AWS Encryption SDK supports data key caching, with strict age, byte, and message limits. Use the AWS Encryption SDK with protected process memory for the cached plaintext data encryption key, not to mask inefficient object layouts.

Price asymmetric keys, AWS CloudHSM, and external key stores separately

Symmetric keys fit most encryption-at-rest workloads. They support high-throughput envelope encryption and use the familiar $0.03 rate per 10,000 requests. Customer managed keys can be either family, but operation pricing differs.

Asymmetric keys fit different needs, such as digital signatures, client-side encryption with public keys, and verification by parties that should never access private key material. They aren’t interchangeable with symmetric SSE-KMS encryption.

Evaluate multi-Region keys separately, since replicas and regional design add another decision.

For asymmetric keys, use the operation-level price table for the selected Region and key specification. A model should separate these request groups:

• Sign and Verify activity for application signatures.
• Encrypt and Decrypt activity with RSA encryption keys.
• GenerateDataKeyPair and GenerateDataKeyPairWithoutPlaintext activity, especially for RSA, rather than ordinary envelope encryption with a data encryption key.
• Public-key retrieval calls when clients don’t cache public key material safely.

An application that verifies 500 million signatures should not use the symmetric request formula. Nor should a certificate or token service that generates RSA data key pairs. The higher request price and absence of a comparable offset can change the design decision.

Custom key stores add infrastructure costs beyond normal KMS key and request charges. AWS CloudHSM custom key stores require a cluster of hardware security modules. If FIPS 140-2 is part of the control requirement, account for those hardware security modules and verify the selected Region and configuration.

In us-east-1, AWS CloudHSM has been priced at about $1.60 per HSM hour. A two-HSM monthly estimate using 730 hours is:

2 HSMs x 730 hours x $1.60 = $2,336 per month

This figure excludes KMS key charges, KMS request charges, backups, data transfer, and other infrastructure. It shows why this option should satisfy a hard control requirement, not a routine desire for a different key hierarchy. It also doesn’t remove key rotation responsibilities.

An external key store has a similar planning issue. AWS KMS still charges for the KMS key and requests, while the external key store’s XKS proxy, external key manager, network connectivity, support contract, and availability design sit outside that KMS line item. The same separation applies to custom key stores, whose cluster and connectivity costs sit outside the KMS line item.

Find request surges with AWS CloudTrail, Amazon Athena, and cost data

Cost Explorer can show which account and Region drove a KMS increase. It can’t always explain the workload behavior behind that increase. AWS CloudTrail can.

Send organization-level AWS CloudTrail logs to a dedicated log archive account, then query them with Amazon Athena. Filter for eventSource = kms.amazonaws.com, then group by event name, account IDs, Region, key ID, user agent, and time period.

Focus on high-volume cryptographic operations such as Decrypt, Encrypt, ReEncrypt, GenerateDataKey, and GenerateDataKeyWithoutPlaintext. A sudden concentration of Decrypt events with an S3 user agent often points to object-read activity. A surge in GenerateDataKey can indicate a write-heavy pipeline or a service integration change.

Use a short investigation sequence:

1. Identify the account, Region, and day where KMS request costs changed in Cost Explorer or the Cost and Usage Report.
2. Query CloudTrail with Amazon Athena for KMS events during that window, grouped by eventName, userAgent, and key identifier.
3. Match the calling service or role to a deployment, analytics job, replication task, application release, or key rotation change.
4. Compare the event count with the pricing formula, then validate the likely fix in a non-production account.

CloudTrail log collection has a cost of its own. KMS events are management events, while Amazon S3 object activity is data-event logging. Keep those decisions separate. Use advanced event selectors to narrow high-volume S3 data events when they aren’t required, but retain the KMS management events needed for security and cost investigations.

The AWS KMS service overview is a useful reference when mapping which AWS services call KMS and which keys they can use.

Establish a monthly KMS FinOps routine

Review key inventory before reviewing spend. Remove stale customer managed keys from development, check forgotten multi-Region keys and replicas, and record key rotation status. Confirm whether AWS managed keys still support active resources. AWS owned keys are controlled by AWS, so customers cannot delete them. Include recurring key storage charges, AWS CloudHSM deployments, and custom key stores in the inventory. Review each key rotation schedule, and use automatic key rotation where it fits policy requirements.

Then review request patterns by account and Region. Set AWS Budgets alerts for KMS spend, and define a percentage or dollar threshold that triggers a workload review. A daily alert is more useful than waiting for the monthly invoice when a query engine starts reading hundreds of millions of objects. Use the threshold to investigate key rotation changes before they become recurring spend.

Finally, treat key tags as governance data, not perfect request-cost allocation. Tag customer managed keys with owner, environment, system, data classification, and rotation purpose. Pair those tags with account-level cost reports and AWS CloudTrail evidence when assigning responsibility. Record the tagged service owner in key policies, and keep AWS owned keys separate from customer accountability decisions.

Frequently Asked Questions

How much does an AWS KMS customer managed key cost?

A customer managed key costs $1 per month, prorated hourly. The first and second key rotation events each add $1 per month, with the combined storage and rotation charge capped at $3 per key per month.

Does AWS KMS charge for every cryptographic request?

Standard symmetric requests use a shared allowance of 20,000 eligible requests per month, after which the rate is $0.03 per 10,000 requests. Asymmetric operations have separate pricing and generally should not be estimated with the standard symmetric formula.

Which account pays for cross-account AWS KMS requests?

The account that owns the customer managed key pays its storage and rotation charges. The account generating a cross-account request pays the associated KMS request charge, so centralized key ownership does not centralize all costs.

Can Amazon S3 bucket keys reduce AWS KMS costs?

Yes. S3 bucket keys reduce the number of KMS requests generated for SSE-KMS objects and can lower request costs by up to 99% in suitable workloads. Test encryption-context policies, replication, cross-account access, and existing-object migration before relying on the projected savings.

Are AWS CloudHSM and external key stores included in KMS pricing?

No. KMS key and request charges still apply, while CloudHSM clusters, XKS proxies, external key managers, connectivity, support, and related infrastructure require separate forecasting. These options should be modeled independently from standard KMS charges.

Conclusion

AWS KMS costs stay predictable when teams separate the fixed ownership costs of customer managed keys from workload-driven requests. The biggest savings come from reducing unnecessary cryptographic calls, especially for high-volume Amazon S3 reads. Include key rotation in the fixed-cost review.

For multi-account teams, central ownership of customer managed keys should come with clear request-cost accountability. KMS request counts, not key count alone, should drive monthly reviews, and AWS owned keys have different governance boundaries.