What KMS Manages: Keys, Not Just Encryption
AWS KMS lets you create and manage cryptographic keys called Customer Master Keys, now called KMS keys, and control who can use them to encrypt and decrypt data. The actual key material never leaves KMS in plaintext form — services like S3, EBS, and RDS call KMS's Encrypt and Decrypt APIs (or, more efficiently, GenerateDataKey) rather than pulling the raw key out to encrypt data locally. KMS keys are region-specific and backed by FIPS 140-2 validated hardware security modules, and access to use a key is governed by a key policy — a resource-based policy attached to the key itself — in combination with any IAM identity-based policies that reference the key's ARN.
Cricket analogy: KMS is like a stadium's bat-sensor authentication system — the sensor logic that validates a bat's edge never leaves the secure vault, and umpires only ever get a yes/no signal back, never the raw calibration data itself.
Envelope Encryption and Data Keys
Because KMS keys can encrypt at most 4KB directly, and calling KMS over the network for every byte of a large file would be slow, AWS services use envelope encryption: they call GenerateDataKey to get a fresh, random data key back in two forms — plaintext and a copy encrypted under the KMS key. The service uses the plaintext data key to encrypt the actual object locally (fast, all-local AES operation), immediately discards the plaintext data key from memory, and stores only the encrypted copy alongside the ciphertext. To decrypt later, the service sends the small encrypted data key back to KMS, gets the plaintext data key back, decrypts the object, and discards the key again — so KMS is only ever in the loop for the small key operation, not the bulk data.
Cricket analogy: Envelope encryption is like a team using a disposable one-time signal from the dressing room for each ball, rather than radioing the head coach for instructions on every single delivery — the coach (KMS) is only consulted briefly to issue the signal, not involved in every second of play.
Key Policies, Grants, and Rotation
Every KMS key has a key policy, which is the resource-based policy that ultimately controls access — even an IAM administrator with 'kms:*' in their identity policy cannot use a key unless the key policy also permits it (or delegates to IAM policies via the default 'enable IAM policies' statement most console-created keys include). Grants provide a more temporary, programmatic way to delegate specific key permissions, commonly used by AWS services on your behalf so they don't need a broad, standing entry in the key policy. AWS-managed keys rotate automatically every year with no action from you, and customer-managed KMS keys can have automatic annual rotation enabled with a single setting, which rotates the underlying key material while keeping the same key ID and ARN so nothing referencing the key needs to change.
Cricket analogy: A key policy is like a stadium's master access list controlling the vault where the trophy is kept — even the tournament director can't get in just because they run the tournament; their name has to be explicitly on that specific vault's list.
import boto3
kms = boto3.client("kms")
# Ask KMS for a fresh data key: returns plaintext + encrypted copy
response = kms.generate_data_key(
KeyId="arn:aws:kms:us-east-1:123456789012:key/abcd-1234",
KeySpec="AES_256",
)
plaintext_key = response["Plaintext"] # used locally, then discarded
encrypted_key = response["CiphertextBlob"] # stored alongside the encrypted object
# ... encrypt the actual file locally with plaintext_key (e.g. AES-GCM) ...
# ... then delete plaintext_key from memory ...Automatic key rotation for a customer-managed KMS key rotates the backing cryptographic material every year but preserves the key's ID and ARN, so applications, IAM policies, and resource references never need to change. KMS retains all prior key material internally so data encrypted under an older version of the key can still be decrypted.
- KMS keys never expose their raw key material in plaintext outside the service.
- Services use envelope encryption via GenerateDataKey: a plaintext data key encrypts data locally, while only the encrypted data key is stored.
- A key policy is a resource-based policy attached to the key itself, and it ultimately governs access even for IAM administrators.
- Grants offer temporary, programmatic delegation of specific key permissions, often used by AWS services.
- AWS-managed keys rotate automatically every year with no configuration required.
- Customer-managed keys can enable automatic annual rotation, preserving the key ID and ARN.
- KMS keys are region-specific and backed by FIPS 140-2 validated hardware security modules.
Practice what you learned
1. Why do AWS services like S3 use envelope encryption with GenerateDataKey instead of calling KMS Encrypt directly on large objects?
2. What ultimately controls who can use a specific KMS key, even overriding a broad IAM identity policy?
3. What happens to a customer-managed KMS key's ARN when automatic annual rotation occurs?
4. What is a KMS grant primarily used for?
5. In the envelope encryption flow, what does a service do with the plaintext data key after using it to encrypt data locally?
Was this page helpful?
You May Also Like
IAM Policies Explained
IAM policies are JSON documents that define permissions, and understanding their structure and evaluation logic is essential to securing an AWS account.
IAM Users, Groups, and Roles
AWS Identity and Access Management (IAM) defines who or what can act in your account, using users, groups, and roles as the core identity building blocks.
RDS Fundamentals
Amazon RDS is a managed relational database service that automates provisioning, patching, backups, and failover for engines like MySQL, PostgreSQL, and Aurora.