KMS and Encryption

Envelope encryption and key management, at rest vs. in transit, and why KMS checks both IAM and the key policy

Data key encrypts data, KMS key encrypts the data keyenvelope encryption keeps KMS out of the bulk-data path
Every key needs exactly one key policygrants add temporary access without editing it
At rest (SSE) vs. in transit (TLS)independent controls — neither implies the other
Key policy must enable IAM, or IAM Allow does nothingan IAM Deny still applies either way

1.Envelope Encryption, KMS Keys, Policies, Grants, and Rotation

Envelope encryption uses two keys: a data key that encrypts your actual data, and a KMS key that encrypts (wraps) that data key. KMS never touches your bulk data directly — it only ever handles the small, wrapped data key. A key policy is the resource policy every KMS key must have, controlling who can use it. A grant hands out a narrow, temporary permission on a key without editing that key policy at all.

Key features

Customer managed key: you create and fully control it — key policy, rotation, deletion, cross-account sharing. AWS managed key: exists in your account but AWS controls its policy, and it cannot be shared cross-account or used outside its one owning service
A key policy is a resource policy attached to the KMS key itself — every KMS key must have exactly one, with no exceptions
A grant allows a principal to use a key for specific operations without editing the key policy — commonly created and retired automatically by AWS services for temporary access
Encryption context is a set of non-secret key-value pairs passed with an encrypt/decrypt call; KMS uses it as additional authenticated data, so decryption fails if the context does not match exactly what was supplied at encryption time
Automatic key rotation on a customer managed key defaults to every 365 days and keeps all prior key material, so old ciphertext still decrypts correctly — an AWS managed key is always rotated automatically, every year, with no opt-out
Cross-account key usage requires two separate grants of permission: the KMS key policy in the owning account must allow the other account's principal, and that principal's own account must separately grant it the matching kms: permission

The three KMS key types

The three KMS key types
Key type	Who controls the key policy	Cross-account sharing	Rotation
Customer managed key	You, fully	Yes, via the key policy	Optional automatic rotation, default 365 days
AWS managed key	The AWS service (you can view, not edit)	No — scoped to your account only	Automatic, every year, cannot be disabled
AWS owned key	The AWS service, exclusively — not even visible to you	Handled transparently by the service	Managed entirely by the owning service

Key policy vs grant

Key policy

One per key, always required — the baseline authorization document
Edited directly; changes apply to everyone the policy names
The natural place for long-lived, broad access

Grant

Any number per key, all optional — layered on top of the key policy
Created and retired independently, without touching the key policy
The natural place for narrow, temporary, or automated access

Signature

Key policy (required, one per key) · Grant (optional, temporary, layered on top)

Envelope encryption: a data key encrypts your data, a KMS key encrypts the data key. Every key needs exactly one key policy; grants add temporary access without editing it. Encryption context is authenticated but not secret — it appears in CloudTrail. Customer managed keys support cross-account sharing and optional rotation (365-day default); AWS managed keys don't share cross-account and rotate automatically every year regardless.

2.Encryption at Rest vs. Encryption in Transit

Encryption at rest protects data while it is stored on disk — S3 objects, EBS volumes, RDS databases — so a stolen disk or leaked storage snapshot is unreadable without the key. Encryption in transit protects data while it moves across a network, using TLS, so anyone intercepting the traffic between a client and AWS (or between two AWS services) cannot read it. They protect different moments and neither one substitutes for the other.

Key features

At rest: protects stored data (S3 objects, EBS volumes, RDS storage, DynamoDB tables) — implemented with server-side encryption (SSE) options, most of them backed by AWS KMS keys
In transit: protects data moving over a network — implemented with TLS, e.g. HTTPS to an S3 or API Gateway endpoint, or a TLS listener on a load balancer
The two are independent controls: enabling one does nothing for the other — a bucket can be encrypted at rest while still being reachable over plain, unencrypted HTTP
AWS Certificate Manager (ACM) issues and manages the TLS certificates that load balancers and CloudFront distributions use for encryption in transit
AWS KMS keys are the common mechanism behind encryption at rest across many services (S3, EBS, RDS, DynamoDB) but play no role in encryption in transit, which is TLS, not KMS

Two different moments, two different controls

At rest

Protects data while stored (disk, database, object storage)
Implemented with server-side encryption, usually backed by a KMS key
A stolen disk or leaked snapshot is unreadable without the key

In transit

Protects data while moving across a network
Implemented with TLS, using a certificate from ACM (or another CA)
Intercepted traffic between a client and AWS is unreadable without the session key

Signature

At rest: server-side encryption (KMS-backed) · In transit: TLS (ACM certificates)

At rest protects stored data (SSE, usually backed by a KMS key); in transit protects data on the network (TLS, via ACM certificates). They are independent — one being enabled never implies the other is.

3.Why KMS Authorization Needs Both IAM and a Key Policy

A KMS key checks two separate documents before allowing any use: the key policy (attached to the key itself) and, if the key policy enables it, IAM policies (attached to the calling user or role). Unless the key policy explicitly allows it, an IAM policy alone cannot grant access — a generous IAM policy means nothing if the key policy never opens the door for IAM policies to matter.

Key features

No principal — not even the AWS account root user or the key's creator — has any permission on a KMS key unless explicitly allowed in a key policy, IAM policy, or grant
Unless the key policy explicitly enables it, IAM policies that allow access have no effect on that key — an "Allow" in IAM is not enough by itself
The default key policy AWS generates on key creation includes the statement that enables IAM policies to matter for that key — a custom key policy that omits it silently blocks every IAM policy
An IAM policy CAN deny access to a KMS key even without permission from the key policy — the enablement requirement applies only to Allow, never to Deny
Key policies are Regional: a key policy governs only the KMS key it is attached to, in that Region — it has no effect on keys in other Regions

What each layer alone can and cannot do

Key policy alone

Always sufficient by itself — every key needs exactly one
Can grant access directly without any IAM policy involved
Must explicitly enable IAM policies, or they are ignored entirely

IAM policy alone

Never sufficient by itself for granting access to a key
Only takes effect once the key policy has opted in to trusting IAM
Can still DENY access to a key even without that opt-in

Signature

Key policy (required, must enable IAM) + IAM policy (only matters once enabled)

A KMS key checks the key policy first — it is required, and unless it explicitly enables IAM, an IAM Allow does nothing. IAM can still Deny access to a key without that enablement. Always check both when a KMS AccessDenied looks wrong on the IAM side.

Spotted a mistake on this page? Tell us.

Read Sheet