What Is AWS KMS? Keys, Key Policies, and Pricing

Definition

AWS Key Management Service (AWS KMS) is a managed service for creating and controlling the encryption keys that protect your data across AWS. Key material lives inside FIPS 140-2 / 140-3 validated hardware security modules (HSMs) and never leaves them for symmetric keys — you call the KMS API to encrypt, decrypt, sign, or generate data keys, and every call is logged to CloudTrail.

In practice KMS is the piece that makes "encryption at rest" a checkbox rather than a project. More than 100 AWS services — S3, EBS, RDS, DynamoDB, Lambda, Secrets Manager — accept a KMS key at resource creation and handle the cryptography for you. Costs are deliberately simple: $1 per customer-managed key per month plus $0.03 per 10,000 requests, with 20,000 requests a month free forever.

Three things account for most of the confusion people hit with KMS, and each gets its own section below: the difference between customer-managed, AWS-managed, and AWS-owned keys; how key policies differ from IAM policies (an IAM policy alone can never grant access to a key); and envelope encryption with data keys, which is what keeps request costs from exploding.

How It Works

KMS exposes two categories of keys: symmetric (AES-256-GCM, the default and most common) and asymmetric (RSA or ECC key pairs for sign/verify or encrypt/decrypt). The primary key material of a symmetric KMS key never leaves HSMs; all encrypt/decrypt calls flow through the KMS API.

For real-world bulk data, AWS services use envelope encryption: KMS generates a data key (a plaintext AES key plus a KMS-encrypted copy), hands both to the calling service, and the service encrypts the bulk data with the plaintext data key locally, stores the encrypted data key next to the ciphertext, and discards the plaintext data key from memory. To decrypt, the service calls KMS to decrypt the encrypted data key, then uses it to decrypt the data. This avoids sending terabytes of data through the KMS API while still giving KMS full control over who can ultimately decrypt.

Key Types

• Customer managed keys (CMKs) — you create, configure, and own. You write the key policy, enable/disable, schedule deletion, and choose whether to enable automatic rotation. Visible in the KMS console. Billed $1/month each.
• AWS managed keys — created on your behalf by AWS services (e.g., aws/s3, aws/ebs). Free to use, you cannot modify their key policy, and they are unique per account per Region. Visible in the KMS console, prefixed with aws/.
• AWS owned keys — owned and used by AWS services across many accounts. Not visible in your account, not billed. Used when you don't pick a specific key (for example, DynamoDB default encryption).

Additional key kinds include multi-Region keys (a primary plus replicas with identical key material for cross-Region disaster recovery), HMAC keys (for symmetric message authentication), and external keys / XKS (key material stored in your own external HSM, with KMS as the proxy).

AWS KMS Key Policies Explained

Every KMS key has exactly one key policy, and that policy — not IAM — is the ultimate authority over who can use the key. This is the single biggest difference between KMS and most other AWS services, and the source of most "access denied" tickets involving encryption.

In a normal service, attaching an IAM policy that allows an action is enough. With KMS it is not: if the key policy does not allow the principal, the request is denied no matter what IAM says. Access requires permission in the key policy and, for principals reached indirectly, in IAM.

The default key policy

When you create a key without specifying a policy, KMS applies a default that delegates control back to your account:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableIAMUserPermissions",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
      "Action": "kms:*",
      "Resource": "*"
    }
  ]
}

Two details trip people up here. First, :root does not mean the account root user — it means "this AWS account and its administrators", and it is what allows IAM policies in the account to grant access to the key. Second, "Resource": "*" does not mean "all keys"; in a key policy the asterisk means "the key this policy is attached to."

Required elements of a key policy statement

| Element | Required | Notes | | --- | --- | --- | | Version | Yes | Must be 2012-10-17 | | Effect | Yes | Allow or Deny. Access is implicitly denied if not allowed | | Principal | Yes | Accounts, IAM users, IAM roles, some AWS services. IAM groups are not valid | | Action | Yes | e.g. kms:Encrypt. A statement without Action silently has no effect | | Resource | Yes | Always "*" — meaning this key | | Sid | No | Unlike IAM, may contain spaces | | Condition | No | Supports KMS condition keys such as kms:ViaService, kms:CallerAccount, and tag/alias conditions for ABAC |

A key policy document can be up to 32 KB. A quiet failure mode worth knowing: if you omit Action or Resource, the CreateKey and PutKeyPolicy APIs succeed anyway and produce a statement that does nothing — only the console flags the error.

Key policies vs IAM policies vs grants

• Key policy — resource-based, attached to the key, always evaluated. The only mechanism that can grant cross-account access to a key.
• IAM policy — identity-based, only effective if the key policy has delegated to the account. Good for "this role may use any key tagged env=prod".
• Grants — programmatic, temporary, narrowly-scoped permissions, typically created by AWS services on your behalf for operations like copying an encrypted snapshot. They avoid rewriting the key policy for short-lived delegation and can be retired when done.

Grants are a lightweight alternative for temporary delegation; key policies are for durable permissions; IAM policies are for organizing access at scale once the key policy has opened the door.

Key Features and Limits

• Pricing — $1.00 per month per customer-managed key (prorated hourly), plus $1/month for each of the first two rotations. API requests: $0.03 per 10,000 (symmetric), $0.15 per 10,000 for asymmetric signing.
• Free Tier — 20,000 KMS requests per month across all Regions are free, forever (symmetric operations only). AWS managed keys carry no storage charge; you pay only for their API requests.
• SLA — 99.999% monthly uptime per Region.
• Automatic rotation — symmetric CMKs support automatic annual rotation (opt-in; default 365 days, configurable 90–2,560 days as of 2023). Rotation generates new backing material and keeps older material around to decrypt historical ciphertext; the key ID and ARN stay the same.
• Key deletion — scheduled deletion has a waiting period of 7 to 30 days (default 30). Once deleted, the key is unrecoverable and all data encrypted under it is permanently lost.
• Key spec options — SYMMETRIC_DEFAULT (AES-256-GCM), RSA (2048/3072/4096), ECC (NIST P-256/P-384/P-521, SECG P-256K1), SM2 (China Regions), HMAC (224/256/384/512).
• Request rate — KMS API has per-Region request quotas (e.g., 10,000/s for cryptographic operations in commercial Regions; higher for data key operations). Quotas are raisable via Service Quotas.
• Cross-account sharing — a key policy can grant a principal in another account access; the other account's IAM policies still need to allow the calls.
• Encryption context — an optional set of key-value pairs passed to KMS that is bound to the ciphertext and logged to CloudTrail. Widely used by AWS services (e.g., S3 passes the bucket and key as context).
• CloudTrail integration — every KMS API call (including Encrypt / Decrypt / GenerateDataKey) is logged, enabling complete audit of key usage.

Common Use Cases

1. Default encryption for AWS services — S3 bucket SSE-KMS, EBS volume encryption, RDS database encryption, DynamoDB default encryption.
2. Envelope encryption in applications — call GenerateDataKey from Lambda or EC2, encrypt bulk data locally, store encrypted data + encrypted data key.
3. Secrets protection — AWS Secrets Manager encrypts every secret with a KMS key; the same pattern applies to SSM Parameter Store SecureString parameters.
4. Client-side encryption SDKs — AWS Encryption SDK, S3 Encryption Client, and DynamoDB Encryption Client use KMS as their root key provider.
5. Digital signing — use an asymmetric KMS key to sign JWTs, software artifacts, or documents without exposing the private key.
6. Disaster recovery — multi-Region keys replicate across Regions so that data encrypted in Region A can be decrypted natively in Region B after a failover.

AWS KMS Pricing

| What you pay for | Rate | | --- | --- | | Customer-managed key (any type) | $1.00 per key per month, prorated hourly | | Each of the first two key rotations | +$1.00 per month each — capped after the second rotation | | API requests (symmetric) | $0.03 per 10,000 requests | | Asymmetric signing operations | $0.15 per 10,000 requests | | Free Tier | 20,000 requests per month, forever, across all Regions | | AWS managed keys (aws/s3, aws/ebs, …) | No storage charge — requests billed at standard rates | | AWS owned keys | Free, and invisible in your account | | External key store (XKS) | $1/key/month plus your own CloudHSM or external HSM costs |

Two subtleties that surprise people on the bill:

• Rotation is not free. The first and second automatic rotations each add $1/month to that key's storage cost. Rotations after the second are not billed, so a long-lived rotating key settles at $3/month rather than growing forever.
• GenerateDataKeyPair and asymmetric operations are excluded from the Free Tier, so the 20,000 free requests only cover symmetric usage.

Multi-Region keys are billed as $1/month per replica — a primary plus two replicas is three keys, not one. Custom Key Stores backed by CloudHSM add HSM cluster costs (roughly $1.45/hour per HSM), which dwarf the KMS charges themselves.

AWS KMS SLA and Availability

AWS KMS carries a 99.999% Monthly Uptime Percentage commitment per Region — one of the strongest availability SLAs AWS publishes, and materially higher than the 99.99% typical of most services. That reflects KMS's position in the dependency graph: if KMS is unavailable in a Region, every service that decrypts data with it is effectively unavailable too.

| Monthly Uptime Percentage | Service credit | | --- | --- | | Less than 99.999% but ≥ 99.0% | 10% | | Less than 99.0% but ≥ 95.0% | 25% | | Less than 95.0% | 100% |

Credits are applied against future KMS charges and must be claimed within two billing cycles — they are not issued automatically.

Two practical notes. The SLA is per Region, so a multi-Region architecture does not inherit a higher number; it just fails independently. And the SLA covers KMS availability, not your request quotas — throttling because you exceeded the per-Region cryptographic operations limit is not an SLA event, which is one more reason to use envelope encryption with data-key caching rather than calling Decrypt on the hot path.

Pros and Cons

Pros

• Deep integration with virtually every AWS service — usually just a key selector.
• FIPS 140-2/140-3 validated HSMs and strong audit via CloudTrail on every operation.
• Simple, predictable pricing ($1/key/month) with a generous free tier for requests.
• Multi-Region keys solve cross-Region DR without rewrapping ciphertext.

Cons

• Key policy syntax is similar to IAM but has unique gotchas (you usually must explicitly delegate to IAM with Principal: root).
• Request quotas can surprise high-throughput workloads; envelope encryption and data-key caching are essential for scale.
• KMS is Region-scoped (except multi-Region keys) — cross-Region replication always re-encrypts unless you planned multi-Region from the start.
• Deleted keys are unrecoverable after the 7–30 day wait; silently orphaned ciphertext becomes permanently unreadable.

Comparison with Alternatives

| Feature | AWS KMS | AWS CloudHSM | AWS Secrets Manager | | --- | --- | --- | --- | | Primary purpose | Managed encryption keys | Dedicated single-tenant HSM cluster | Secret storage + rotation | | Tenancy | Multi-tenant HSMs | Single-tenant HSMs | Managed service (uses KMS internally) | | Pricing | $1/key-month + requests | ~$1.45/hr per HSM | $0.40/secret-month + API calls | | Custom algorithms | Limited | Full PKCS#11 control | N/A | | Best for | Default AWS encryption, app-level envelope encryption | Strict single-tenant compliance, custom crypto | DB credentials, API keys, rotation |

Exam Relevance

KMS appears across:

• Solutions Architect Associate (SAA-C03) — choosing between SSE-S3, SSE-KMS, SSE-C; encrypting EBS snapshots on copy; multi-Region keys for DR.
• Developer Associate (DVA-C02) — envelope encryption, GenerateDataKey, encryption context, encrypting data in Lambda.
• Security Specialty (SCS-C02) — deep key policy evaluation, grants, cross-account key sharing, customer vs AWS managed vs AWS owned trade-offs, automatic rotation semantics.
• Database Specialty, Data Engineer — RDS/Redshift/Aurora encryption, re-encryption of snapshots, cross-account restore.

Classic exam trap: candidates confuse automatic key rotation with re-encrypting existing ciphertext. KMS rotation keeps the key ID and ARN the same and adds new backing material for future encryptions; existing ciphertext is not re-encrypted — older backing material is retained so it can still be decrypted. If a question asks how to force re-encryption, the answer is manual rotation or re-encrypting the data, not enabling automatic rotation.

Common Pitfalls

• Scheduling key deletion is (almost) irreversible. Deleting a KMS key enters a 7–30 day waiting window, and once it fires, every ciphertext encrypted under that key is permanently unreadable. Disable keys instead of deleting when unsure.
• Key-policy lockout. The key policy — not just IAM — governs a key. Remove your own principal from the policy and you can lock everyone, including admins, out of the key with no self-service recovery. Always keep a break-glass admin principal.
• Per-request cost at scale. Calling Encrypt/Decrypt directly on every operation bills $0.03 per 10,000 requests and adds latency. For anything beyond tiny payloads use envelope encryption (a cached data key) so KMS is hit rarely.
• Rotation misconceptions. Automatic annual rotation applies only to symmetric keys and rotates the backing material — old ciphertext still decrypts. Asymmetric and imported-material keys need manual rotation.
• Cross-Region assumptions. A standard KMS key is Regional; a multi-Region key must be explicitly created as such. Copying an encrypted snapshot to another Region re-encrypts under a key there.

A Worked Pricing Example

KMS charges $1 per customer-managed key per month plus $0.03 per 10,000 requests (as of 2026, us-east-1):

• 20 customer-managed keys → $20/month in key storage.
• A service that calls Decrypt directly on 100 million operations/month → 100M ÷ 10,000 × $0.03 = $300/month in requests.
• Switch to envelope encryption with data-key caching (decrypt one data key, reuse it in memory) and those 100M calls collapse to a few thousand — request cost drops to cents.

The lesson: key storage is trivial; request volume is where KMS bills add up, and envelope encryption is the fix.

Frequently Asked Questions

Q: What is the difference between a customer-managed key, an AWS-managed key, and an AWS-owned key?

A: A customer-managed key is one you create and fully control — you write the key policy, enable or disable it, configure rotation, and pay $1/month per key. An AWS-managed key is created on your behalf by an AWS service (names like aws/s3), is free for the key itself but billed per API request, and you can't modify its key policy. An AWS-owned key belongs to AWS across many accounts, isn't visible in your account, and is free — used when you don't select a specific key (e.g., DynamoDB default encryption).

Q: What is envelope encryption, and why does KMS use it?

A: Envelope encryption encrypts data with a locally-generated data key and then encrypts that data key with a KMS key (the wrapping key). The encrypted data key is stored alongside the ciphertext. This avoids pushing terabytes of data through KMS (which is rate-limited and has a maximum 4 KB payload for direct Encrypt/Decrypt) while keeping key control centralized: to decrypt, the service calls KMS to unwrap the data key, then decrypts the bulk data locally. AWS services like S3, EBS, and RDS all use envelope encryption internally.

Q: What is a KMS data key, and how is it different from a KMS key?

A: A KMS key lives inside the HSM and never leaves it. A data key is a regular AES key that KMS generates for you and hands back in two forms: plaintext, and encrypted under the KMS key. You encrypt your bulk data locally with the plaintext copy, throw the plaintext away, and store the encrypted copy next to the ciphertext. Later you send the encrypted copy back to KMS to unwrap it. GenerateDataKey returns both copies; GenerateDataKeyWithoutPlaintext returns only the encrypted one, which is useful when the component creating the key isn't the one that will encrypt. Data keys are what make it economical to encrypt terabytes — you pay for one KMS request, not one per megabyte.

Q: How does automatic key rotation in KMS actually work?

A: When automatic rotation is enabled on a symmetric customer-managed key, KMS generates new backing key material on a schedule (365 days by default, configurable 90–2,560 days since 2023). The key's ID, ARN, and key policy remain unchanged, so integrations keep working. Existing ciphertext is not re-encrypted — KMS stores all prior backing material so older ciphertext can still be decrypted. To actually re-encrypt data, you must re-read and re-write it yourself or use a service-level re-encryption feature.

Q: How do I avoid high AWS KMS request costs?

A: Use envelope encryption: call KMS once to generate or decrypt a data key, then use that data key locally to encrypt/decrypt your actual data, caching it in memory (the AWS Encryption SDK's data-key caching does this for you). This turns millions of KMS API calls into a handful, cutting request charges from hundreds of dollars to near zero while keeping the master key in KMS.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS KMS documentation before making production decisions.