AWS KMS in Depth: Multi-Region Keys, Envelope Encryption, Key Policies, and Grants

Most teams treat KMS as a checkbox: tick “encryption at rest,” pick the AWS-managed key, move on. That works until you need cross-Region DR, cross-account data sharing, a key you can prove only one role can use, or 100k decrypts a second on a hot path. At that point KMS stops being a checkbox and becomes an authorization system with a latency budget and a request quota. This guide treats it that way — the key types, how envelope encryption actually moves bytes, multi-Region keys, the three-layer authorization model, and the operational edges (rotation, quotas, audit) that bite at scale.

The single most important fact, the one every later decision falls out of: your plaintext almost never goes to KMS, and KMS key material never leaves KMS. A KMS key (the CMK, formally a “KMS key”) is a logical reference to material that lives inside FIPS 140-3 validated HSMs. You cannot export it. What you can do is ask KMS to wrap and unwrap small blobs — and the standard pattern is to have KMS wrap a data key that you then use locally to encrypt the actual payload. That is envelope encryption.

By the end you will stop guessing about encryption design. When someone asks “can the DR Region read this?”, “who can actually call Decrypt on that key?”, or “why is the KMS bill suddenly four figures?”, you will know the mechanism, the exact CLI to confirm it, and the fix. Because this is a reference you will return to mid-incident, the key types, the conditions, the limits, the errors and the cost levers are all laid out as scannable tables — read the prose once, then keep the tables open when the pager goes off.

What problem this solves

Encryption-at-rest is easy to enable and hard to get right the moment your data or your blast radius crosses a boundary. The defaults — AWS-managed keys, a Region-locked CMK, no encryption context, a wide-open key policy delegated to IAM and never tightened — work in a single account, in a single Region, with one team, until exactly one of those assumptions breaks. Then you discover that an AWS-managed key cannot be shared cross-account, that a Region-scoped ciphertext is unreadable in your DR Region even though the bytes replicated fine, or that a hot path calling GenerateDataKey per object is throttling and running up a four-figure monthly bill.

What breaks without this knowledge: a team enables a DynamoDB global table, replicates client-side-encrypted PAN data to a second Region, runs a failover game-day, and cannot decrypt a single replicated record — the worst kind of DR failure, because it looks healthy until you cut over. Or an auditor asks “prove only the payments role can decrypt cardholder data,” and the answer is a key policy delegated to account root with no kms:ViaService or EncryptionContext constraint, so the honest answer is “anyone in the account with the right IAM can.” Or a launch melts under ThrottlingException because nobody enabled S3 Bucket Keys or raised the request-rate quota ahead of time.

Who hits this: any team with cross-Region DR of encrypted data, cross-account data sharing, a compliance regime that demands provable key isolation, or a high-throughput encryption path. It bites hardest on active-active applications with global tables (multi-Region key portability), regulated workloads (encryption context and least-privilege key policies), and anything that calls KMS per object (quota and cost). The fix is almost never “turn on a bigger key” — it is “make the key portable where ciphertext travels, scope authorization to the exact caller and context, and architect the call volume down.”

To frame the whole field before the deep dive, here is every problem class this article covers, the question it forces, and where to look first:

Learning objectives

By the end of this article you can:

• Explain why KMS never encrypts bulk data and design envelope encryption with data keys so plaintext and key material both stay where they belong.
• Choose the right key type (symmetric, asymmetric, HMAC, multi-Region) and management model (AWS-owned, AWS-managed, customer-managed) deliberately, knowing which choices are immutable one-way doors.
• Architect multi-Region keys for DR and active-active, scope each replica’s policy independently, and run a ReEncrypt backfill of pre-existing ciphertext.
• Reason fluently about the three-layer authorization model — key policy vs IAM vs grants — and know why a KMS key policy that omits IAM delegation makes IAM ignored.
• Build cross-account encrypted sharing (S3, EBS snapshots) as a two-sided handshake and explain why missing either side fails closed.
• Use encryption context, kms:ViaService, aws:PrincipalOrgID and ABAC conditions to pin a key to an exact caller, service, and context — and prove it from CloudTrail.
• Manage rotation, request quotas, and cost: enable automatic rotation, use S3 Bucket Keys and data-key caching to crush per-object calls, and raise the request-rate quota before a launch.

Prerequisites & where this fits

You should be comfortable with IAM policy evaluation (identity vs resource policies, explicit deny wins, condition keys), basic AWS CLI (--query, JSON output, fileb://), and the idea of at-rest vs in-transit encryption. You should know what an ARN is and how cross-account access works in principle. Familiarity with AES-GCM and the words “symmetric” and “authenticated encryption” helps but isn’t required — the article defines what it needs.

This sits in the Security & Cryptography track. It assumes the identity fundamentals from AWS IAM Fundamentals: Users, Roles, Policies & the Evaluation Engine and the least-privilege patterns in IAM Least Privilege: Permission Boundaries & Inescapable Ceilings, because a key policy is just a resource policy and the three-layer model is IAM evaluation with the key policy as the root of trust. It is upstream of every storage deep-dive: S3 storage classes, versioning, lifecycle & encryption, EBS, EFS & FSx, and RDS & Aurora all consume KMS for SSE. It pairs with Secrets Manager & Parameter Store (both wrap their secrets under a CMK), CloudTrail, Config & audit (where every Decrypt lands), and at org scale with Organizations: SCPs, guardrails & delegated admin and Resource Control Policies & the data perimeter.

A quick map of who owns which layer during an encryption design or incident, so you call the right person fast:

Core concepts

Six mental models make every later decision obvious.

KMS is a wrapping and authorization service, not a bulk cipher. Two API verbs anchor the whole service. Encrypt/Decrypt send up to 4 KB of plaintext/ciphertext and KMS does the crypto — fine for small secrets, wrong for large objects. GenerateDataKey mints a fresh symmetric data key and returns it to you both in plaintext and wrapped under your KMS key; you encrypt your gigabytes locally with the plaintext copy, throw it away, and store only the ciphertext payload plus the wrapped blob. Every design decision — quotas, caching, multi-Region portability — falls out of “KMS protects the key that protects the data.”

The key policy is the root of trust, not IAM. Unlike S3, where an IAM policy alone can grant access, a KMS key policy that does not delegate to IAM means IAM policies are ignored. The key policy is authoritative. This single fact is responsible for most KMS lockouts and most “why is my Decrypt denied when IAM clearly allows it” tickets.

KeySpec and KeyUsage are immutable. You choose symmetric vs asymmetric vs HMAC, and encrypt-vs-sign, at creation, and you can never change them. Picking wrong means creating a new key and re-encrypting. Treat key creation as a one-way door.

A normal key is Region-locked; ciphertext is portable only with a multi-Region key. Ciphertext produced in eu-west-1 can only be decrypted by calling KMS in eu-west-1. If that Region is down, the data is unreadable even though the bytes replicated elsewhere. Multi-Region keys share the same key material across Regions so an envelope decrypts in any of them — a deliberate availability/isolation trade-off you opt into, not a default.

Encryption context is authenticated, logged, additional data — your cheapest authorization and audit tool. It is not secret and not encrypted, but it is bound to the ciphertext and required, byte-for-byte, at decrypt time, appears in CloudTrail, and can be constrained in policy with kms:EncryptionContext: conditions. It is the difference between “this role can decrypt anything” and “this role can decrypt only tenant=acme invoices.”

Throughput is bounded by a shared, Region-level request-rate quota. Symmetric Decrypt/GenerateDataKey/Encrypt share a per-Region quota (tens of thousands of requests/second depending on Region). A hot path that calls KMS per object hits ThrottlingException long before you expect. The architecture answer is to call KMS less (Bucket Keys, data-key caching), not just to retry harder.

The vocabulary in one table

Before the deep sections, pin every moving part. The glossary at the end repeats these for lookup; this table is the mental model side by side:

1. Key types: pick the right primitive

KMS keys are not interchangeable. The KeySpec and KeyUsage are immutable at creation, so this is a one-way door. Choose the primitive for the job, then never look back.

Orthogonal to spec is who manages the key. This choice is not immutable, but migrating between models means re-encryption, so decide deliberately:

The takeaway: the moment you need an editable policy, cross-account sharing, custom rotation, grants, or independent deletion, you are forced to a customer-managed key. Everything below assumes CMKs. The decision rule in one table:

# A customer-managed symmetric key, with rotation on from day one
aws kms create-key \
  --description "app-prod data-at-rest" \
  --key-spec SYMMETRIC_DEFAULT \
  --key-usage ENCRYPT_DECRYPT \
  --tags TagKey=env,TagValue=prod TagKey=app,TagValue=payments

# Give it a human-friendly alias (aliases are Region-scoped, mutable pointers)
aws kms create-alias \
  --alias-name alias/payments-prod \
  --target-key-id <key-id>

# Terraform equivalent: key + alias + rotation in one place, reviewed in a PR
resource "aws_kms_key" "payments" {
  description             = "app-prod data-at-rest"
  key_usage               = "ENCRYPT_DECRYPT"
  customer_master_key_spec = "SYMMETRIC_DEFAULT"
  enable_key_rotation     = true
  rotation_period_in_days = 180
  deletion_window_in_days = 30
  tags = { env = "prod", app = "payments" }
}

resource "aws_kms_alias" "payments" {
  name          = "alias/payments-prod"
  target_key_id = aws_kms_key.payments.key_id
}

Aliases deserve their own note, because they are the moving part teams misuse. An alias is a Region-scoped, mutable pointer to a key — alias/payments-prod resolves to whatever key it currently targets. That makes manual rotation (repoint the alias to a new key) trivial, but it also means an alias is not a stable identity for audit. The alias quirks worth knowing:

2. Envelope encryption: data keys and the SDK

For anything larger than 4 KB, you encrypt locally with a data key. The raw flow, before any SDK:

# 1. Mint a data key: plaintext + ciphertext (wrapped) come back together
aws kms generate-data-key \
  --key-id alias/payments-prod \
  --key-spec AES_256 \
  --query '{plaintext:Plaintext, wrapped:CiphertextBlob}' \
  --output json
# 2. Encrypt the payload locally with `plaintext` (AES-256-GCM in your app)
# 3. Persist the ciphertext payload + `wrapped` blob; ZERO the plaintext key in memory
# 4. To read: Decrypt(wrapped) -> plaintext key -> decrypt payload locally

The data-key API has variants, and picking the wrong one is a common slip — GenerateDataKeyWithoutPlaintext exists precisely for the case where the minting service shouldn’t see the key (it will be decrypted later, elsewhere):

Rolling your own framing (IV, AAD, key blob, algorithm tags) is where teams introduce vulnerabilities. Use the AWS Encryption SDK — it produces a portable, self-describing message format that bundles the wrapped data key with the ciphertext, handles authenticated encryption, and supports multiple wrapping keys:

import aws_encryption_sdk
from aws_encryption_sdk import CommitmentPolicy

client = aws_encryption_sdk.EncryptionSDKClient(
    commitment_policy=CommitmentPolicy.REQUIRE_ENCRYPT_REQUIRE_DECRYPT
)
key_provider = aws_encryption_sdk.StrictAwsKmsMasterKeyProvider(
    key_ids=["arn:aws:kms:eu-west-1:111122223333:key/<key-id>"]
)

ciphertext, header = client.encrypt(
    source=plaintext_bytes,
    key_provider=key_provider,
    # Encryption context is AAD: authenticated, logged in CloudTrail, NOT secret
    encryption_context={"tenant": "acme", "purpose": "invoice"},
)

Two things that matter at principal level. Key commitment (REQUIRE_ENCRYPT_REQUIRE_DECRYPT, the 2.x+ default) prevents a class of attacks where one ciphertext decrypts to different plaintexts under different keys; do not lower it to interop with ancient clients unless you understand exactly what you give up. And encryption context is your cheapest authorization and audit tool — additional authenticated data that is not encrypted but is bound to the ciphertext, required byte-for-byte at decrypt, logged in CloudTrail, and constrainable in policy. The Encryption SDK options worth knowing:

What encryption context is and isn’t trips up almost everyone the first time. The boundaries:

Caching: trading blast radius for throughput

Calling GenerateDataKey per object is correct but expensive — every write becomes a KMS request against your quota. The data key caching layer in the Encryption SDK reuses a data key across many messages, bounded by max_age, max_messages_encrypted, and max_bytes_encrypted:

from aws_encryption_sdk.caches.local import LocalCryptoMaterialsCache
from aws_encryption_sdk.materials_managers.caching import CachingCryptoMaterialsManager

cache = LocalCryptoMaterialsCache(capacity=1000)
cmm = CachingCryptoMaterialsManager(
    master_key_provider=key_provider,
    cache=cache,
    max_age=300.0,             # rotate the cached data key every 5 minutes
    max_messages_encrypted=1000  # ...or after 1000 messages, whichever first
)

The trade-off is explicit: a larger cache and longer max_age mean fewer KMS calls (cheaper, faster, quota-friendly) but a wider blast radius per data key and weaker cryptographic isolation between messages. Tune it; never leave it unbounded. The knobs and how to reason about each:

3. Multi-Region keys: portability for DR

A normal KMS key is Region-locked: ciphertext produced in eu-west-1 can only be decrypted by calling KMS in eu-west-1. If that Region is down, your data is unreadable even though the bytes are safely replicated elsewhere. Multi-Region keys (MRKs) fix this. A primary and its replicas share the same key material and a related key ID (mrk-...), so ciphertext encrypted under the primary decrypts under any replica — no re-encryption.

# Create the primary as multi-region
aws kms create-key --multi-region \
  --description "global-table encryption primary" \
  --region eu-west-1

# Replicate it into a DR Region (same material, independent policy)
aws kms replicate-key \
  --key-id mrk-1234567890abcdef0 \
  --replica-region us-east-1 \
  --description "global-table encryption replica"

# Terraform: a primary MRK and a replica with its OWN, narrower policy
resource "aws_kms_key" "mrk_primary" {
  provider                 = aws.euwest1
  description              = "global-table encryption primary"
  multi_region             = true
  enable_key_rotation      = true
}

resource "aws_kms_replica_key" "mrk_replica" {
  provider                = aws.useast1
  description             = "global-table encryption replica (decrypt-only app)"
  primary_key_arn         = aws_kms_key.mrk_primary.arn
  policy                  = data.aws_iam_policy_document.replica_decrypt_only.json
}

The nuances that catch people are exactly the things that make MRKs powerful and dangerous:

The single most important caveat, learned the hard way in the scenario below: adopting an MRK does nothing for data already wrapped under a single-Region key. Existing envelopes are bound to the old key in the old Region. Making them portable requires a ReEncrypt backfill. The single-Region vs multi-Region decision, distilled:

4. Key policies vs IAM vs grants: the authorization model

This is where KMS differs sharply from most AWS services and where the dangerous mistakes live. Three layers decide whether a Decrypt succeeds, and the order of trust is not what IAM-first intuition expects:

1. The key policy — the resource policy on the key. It is the root of trust. Unlike S3, where IAM alone can grant access, a KMS key policy that does not delegate to IAM means IAM policies are ignored. The key policy is authoritative.
2. IAM policies — only effective if the key policy enables IAM (the canonical kms:* to the account root statement). With that statement present, IAM grants behave normally.
3. Grants — programmatic, temporary, fine-grained delegations, ideal for AWS services and short-lived workloads.

The three layers side by side, because choosing the wrong instrument is the most common architectural error:

The minimum sane key policy delegates administration and usage to IAM rather than hard-coding every principal:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableIAMRoot",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "KeyUsers",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:role/payments-app" },
      "Action": ["kms:Encrypt", "kms:Decrypt", "kms:GenerateDataKey*", "kms:DescribeKey"],
      "Resource": "*",
      "Condition": {
        "StringEquals": { "kms:EncryptionContext:tenant": "acme" }
      }
    }
  ]
}

The EnableIAMRoot statement is not a backdoor to root credentials — it delegates the decision to IAM in this account. Omit it and you must enumerate every principal in the key policy forever, including the admins who could otherwise fix a lockout. That is the classic way teams brick a key.

The KMS actions you will actually write into policies, grouped by what they let a principal do — least privilege means granting only the row you need:

When to reach for grants

Grants shine where a static policy is wrong. They are issued via API, carry their own constraints, and can be retired the instant the work is done:

aws kms create-grant \
  --key-id <key-id> \
  --grantee-principal arn:aws:iam::111122223333:role/batch-worker \
  --operations Decrypt GenerateDataKey \
  --constraints EncryptionContextSubset={tenant=acme} \
  --retiring-principal arn:aws:iam::111122223333:role/grant-manager

This is exactly the mechanism AWS services use on your behalf: when you attach a CMK to an Auto Scaling group or an encrypted EBS volume, the service creates a grant so it can mint data keys without you widening the key policy. Prefer grants over key-policy edits for service integrations and transient access — they are revocable and don’t bloat the resource policy. The grant constraints and lifecycle, which trip teams up under eventual consistency:

5. Cross-account encryption: S3, EBS, and snapshots

Sharing encrypted data across accounts is a two-sided handshake: the key policy in the owning account must allow the foreign principal, and that principal’s IAM policy in their own account must allow the KMS actions. Missing either side fails closed — and the failure is a generic AccessDenied, not a helpful “the other side didn’t grant you.”

Key policy in the owning account (111122223333):

{
  "Sid": "AllowConsumerAccount",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
  "Action": ["kms:Decrypt", "kms:DescribeKey", "kms:GenerateDataKey"],
  "Resource": "*",
  "Condition": { "StringEquals": { "aws:PrincipalOrgID": "o-exampleorgid" } }
}

IAM policy in the consumer account (444455556666) — note you must name the full key ARN, because the key lives in another account:

{
  "Effect": "Allow",
  "Action": ["kms:Decrypt", "kms:DescribeKey"],
  "Resource": "arn:aws:kms:eu-west-1:111122223333:key/<key-id>"
}

The two-sided requirement is the whole game. Which side does what:

Service-specific edges that matter, because each service layers its own access surface on top of the KMS handshake:

Two edges deserve calling out explicitly. For S3 with SSE-KMS, cross-account reads need the bucket policy, the object’s KMS key policy, and the reader’s IAM all aligned; set the bucket’s default encryption to your CMK and enable S3 Bucket Keys — it caches a bucket-level data key and collapses thousands of per-object KMS calls into a handful, cutting both cost and quota pressure dramatically. For EBS / snapshots, you cannot share a snapshot encrypted with an AWS-managed key cross-account — full stop. Use a CMK, share the snapshot, grant the target account Decrypt + CreateGrant on the key, and the target re-encrypts to their key on copy. This is why production fleets standardize on CMKs for EBS even when defaults would “work.”

# Enable S3 Bucket Keys on a bucket's default SSE-KMS — the single biggest KMS-call reducer
aws s3api put-bucket-encryption --bucket payments-data \
  --server-side-encryption-configuration '{
    "Rules": [{
      "ApplyServerSideEncryptionByDefault": {
        "SSEAlgorithm": "aws:kms",
        "KMSMasterKeyID": "arn:aws:kms:eu-west-1:111122223333:key/<key-id>"
      },
      "BucketKeyEnabled": true
    }]
  }'

6. Key rotation: automatic vs manual

Automatic rotation is the default answer. Enable it and KMS generates new cryptographic material on a schedule (the default is yearly; the rotation period is now configurable down to ~90 days), retaining all prior material so old ciphertext stays decryptable. The key ID, ARN, and policy never change — rotation is invisible to applications.

aws kms enable-key-rotation \
  --key-id <key-id> \
  --rotation-period-in-days 180

aws kms get-key-rotation-status --key-id <key-id>

Crucial subtlety: automatic rotation rotates the KMS key material, but it does not re-encrypt your existing data or your stored data keys. Old envelopes are unwrapped with retained old material; new writes use new material. If your compliance regime demands that data actually be re-wrapped under fresh material, that is a separate, application-driven re-encryption job, not something rotation does for you:

# Conceptual re-encrypt: ReEncrypt swaps the wrapping key without exposing plaintext.
# Plaintext never returns to your process — KMS decrypts and re-wraps internally.
new_blob = kms.re_encrypt(
    CiphertextBlob=old_wrapped_blob,
    SourceKeyId="alias/payments-prod-old",
    DestinationKeyId="alias/payments-prod-new",
    DestinationEncryptionContext={"tenant": "acme"},
)["CiphertextBlob"]

Manual rotation (a brand-new key behind the same alias) is for cases automatic rotation can’t cover: changing key spec, moving to a new Region/account, or responding to suspected compromise where you must invalidate old material. You repoint the alias and run a re-encryption backfill. Asymmetric and HMAC keys historically required this; symmetric keys rarely do. The two models compared:

What rotation does and does not do — the table that prevents a false sense of security:

7. Auditing and controls

Every KMS API call lands in CloudTrail — including Decrypt, with the encryptionContext, the calling principal, and the source IP. This is the highest-signal security telemetry in the account; treat unexpected Decrypt calls as you would unexpected AssumeRole.

Tighten policies with condition keys so a key is usable only in the intended context:

{
  "Sid": "OnlyViaS3FromOrg",
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::111122223333:role/payments-app" },
  "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "s3.eu-west-1.amazonaws.com",
      "aws:PrincipalOrgID": "o-exampleorgid"
    }
  }
}

kms:ViaService pins usage to a specific AWS service (the key can only be used through S3, not by a human running aws kms decrypt). aws:PrincipalOrgID confines cross-account use to your organization. For ABAC, gate Decrypt on tag parity between the principal and the key with aws:ResourceTag / aws:PrincipalTag so access scales with tags instead of hand-written ARNs:

"Condition": {
  "StringEquals": {
    "aws:ResourceTag/project": "${aws:PrincipalTag/project}"
  }
}

The condition keys that turn a wide key policy into a tightly-scoped one — the most useful security lever in KMS:

What to watch for in CloudTrail, and what each signal usually means:

8. Cost and request-quota management

KMS pricing has two parts: roughly $1 per CMK per month (replicas billed separately), and per-request charges with a shared, Region-level request rate quota for cryptographic operations. Symmetric Decrypt/GenerateDataKey/Encrypt share a quota (a few tens of thousands of requests/second depending on Region and key type). A hot path that calls KMS per object will hit ThrottlingException long before you expect.

The levers, in order of impact:

The cost trap is never the $1/month per key. It is millions of unbatched Decrypt calls from a service that should have been using Bucket Keys or a data-key cache. Architect the call volume down first; optimize the bill second.

The throttling-relevant limits and what each means in practice:

Error and limit reference

The KMS errors you will actually see, what they mean, how to confirm, and the fix. The non-obvious ones are AccessDeniedException when IAM looks fine (the key policy didn’t delegate), InvalidCiphertextException from a mismatched encryption context, and KMSInvalidStateException on a key pending deletion or disabled:

The key states a CMK moves through, because several errors above are just “wrong state for this operation”:

Architecture at a glance

The diagram traces the write-then-fail-over path the way bytes actually move, then maps the five places authorization or availability breaks. Read it left to right. A workload needs at-rest crypto, so it calls GenerateDataKey (via the AWS Encryption SDK, with key commitment on and a bounded data-key cache). That call passes through the three-layer authorization stack — the key policy (root of trust, with the EnableIAMRoot delegation), then IAM and grants (effective only because the key policy delegated, scoped by kms:ViaService), then the encryption context check (the AAD that must match byte-for-byte at decrypt). Only if every layer allows does the request reach the multi-Region CMK: an mrk-... primary in eu-west-1 whose material is replicated — not re-encrypted — to a decrypt-only replica in eu-central-1. KMS returns the data key plaintext-and-wrapped; the app encrypts gigabytes locally with AES-256-GCM, zeroes the plaintext, and stores only the ciphertext and the wrapped blob in S3 (Bucket Keys on) or behind a DynamoDB global table that replicates the ciphertext to the second Region.

Notice the two things the diagram is built to teach. First, the dashed replicate-material arrow looping the primary to the replica is the whole DR story: it carries key material, so the same envelope decrypts in either Region — which is exactly why a single-Region key behind a global table produces “replicated-but-unreadable” data (badge 3). Second, every path converges on CloudTrail (every Decrypt, with principal and context) and a quota guard (watching ThrottlingException and request-rate headroom) — the audit-and-protect footer. The five numbered badges sit on the precise hops where it breaks: the key policy locking you out (1), a wrong encryption context failing closed (2), replicated-but-unreadable DR (3), a per-object KMS storm and throttling (4), and an unexpected Decrypt that signals an authorization gap (5). The legend narrates each as symptom, confirm command, and fix.

Real-world scenario

Northwind Pay, a fictional but representative pan-European payments platform, ran active-active in eu-west-1 and eu-central-1 behind a DynamoDB global table, with the application performing client-side field-level encryption on PAN (card number) data before writing. They had used a standard, Region-scoped CMK in eu-west-1. The global table dutifully replicated the ciphertext to eu-central-1 — about 240 million encrypted items, growing 3 million a day. The platform team was six engineers; the KMS bill was a rounding error and nobody had thought hard about it.

The first incident was a planned regional failover game-day. At 10:00 they drained eu-west-1; by 10:02 the eu-central-1 application could not decrypt a single replicated record. Every read of PAN data threw AccessDeniedException / NotFoundException from KMS. The ciphertext was a KMS envelope bound to a key that only existed in eu-west-1, and kms:Decrypt in eu-central-1 had no key to call. Replicated-but-unreadable data is the worst kind of DR failure: it looks perfectly healthy — the bytes are there, the table is green — until you cut over and discover the ability to read them never replicated. The game-day was aborted; the DR posture was, on paper, a lie.

The fix was a multi-Region key, and critically, a backfill — adopting an MRK does nothing for the 240 million records already wrapped under the old single-Region key. They created an MRK primary in eu-west-1, replicated it into eu-central-1, repointed the application’s key provider, and ran a controlled ReEncrypt migration (in batches, throttle-aware, idempotent on a per-item version flag) over the existing items so every envelope was re-wrapped under the portable key. The backfill ran for nine days at a deliberately capped rate to stay well under the request-rate quota. They also tightened each replica’s policy independently: the eu-central-1 replica granted the app Decrypt only, while writes (and thus GenerateDataKey) stayed pinned to the active primary, so a failover couldn’t silently start minting keys in the standby Region.

# Primary in the active Region
aws kms create-key --multi-region --region eu-west-1 \
  --description "pan-field-encryption primary"

# Replica in the standby Region (independent, decrypt-only policy attached after)
aws kms replicate-key \
  --key-id mrk-0a1b2c3d4e5f6a7b8 \
  --replica-region eu-central-1

A second, quieter incident surfaced during the same project. With the global table now genuinely portable, traffic doubled into both Regions and the payments service began throwing intermittent ThrottlingException on GenerateDataKey during the evening peak. The cause: client-side field encryption was calling GenerateDataKey per item, and at peak that exceeded the Region’s request-rate quota. They fixed it two ways: added data-key caching in the Encryption SDK (keyed per tenant, max_age=120s, max_messages_encrypted=500), which cut KMS calls by ~98%, and proactively raised the request-rate quota via Service Quotas ahead of the next quarter’s launch. The S3 archive of settlement files, separately, had Bucket Keys enabled in the same sweep — it had been making a GenerateDataKey call per object and was the single largest line on the (newly noticed) KMS bill.

The lesson the team wrote into their standards, in three lines: if a ciphertext can travel between Regions, the key that protects it must travel too — and you must re-encrypt the data that predates that decision. Replication moves bytes; it does not move the ability to read them. And: architect the KMS call volume down before you scale up the quota. The incident timeline, because the order of discovery is the lesson:

Advantages and disadvantages

KMS’s design — keys that never leave the HSM, a resource policy as the root of trust, envelope encryption as the pattern — is what makes it both powerful and full of sharp edges. Weigh it honestly:

The model is right whenever you need provable, auditable, centrally-controlled key management — which is almost every regulated or multi-account workload. It bites hardest on teams that treat the key policy like an IAM afterthought (lockouts), that call KMS per object (throttling, cost), that assume rotation re-encrypts data (compliance gap), or that replicate ciphertext cross-Region without making the key portable (the Northwind failure). Every disadvantage is manageable — but only if you know it exists, which is the entire point of this article.

Hands-on lab

Prove envelope encryption, multi-Region portability, encryption-context enforcement, and the key-policy-is-root-of-trust behaviour end to end — all in the AWS Free Tier shape (a CMK is ~$1/month prorated; one MRK replica adds a second; delete at the end and the cost is pennies). Run in CloudShell with credentials that can manage KMS. You will create a multi-Region key, round-trip a data key, prove cross-Region decrypt, and prove that the wrong encryption context fails closed.

Step 1 — Variables.

PRIMARY_REGION=eu-west-1
DR_REGION=eu-central-1
ACCT=$(aws sts get-caller-identity --query Account --output text)
echo "account=$ACCT primary=$PRIMARY_REGION dr=$DR_REGION"

Step 2 — Create a multi-Region primary key and an alias.

KEY_ID=$(aws kms create-key --multi-region --region $PRIMARY_REGION \
  --description "kms-lab mrk primary" \
  --query KeyMetadata.KeyId --output text)
aws kms create-alias --region $PRIMARY_REGION \
  --alias-name alias/kms-lab --target-key-id $KEY_ID
echo "primary key: $KEY_ID"

Expected: a KeyId beginning mrk-. Confirm it is multi-Region:

aws kms describe-key --region $PRIMARY_REGION --key-id alias/kms-lab \
  --query 'KeyMetadata.{MR:MultiRegion, State:KeyState}'
# -> "MR": true, "State": "Enabled"

Step 3 — Enable rotation on a 180-day cadence.

aws kms enable-key-rotation --region $PRIMARY_REGION \
  --key-id $KEY_ID --rotation-period-in-days 180
aws kms get-key-rotation-status --region $PRIMARY_REGION --key-id $KEY_ID
# -> "KeyRotationEnabled": true, "RotationPeriodInDays": 180

Step 4 — Replicate into the DR Region with a (decrypt-only) policy.

aws kms replicate-key --region $PRIMARY_REGION \
  --key-id $KEY_ID --replica-region $DR_REGION \
  --description "kms-lab mrk replica"
aws kms create-alias --region $DR_REGION \
  --alias-name alias/kms-lab --target-key-id $KEY_ID
aws kms describe-key --region $DR_REGION --key-id alias/kms-lab \
  --query 'KeyMetadata.{MR:MultiRegion, State:KeyState}'
# -> "MR": true, "State": "Enabled" in the DR Region too

Step 5 — Envelope round-trip: mint a data key, then decrypt the wrapped blob.

WRAPPED=$(aws kms generate-data-key --region $PRIMARY_REGION \
  --key-id alias/kms-lab --key-spec AES_256 \
  --encryption-context tenant=acme \
  --query CiphertextBlob --output text)

# Decrypt the wrapped data key back, in the PRIMARY Region (must supply same context)
aws kms decrypt --region $PRIMARY_REGION \
  --ciphertext-blob fileb://<(echo "$WRAPPED" | base64 --decode) \
  --encryption-context tenant=acme \
  --query KeyId --output text
# -> returns the key ARN, proving decrypt authorization + correct context

Step 6 — Prove cross-Region portability (the DR claim). Decrypt the same wrapped blob by calling KMS in the DR Region:

aws kms decrypt --region $DR_REGION \
  --ciphertext-blob fileb://<(echo "$WRAPPED" | base64 --decode) \
  --encryption-context tenant=acme \
  --query KeyId --output text
# -> returns the DR-Region key ARN: the multi-Region key made the envelope portable

Step 7 — Prove encryption context fails closed. Decrypt with the wrong context — it must error:

aws kms decrypt --region $PRIMARY_REGION \
  --ciphertext-blob fileb://<(echo "$WRAPPED" | base64 --decode) \
  --encryption-context tenant=wrong 2>&1 | grep -i "InvalidCiphertext\|AccessDenied" \
  && echo "GOOD: wrong context correctly rejected"

Validation checklist. You created a multi-Region key, enabled rotation, replicated it, round-tripped a data key, decrypted the same envelope in two Regions (portability), and proved that the wrong encryption context fails closed. The lab steps mapped to what each proves:

Teardown (avoid the ~$1/key/month charge). A replica must be deleted; deleting an MRK has a scheduling window:

# Schedule deletion in BOTH Regions (7-day minimum window), then remove aliases
aws kms delete-alias --region $DR_REGION --alias-name alias/kms-lab
aws kms schedule-key-deletion --region $DR_REGION --key-id $KEY_ID --pending-window-in-days 7
aws kms delete-alias --region $PRIMARY_REGION --alias-name alias/kms-lab
aws kms schedule-key-deletion --region $PRIMARY_REGION --key-id $KEY_ID --pending-window-in-days 7

Cost note. Two keys for a few days, scheduled for deletion at the 7-day minimum, costs a fraction of the ~$1/key/month — well under ₹100 total. Crypto requests in this lab are a handful and effectively free.

Common mistakes & troubleshooting

This is the playbook — the part you bookmark. First a scannable table you can read mid-incident, then the full reasoning for the entries that bite hardest. Every row is symptom → root cause → confirm (exact command) → fix.

The expanded form, for the entries that cause the most lost hours:

1. The DR Region cannot decrypt replicated data after a failover. Root cause: A single-Region CMK sits behind a cross-Region replicated store (DynamoDB global table, S3 CRR of SSE-KMS objects, cross-Region snapshot copies). The bytes replicate; the key does not. Confirm: aws kms describe-key --key-id <id> --query 'KeyMetadata.{MR:MultiRegion}' returns false; the ciphertext’s key ARN names the source Region only. Fix: Create a multi-Region key, replicate-key into the DR Region, repoint the app’s key provider, and run a ReEncrypt backfill over pre-existing ciphertext. Test decrypt in DR, not just replication, in every game-day.

2. AccessDeniedException on Decrypt even though the IAM policy plainly allows kms:Decrypt. Root cause: The key policy omits the IAM-delegation statement, so IAM is ignored and the key policy is the only authority — and it doesn’t list this principal. Confirm: aws kms get-key-policy --key-id <id> --policy-name default shows no kms:* to :root statement (no EnableIAMRoot). Fix: Add the account-root delegation statement so IAM is honored; then the existing IAM allow works. This is the most common KMS lockout.

3. InvalidCiphertextException on a blob that decrypted yesterday. Root cause: Encryption context mismatch. The context passed at decrypt differs (a key, a value, or a missing pair) from encrypt — it’s required byte-for-byte. Confirm: Diff the --encryption-context (or SDK encryption_context) used at encrypt vs decrypt; check whether a kms:EncryptionContext: policy condition changed. Fix: Pass the exact same AAD map. Treat context as required authorization, not optional metadata; store/propagate it alongside the ciphertext.

4. ThrottlingException on a hot path, and a four-figure KMS bill nobody expected. Root cause: One KMS call per object — per-object GenerateDataKey on writes or Decrypt on reads — exceeding the Region’s shared request-rate quota and metering every call. Confirm: CloudTrail shows one GenerateDataKey/Decrypt per object; Service Quotas → KMS shows you near the request-rate cap. Fix: Enable S3 Bucket Keys (collapses thousands of calls to ~one per bucket), add data-key caching in the Encryption SDK, verify backoff+jitter, and raise the request-rate quota ahead of launches.

5. A cross-account read fails with a bare AccessDenied and no hint which side. Root cause: The cross-account handshake is two-sided and one side is missing — either the owner’s key policy doesn’t allow the foreign principal, or the consumer’s IAM doesn’t allow the KMS action on the full key ARN. Confirm: Read both the owning account’s key policy (get-key-policy) and the consumer’s IAM policy; the consumer must reference the full key ARN. Fix: Grant both sides; scope the key policy with aws:PrincipalOrgID rather than a bare *.

6. You cannot share an encrypted EBS snapshot with another account. Root cause: The snapshot is encrypted with the AWS-managed aws/ebs key, which cannot be shared cross-account — full stop. Confirm: aws ec2 describe-snapshots --snapshot-ids <id> --query 'Snapshots[].KmsKeyId' shows the aws/ebs alias/key. Fix: Copy the snapshot to one encrypted with a CMK, share the snapshot, grant the target account Decrypt + CreateGrant, and let the target re-encrypt to their key on copy.

7. The key was rotated, but a compliance review fails because “the data wasn’t re-encrypted.” Root cause: A misunderstanding — automatic rotation rotates key material, not your stored ciphertext. Old envelopes are unwrapped with retained old material. Confirm: get-key-rotation-status shows rotation enabled, but there’s no ReEncrypt job in your pipeline. Fix: If the regime requires fresh material on existing data, run a separate, application-driven ReEncrypt backfill. Don’t claim rotation does it.

Best practices

• Every key that needs an editable policy, cross-account use, or DR portability is a customer-managed key. AWS-managed keys can’t be shared, can’t be policy-edited, and can’t be multi-Region.
• Always include the EnableIAMRoot delegation in the key policy. Omitting it makes IAM ignored and is the classic way to brick a key and lock out the admins who could fix it.
• Envelope-encrypt anything over 4 KB with the AWS Encryption SDK — never raw Encrypt on large payloads, and never roll your own framing.
• Set a meaningful encryption context on every operation and enforce it in policy with kms:EncryptionContext: conditions — it’s free, logged authorization and audit binding.
• Bound your data-key cache (max_age, max_messages_encrypted, max_bytes_encrypted) and key it per tenant/purpose — never leave it unbounded; tune the blast-radius-vs-throughput trade deliberately.
• Use multi-Region keys wherever ciphertext crosses Regions, scope each replica’s policy independently (e.g. DR Region decrypt-only), and always pair the MRK adoption with a ReEncrypt backfill of legacy data.
• Prefer grants over key-policy edits for AWS services and short-lived jobs — they’re revocable, scoped, and don’t bloat the resource policy. Audit and retire orphaned grants.
• Enable S3 Bucket Keys on every SSE-KMS bucket — it’s the single biggest reducer of per-object KMS calls, cutting both cost and quota pressure.
• Pin keys with kms:ViaService and aws:PrincipalOrgID so a key is usable only through the intended service and only inside your org; treat direct human Decrypt as a red flag.
• Enable automatic rotation on every long-lived symmetric key; handle compliance-driven re-encryption as a separate job, not an assumption about rotation.
• Use long key-deletion windows (close to 30 days) and require multi-party review for ScheduleKeyDeletion and PutKeyPolicy — these are data-destroying / access-granting actions.
• Monitor CloudTrail for unexpected Decrypt, PutKeyPolicy, and ScheduleKeyDeletion, and request request-rate quota increases before launches, not during incidents.

Security notes

• Least privilege on kms:Decrypt. Decrypt is “read the data” — grant it narrowly, gated by encryption context and kms:ViaService, never broadly to account root for usage. Encrypt-only access is benign; decrypt access is the crown jewel.
• The key policy is your security boundary, not IAM. Treat the key policy as the authoritative allow-list, reviewed in PRs, with the IAM-delegation statement present but every usage grant scoped and conditioned.
• Encryption context for tenant isolation. Bind ciphertext to tenant/purpose and constrain it in policy so one tenant’s role can never decrypt another tenant’s data — provable from CloudTrail, not just asserted.
• Confine cross-account use to the org. Always add aws:PrincipalOrgID to cross-account key-policy statements; a bare Principal: * or :root without an org condition is a data-perimeter hole.
• Protect the destructive actions. ScheduleKeyDeletion, PutKeyPolicy, DisableKey, and CreateGrant can destroy data or broaden access — restrict them to break-glass roles, alarm on them, and prefer long deletion windows.
• Pin keys to services and endpoints. kms:ViaService blocks a human running aws kms decrypt; aws:SourceVpce pins use to your KMS interface endpoint so off-network calls fail.
• MRK replicas weaken isolation deliberately — scope them. Identical material in two Regions is an availability trade; give each replica the narrowest policy that Region needs (often decrypt-only in DR) so a failover can’t start minting keys.
• Audit grants and rotation. Orphaned grants accumulate (50k/key) — list and retire them; verify rotation is actually on with get-key-rotation-status rather than assuming.

The security controls that also prevent the operational incidents — secure and resilient pull the same way here:

Cost & sizing

KMS pricing has two components and one trap. The components: roughly $1 per CMK per month (each MRK replica is billed as its own key, so a primary + one replica ≈ $2/month), plus per-request charges for cryptographic operations (a small fee per 10,000 requests, with asymmetric and the heavier GenerateDataKeyPair operations costing more). The trap: the bill is never the $1/month per key — it is millions of unbatched Decrypt/GenerateDataKey calls from a service that should have used S3 Bucket Keys or a data-key cache.

• Architect the call volume down first. S3 Bucket Keys collapse thousands of per-object calls into roughly one per bucket; data-key caching reuses a data key across hundreds of messages. Both cut the request line of the bill by orders of magnitude and relieve the request-rate quota. Do this before optimizing anything else.
• CMK count is a rounding error; don’t over-fragment but don’t agonize. A few hundred keys is a few hundred dollars a month — trivial next to one throttled launch. Use enough keys for clean policy/blast-radius boundaries; don’t create a key per object.
• Multi-Region replicas double the per-key cost of that key and bill requests in each Region separately — worth it for genuine DR, wasteful if you don’t need portability.
• Asymmetric and HMAC operations cost more per request than symmetric; prefer symmetric envelope encryption unless you specifically need offline-encrypt, signing, or MACs.
• Free tier: KMS includes a modest monthly allotment of free crypto requests; the per-key monthly charge is not free. CloudHSM (a different service) is far more expensive — use KMS unless you have a single-tenant HSM mandate.

A rough monthly picture for a mid-size regulated workload — and what each line actually buys:

The sizing rule in one line: the only KMS number that ever surprises a CFO is request volume. Enable Bucket Keys and caching, raise the quota proactively, and the bill stays in the low thousands of rupees; skip them and a per-object hot path turns a rounding error into a five-figure line.

Interview & exam questions

1. Why does KMS “never encrypt your data,” and what does it encrypt instead? KMS is a wrapping and authorization service, not a bulk cipher: key material lives in FIPS 140-3 HSMs and never leaves. For anything over 4 KB you call GenerateDataKey, which returns a data key both in plaintext and wrapped under your CMK; you encrypt the payload locally with the plaintext key, discard it, and store only the ciphertext plus the wrapped blob. KMS protects the key that protects the data — envelope encryption.

2. A Decrypt is denied even though the caller’s IAM policy clearly allows kms:Decrypt. Why, and how do you confirm? The key policy almost certainly omits the IAM-delegation statement (kms:* to the account root), so IAM is ignored and the key policy is the sole authority — and it doesn’t list this principal. Confirm with aws kms get-key-policy; the absence of an EnableIAMRoot-style statement is the smoking gun. Fix by adding the delegation so IAM is honored.

3. A DynamoDB global table replicates client-side-encrypted data to a second Region, but the DR Region can’t decrypt it. What happened and how do you fix it? The data was encrypted under a single-Region CMK; replication moved the ciphertext but not the key, so kms:Decrypt in the DR Region has no key to call. Fix with a multi-Region key (replicate it into the DR Region) and a ReEncrypt backfill of the pre-existing ciphertext — adopting the MRK alone does nothing for data already wrapped under the old key.

4. Explain the three-layer KMS authorization model and which layer is authoritative. The key policy (resource policy on the key) is the root of trust and is authoritative; IAM policies are effective only if the key policy delegates to IAM; grants are programmatic, temporary, fine-grained delegations for services and short-lived jobs. Unlike S3, IAM alone cannot grant KMS access — the key policy must enable it.

5. What is encryption context, and what is it good for? It’s additional authenticated data (AAD): not secret, not encrypted, but bound to the ciphertext, required byte-for-byte at decrypt, and logged in CloudTrail. It’s the cheapest authorization and audit tool in KMS — constrain it with kms:EncryptionContext: conditions to say “this role can decrypt only tenant=acme data,” and read it in CloudTrail to see exactly what was decrypted.

6. Does automatic key rotation re-encrypt your existing data? If not, what does? No — automatic rotation generates new key material and retains the old, so new writes use fresh material while old ciphertext is still unwrapped with retained material; your stored data and data keys are untouched. To actually re-wrap existing data (a compliance requirement in some regimes) you run a separate, application-driven ReEncrypt backfill.

7. How do you share an encrypted EBS snapshot across accounts, and why won’t the default key work? You cannot share a snapshot encrypted with the AWS-managed aws/ebs key — it’s not shareable cross-account. Use a customer-managed key, share the snapshot, grant the target account Decrypt + CreateGrant on the key, and the target re-encrypts to their key on copy. This is why production fleets standardize on CMKs for EBS.

8. A hot path is throwing ThrottlingException and the KMS bill spiked. Diagnose and fix. The path is making one KMS call per object (GenerateDataKey/Decrypt), exceeding the Region’s shared request-rate quota and metering every call. Confirm via CloudTrail event counts and Service Quotas usage. Fix by enabling S3 Bucket Keys, adding data-key caching in the Encryption SDK, verifying backoff+jitter, and raising the request-rate quota ahead of launches.

9. When do you reach for a grant instead of editing the key policy? For AWS services and short-lived workloads — a grant is issued by API, carries its own operation list and encryption-context constraints, is retirable the instant the work is done, and doesn’t bloat the resource policy. It’s exactly how services like Auto Scaling and EBS mint data keys on your behalf. Prefer grants for transient/service access; key-policy edits for the durable allow-list.

10. How do you confine a KMS key so only a specific service in your org can use it? Add two condition keys to the policy: kms:ViaService (e.g. s3.eu-west-1.amazonaws.com) so the key is usable only through that service and not by a human running aws kms decrypt, and aws:PrincipalOrgID so cross-account use is confined to your organization. Add aws:SourceVpce to pin it to your KMS interface endpoint for off-network defense.

11. What’s the difference between a single-Region and a multi-Region key, and when is each correct? A single-Region key is Region-locked — its ciphertext decrypts only in that Region, and it offers the strongest isolation. A multi-Region key shares identical material across a primary and replicas so the same envelope decrypts in any of them. Use single-Region by default; use multi-Region only where ciphertext must cross Regions (global tables, cross-Region DR), accepting weaker isolation as the trade.

12. You scheduled a key for deletion. What are the risks and the safety net? Deleting a CMK destroys the material after a 7–30 day waiting window, rendering all ciphertext under it permanently unreadable. The safety net is cancel-key-deletion within the window, and the discipline is long windows (close to 30 days) plus multi-party review, because ScheduleKeyDeletion is a data-destroying action.

These map across several certs: AWS Certified Security – Specialty (SCS-C02) covers KMS authorization, grants, encryption context, cross-account, and CloudTrail auditing in depth; Solutions Architect – Professional (SAP-C02) covers multi-Region keys and DR portability; Solutions Architect – Associate (SAA-C03) covers envelope encryption, SSE integrations, and key types. A compact cert-mapping:

Quick check

1. A Decrypt is denied even though the caller’s IAM allows kms:Decrypt. What is the most likely cause, and the one command to confirm it?
2. A global table replicated your encrypted data to a DR Region, but the DR Region can’t decrypt it. What single property of the key explains this, and what two-part fix is required?
3. True or false: enabling automatic key rotation re-encrypts your existing stored data under the new material.
4. You’re seeing ThrottlingException on an S3-backed hot path and a surprising KMS bill. Name the single biggest lever to fix both.
5. You want a CMK that can only be used through S3 and only by principals in your organization. Which two condition keys do you add?

Answers

1. The key policy omits the IAM-delegation statement, so IAM is ignored and the key policy is authoritative — and it doesn’t list this principal. Confirm with aws kms get-key-policy --key-id <id> --policy-name default; the missing kms:*-to-:root (EnableIAMRoot) statement is the cause. Add it.
2. The key is single-Region (MultiRegion: false) — replication moved the ciphertext but not the key. The fix is two parts: adopt a multi-Region key (replicate it into the DR Region) and run a ReEncrypt backfill of the pre-existing ciphertext; the MRK alone does nothing for data already wrapped under the old key.
3. False. Rotation generates new material and retains the old, so new writes use fresh material while old ciphertext is unwrapped with retained material — your stored data is untouched. Re-wrapping existing data needs a separate, application-driven ReEncrypt job.
4. Enable S3 Bucket Keys. It collapses thousands of per-object KMS calls into roughly one per bucket, cutting the request line of the bill and relieving the request-rate quota that’s causing the throttling. (Add data-key caching and a quota increase as follow-ups.)
5. kms:ViaService (e.g. s3.eu-west-1.amazonaws.com) to pin the key to S3 only — blocking a human running aws kms decrypt — and aws:PrincipalOrgID to confine use to your organization.

Glossary

• KMS key (CMK) — a logical reference to symmetric or asymmetric key material that lives inside FIPS 140-3 validated HSMs and is never exported; formally a “KMS key.”
• Customer-managed key — a CMK whose policy, rotation, grants, tags, and deletion you control; the only type worth architecting around (vs AWS-owned/AWS-managed).
• Data key — a symmetric key minted by GenerateDataKey, returned in plaintext (for local encryption) and wrapped under the CMK (for storage); it does the actual bulk encryption.
• Envelope encryption — encrypting data with a data key and wrapping that data key under a CMK, so plaintext and key material both stay out of KMS.
• Key policy — the resource policy attached to a CMK; the root of trust in KMS, authoritative over IAM (which is ignored unless the key policy delegates to it).
• Grant — a programmatic, temporary, fine-grained delegation (operations + constraints) used by AWS services and short-lived jobs; revocable without editing the key policy.
• Encryption context — additional authenticated data (AAD): not secret, bound to the ciphertext, required byte-for-byte at decrypt, logged in CloudTrail, and constrainable in policy.
• Multi-Region key (MRK) — a primary plus replicas that share identical key material (mrk-...), so a single envelope decrypts in any of their Regions; the basis of cross-Region DR portability.
• ReEncrypt — a KMS operation that decrypts and re-wraps ciphertext under a new key without exposing plaintext to your process; used to migrate the wrapping key and backfill rotation.
• Alias — a mutable, Region-scoped friendly pointer (e.g. alias/payments-prod) to a CMK; convenient but not a stable identity for audit (CloudTrail logs the key ARN).
• kms:ViaService — a condition key that pins a CMK to a specific AWS service, so it can be used only through that service (e.g. S3) and not by a human calling KMS directly.
• aws:PrincipalOrgID — a condition key that confines cross-account key use to principals within your AWS Organization.
• S3 Bucket Keys — a bucket-level setting that caches a data key per bucket for SSE-KMS, collapsing thousands of per-object KMS calls into roughly one and cutting cost and quota pressure.
• Request-rate quota — the shared, per-Region cap on cryptographic operations; exceeding it returns ThrottlingException, the throttling ceiling you architect call volume around.
• Key commitment — an Encryption SDK property (REQUIRE_ENCRYPT_REQUIRE_DECRYPT) that prevents one ciphertext from decrypting to different plaintexts under different keys.
• KeySpec / KeyUsage — the immutable cryptographic spec (e.g. SYMMETRIC_DEFAULT) and purpose (e.g. ENCRYPT_DECRYPT) chosen at key creation — a one-way door.
• Key deletion window — the 7–30 day waiting period after ScheduleKeyDeletion before material is destroyed; cancel-key-deletion is the safety net within it.

Next steps

You can now architect KMS as an authorization system with a latency budget and a quota — pick key types deliberately, scope authorization to the exact caller and context, make ciphertext portable where it travels, and crush per-object call volume. Build outward:

• Foundation: AWS IAM Fundamentals: Users, Roles, Policies & the Evaluation Engine — the policy-evaluation model the three-layer KMS authorization is built on.
• Related: IAM Least Privilege: Permission Boundaries & Inescapable Ceilings — the boundary and ABAC patterns that pair with KMS condition keys.
• Related: S3 Deep Dive: Storage Classes, Versioning, Lifecycle & Encryption — where SSE-KMS and S3 Bucket Keys live.
• Related: Secrets Manager & Parameter Store Deep Dive — both wrap their secrets under a CMK and use encryption context.
• Related: CloudTrail, Config & Audit/Compliance — where every Decrypt lands and how to alarm on unexpected ones.
• Related: Cross-Account IAM Roles: External ID, Confused Deputy & Session Policies — the trust patterns behind cross-account KMS sharing.
• Related: The Well-Architected Security Pillar, Deep Dive — where data-protection and key management sit in the bigger picture.