KMS pricing: what to model (keys + requests)

Start with a calculator if you need a first-pass estimate, then use this guide to validate the assumptions and catch the billing traps.

Use this page when you need to decide what belongs inside the KMS bill model before you argue about optimization. This is the AWS KMS request and key-boundary page.

Stay here when the question is keys, request volume, and caller behavior rather than the wider security system. Go back to the security parent page if the broader security spend diagnosis is still unclear.

KMS pricing inputs

• Key-months: CMKs per month by environment.
• Requests/month: Encrypt/Decrypt/GenerateDataKey.
• Key type: symmetric vs asymmetric request rates.

What to model

• Keys (key-month): how many customer-managed keys you maintain (often per environment/account/region).
• Requests/month: Encrypt/Decrypt/GenerateDataKey-style API calls across all callers.
• Request mix: if pricing differs by operation or tier, use a blended $ per 10k requests for a first pass.

Tool: AWS KMS cost calculator

Inside the KMS bill vs outside the KMS bill

• Inside the KMS bill: key-month charges, Encrypt or Decrypt or GenerateDataKey style request charges, and service-triggered KMS calls that still land on KMS usage.
• Usually outside the KMS bill: the storage, compute, or secret-management service costs that happen to call KMS as part of a broader workflow.
• Why that boundary matters: teams often blame KMS for the whole workflow bill when the real multiplier sits in caller behavior or the adjacent service pattern.

Step 1: inventory keys (it’s usually the easy part)

• Count keys by environment (prod, stage, dev) and by region.
• Note key “sprawl” patterns: key-per-team, key-per-tenant, key-per-service.
• Write down your intended rotation and lifecycle policy (create, rotate, deprecate, delete).

Step 2: estimate request volume (this is usually the real driver)

Start with the question: what in your architecture causes a KMS call? Common sources:

• Hot-path decrypt: decrypting data or secrets on every request instead of caching.
• Too-frequent data key generation: generating a new data key per small unit of work.
• High-frequency background jobs: short-interval jobs that each perform crypto operations.
• Retry storms: timeouts and retries multiply API calls during incidents.

Guide: estimate KMS requests per month

Step 3: sanity-check the estimate with a “cost per 1M units” view

Convert your model into “KMS requests per 1M app requests” or “KMS requests per 1M objects”. This makes it easier to spot bad assumptions and helps you communicate trade-offs (for example, a 5× increase in decrypt calls).

Common pitfalls

• Assuming KMS is “mostly keys” and missing request-driven spend.
• Fetching/decrypting secrets per request without caching.
• Generating data keys too frequently (per record or per small message) instead of per session/batch.
• Forgetting non-prod traffic still creates request charges (especially always-on dev/test).
• Ignoring incident retries that multiply KMS API calls.

How to validate after you deploy

• In Cost Explorer/CUR, filter to KMS and group by usage type to confirm key-month vs request drivers.
• Use CloudTrail event history for KMS API calls to identify top callers and operations.
• Compare “requests per app request” before/after changes (caching, batching, retries).

When this is not the right page

• If you still need to decide whether WAF, KMS, secrets, or audit logging is the main security cost surface, go back to security costs first.
• If your main problem is turning workload units and caller behavior into a defendable request model, go to Estimate KMS requests per month.
• If the request model is already believable and you now need production changes, go to KMS cost optimization.
• If the real question is which caller or service is creating the volume, use the estimate workflow before treating KMS pricing as solved.

Related guides

Sources

• AWS KMS pricing

Related guides

Related calculators

FAQ