Encryption at Rest on AWS: KMS Keys, Key Policies, and Service Integration

Every KMS-integrated service encrypts under one of three key ownership models, and choosing between them is a control-versus-effort decision the exam tests repeatedly.

AWS owned keys live in AWS-internal accounts: you cannot see, audit, or choose them — DynamoDB's default encryption is the classic example. AWS managed keys (aliases like aws/s3) exist in your account and log to your CloudTrail, but you cannot edit their key policies, control rotation, or — critically — use them across accounts. Customer managed keys are the only model where you own the key policy, opt into rotation, create grants, schedule deletion, and authorize other accounts. The exam pattern: the moment a requirement mentions cross-account sharing, key-level audit boundaries, or the ability to revoke a service's access to data, the answer is a customer managed key.

Symmetric AES-256 keys are the default and what every service integration uses. Asymmetric RSA and ECC keys exist for sign/verify and for encrypt-outside-AWS patterns — the public key is downloadable while the private key never leaves KMS — but know them at concept level.

Unlike most AWS resources, a KMS key does not implicitly trust its own account. The key policy is the root of trust: no principal — not even the account root user — can use or manage a key unless the key policy allows it, directly or by delegation.

The default key policy contains one statement: it allows the account principal (arn:aws:iam::111122223333:root) the full kms:* action set. That statement is not really about the root user — it is the delegation switch that enables IAM policies to work. With it present, an IAM identity policy in the account can grant KMS permissions on the key; without it, IAM policies are inert for that key. Delete or over-restrict that statement and you can create an unmanageable key — one no principal can administer — recoverable only by contacting AWS Support. Treat edits to it like production changes.

Access to a key therefore flows through two policy paths that combine: the key policy can authorize a principal directly, or the key policy delegates to IAM and an identity policy supplies the allow. Cross-account use requires both halves: the key policy must allow the external account (or specific principals in it), and the external account must separately grant its principals IAM permission on the key's ARN. Either half alone fails — a favorite distractor. Only customer managed keys support this; aws/service keys cannot cross accounts.

At organization scale, condition the key policy on aws:PrincipalOrgID to allow any principal from your AWS Organization without enumerating accounts — a clean pattern for shared data lakes and centralized log archives.

Grants are the third access path, alongside key policies and IAM policies: a temporary, programmatic delegation attached to a key. A grant names a grantee principal, a subset of allowed operations (decrypt, encrypt, generate data key, describe, retire, and a few others — grants can only allow, never deny), and optional constraints that pin the grant to a specific encryption context.

Grants exist mainly so AWS services can use your keys on your behalf without long-lived policy entries. The canonical example is EBS: when you attach an encrypted volume, EC2 creates a grant on the volume's KMS key so the service can decrypt the volume's data key during attachment, and retires the grant when it is no longer needed. This is why service-integration key policies commonly allow kms:CreateGrant conditioned on kms:GrantIsForAWSResource — the condition restricts grant creation to AWS services acting for you, rather than letting a human principal mint delegations.

That points at the risk the exam wants you to see: kms:CreateGrant is a delegation right. Any principal holding it can create new access to the key for another principal, sidestepping your policy review. Audit it the way you audit iam:PassRole, scope it with kms:GrantIsForAWSResource where only services need it, and review existing grants with the list-grants APIs during investigations.

Operationally, grants are eventually consistent — a freshly created grant can take a short time to become usable everywhere, which is why the API returns a grant token that can be passed to requests to bridge the gap. Concept-level knowledge of that behavior is enough for the exam.

KMS never bulk-encrypts your data. The direct Encrypt API caps plaintext at 4 KB — enough for another key or a small secret, not for objects. Everything larger uses envelope encryption: call GenerateDataKey and KMS returns two things — a plaintext data key and the same data key encrypted under your KMS key. You encrypt the data locally with the plaintext key, discard that plaintext key from memory, and store the encrypted data key alongside the ciphertext. To read, you send the encrypted data key to Decrypt, receive the plaintext key back, and decrypt locally. Every SSE-KMS integration — S3, EBS, RDS — runs this flow under the hood, which is why revoking access to the KMS key revokes access to all data encrypted under it: without the key, the stored data keys are unrecoverable ciphertext.

Encryption context is the second mechanism you must know cold. It is a set of non-secret key-value pairs bound to a cryptographic operation as additional authenticated data (AAD): it is not encrypted, but for symmetric keys the exact same context must be supplied to decrypt. That yields two benefits. Cryptographic binding — S3, for example, uses the object's location as context, so an encrypted data key copied next to a different object will not decrypt. And audit — the context appears in every CloudTrail record for the KMS call, telling you precisely which resource a Decrypt served. You can also enforce it: the kms:EncryptionContext: condition keys in key policies restrict a principal to operations carrying specific context values, scoping one key safely across many datasets.

Rotation. Customer managed symmetric keys support optional automatic rotation — yearly by default — while AWS managed keys always rotate yearly and you cannot change that. Rotation swaps in new backing key material but retains all previous material so old ciphertexts still decrypt; the key ID and ARN never change, and nothing is ever re-encrypted. Rotation is therefore transparent to applications — and it does not retroactively protect data already encrypted: if key material were compromised, rotation alone does not fix the past. Keys with imported key material cannot auto-rotate at all; rotating them means creating new material or a new key and re-pointing the alias.

Multi-Region keys. KMS keys are Regional, which normally forces decrypt-and-re-encrypt when data crosses Regions. Multi-Region keys solve this: a primary key replicated into other Regions shares the same key ID and key material, so ciphertext encrypted in one Region decrypts in another without re-encryption — the pattern for cross-Region DR and globally replicated data. They are replicas, not a global key: each has its own key policy and is managed independently.

Deletion. You cannot delete a key immediately. ScheduleKeyDeletion imposes a pending window of 7 to 30 days (default 30) during which the key is unusable but recoverable via CancelKeyDeletion. Once deleted, every ciphertext under it — every object, snapshot, and data key — is permanently unrecoverable; that is what unrecoverable means here: the data, not just the key. The operational discipline is disable first: disable the key, watch CloudTrail for failing calls that reveal forgotten dependencies, and only then schedule deletion.

When regulation demands single-tenant HSMs or key material held outside AWS, know that KMS supports CloudHSM-backed custom key stores and external key stores — recognition depth only.

S3 encrypts every new object by default with SSE-S3: AES-256 with keys S3 manages entirely. It is free and invisible — which is exactly its limitation: no key of yours to audit, no key policy to control, no cross-account key governance, and no CloudTrail evidence of key usage per object.

SSE-KMS switches the data-key source to a KMS key — aws/s3 or, for real control, a customer managed key. Now every object's data-key operation is authorized by the key policy and logged to CloudTrail, access can be revoked centrally by disabling the key, and cross-account bucket sharing can be governed at the key. The cost is literal: each object operation calls KMS, which bills per request and consumes the KMS request quota — at high request rates, workloads start seeing throttling.

S3 Bucket Keys are the classic optimization: S3 requests a short-lived bucket-level key from KMS and derives per-object keys from it locally, cutting KMS calls and cost dramatically — the stock answer to reduce KMS request costs or throttling for S3. The visible trade-off is coarser CloudTrail granularity, since far fewer per-object KMS events are emitted.

Two more modes complete the picture at mention level: DSSE-KMS applies two independent layers of encryption for the strictest compliance regimes, and client-side encryption encrypts before upload so AWS never handles plaintext, putting key custody entirely on you.

Enforcement is two-layered: set bucket default encryption to SSE-KMS with your chosen key (and bucket keys enabled), then add a bucket policy denying s3:PutObject unless the s3:x-amz-server-side-encryption header equals aws:kms — since everything is encrypted by default now, the policy's real job is enforcing which method and key, and the companion condition s3:x-amz-server-side-encryption-aws-kms-key-id can pin the exact key.

EBS. Enable the per-Region account setting encryption by default and every new volume and snapshot is encrypted without asking. Existing unencrypted volumes cannot be flipped in place: snapshot the volume, copy the snapshot with encryption enabled (choosing your key), and restore a new volume — the universal encrypt-existing pattern. Sharing is where key choice bites: snapshots encrypted with the default aws/ebs key cannot be shared with another account at all. You must copy the snapshot re-encrypting under a customer managed key, share the snapshot, and grant the target account access in the key policy so it can decrypt and copy. Encrypted snapshots can never be made public.

RDS. Storage encryption is decided at instance creation and cannot be toggled later. Encrypting an existing database uses the same move: snapshot, copy the snapshot with encryption, restore a new instance. Because KMS keys are Regional, copying an encrypted snapshot cross-Region requires specifying a key in the destination Region; and an encrypted snapshot cannot be restored as an unencrypted instance.

DynamoDB is always encrypted at rest — the design decision is only which key: the AWS owned default (free, invisible), the aws/dynamodb managed key (auditable in your CloudTrail), or a customer managed key (full policy control, revocable). You can switch between them on a live table.

Integrity and WORM. When the threat is modification or deletion — ransomware, insider tampering, regulated retention — encryption is not the control; immutability is. S3 Object Lock on a versioned bucket enforces retention in governance mode (bypassable only with s3:BypassGovernanceRetention) or compliance mode (no principal, not even root, can shorten it), plus legal holds. Glacier Vault Lock locks a vault policy immutably once committed. Pair these with versioning and cross-account backup copies via AWS Backup for ransomware resilience.

Org-wide, enforce preventively with SCPs that deny creating unencrypted resources — for example denying ec2:CreateVolume when the ec2:Encrypted condition is false — and detectively with AWS Config rules like encrypted-volumes and rds-storage-encrypted feeding remediation.

Work the scenario the exam loves: a Lambda function reads objects from an SSE-KMS bucket. It worked yesterday; today every GetObject fails with AccessDenied, even though the execution role clearly allows s3:GetObject and kms:Decrypt. Run the checklist in order.

1. Key policy before IAM. If the key lives in another account — or the key policy's delegation statement was tightened — the role's IAM allow is worthless: cross-account use needs the key policy to allow the external account and the caller's IAM policy to allow the key ARN. Check the key policy first, always.

2. Grants. Was access flowing through a grant that has been retired or revoked? List the key's grants; service-created grants disappearing explains sudden service failures.

3. Encryption context. If the key policy or IAM policy carries kms:EncryptionContext: conditions, a request whose context does not match is denied even though the action is allowed. Compare the context in the failing CloudTrail event against the condition values — CloudTrail records both the error and the context.

4. The network path. A Lambda in a VPC reaching KMS through an interface endpoint is also subject to the VPC endpoint policy; an endpoint policy that omits the key or principal denies the call regardless of every other policy. Key policies conditioned on aws:sourceVpce or kms:ViaService fail the same way when requests arrive by an unexpected route.

5. Key state. A disabled or pending-deletion key fails every operation — and cascades: EBS volumes fail to attach, SSE-KMS reads fail, RDS instances using the key become inaccessible. This is the everything-broke-at-once scenario; CloudTrail shows the failing Decrypt calls naming the key ARN. Re-enable the key or CancelKeyDeletion within the pending window — the reason the window and the disable-first discipline exist.

Separately, KMS throttling from high-volume SSE-KMS traffic is a quota problem, not a permissions problem: enable S3 Bucket Keys or request a quota increase.