KMS - Key Management Service

AWS Key Management Service (KMS)

AWS Key Management Service (KMS) is a managed service for creating and controlling cryptographic keys backed by FIPS 140-2 validated hardware security modules (HSMs). KMS is the encryption substrate for nearly every AWS service — S3, EBS, RDS, Lambda, Secrets Manager, and more — and exposes a small API for envelope encryption in your own applications.

Key Features:

Centralized Key Management: Symmetric (AES-256-GCM) and asymmetric (RSA, ECC) KMS keys with versioning, aliases, and rotation managed in one place per region.
Service Integration: S3, EBS, RDS, DynamoDB, Lambda, EFS, FSx, Redshift, and Secrets Manager all accept a KMS key ID for native encryption at rest.
Envelope Encryption: KMS encrypts a per-object data key (DEK), the DEK encrypts the payload — keeps large payloads off the KMS API path.
Granular Access Control: Key policies (resource-based, mandatory) plus IAM policies and grants; cross-account access via key policy + IAM policy in the consumer account.
Automatic Key Rotation: Annual rotation of the underlying key material on customer-managed symmetric keys; old material retained for decrypting historical ciphertext.
Multi-Region Keys: Replicas of a primary key in additional regions share key material — ciphertext encrypted in one region can be decrypted in another without re-encrypting.
External & Custom Key Stores: XKS (External Key Store) keeps key material in an on-prem HSM you operate; CloudHSM-backed custom key stores for single-tenant HSMs.
Audit: Every encrypt, decrypt, and key administration call is logged to CloudTrail with the encryption context.

Common Use Cases:

Encryption at Rest in AWS Services: S3 SSE-KMS, EBS volume encryption, RDS storage encryption — pick a customer-managed key (CMK) for auditability and per-tenant isolation.
Application-Level Envelope Encryption: Use GenerateDataKey for high-throughput encryption of large records (PII, PHI) without saturating the KMS API.
Secrets Manager & Parameter Store: KMS encrypts secret material; the key policy controls who can decrypt.
Cross-Account Sharing: Share an encrypted S3 bucket or RDS snapshot by granting the consumer account access to the underlying KMS key.
Compliance: HIPAA, PCI-DSS, FedRAMP — KMS satisfies HSM-backed key custody requirements.

Key Types & Trade-offs:

AWS-managed keys (aws/service): Free, auto-rotated, but cannot be shared cross-account or audited per-key in the same detail as CMKs.
Customer-managed keys (CMKs): $1/month per key, full control over policy, rotation, and deletion (with a 7-30 day pending window).
Multi-Region keys: $1/month per region replica; ideal for global applications and DR.
Asymmetric keys: For digital signing or use cases where the public key is shared with parties that cannot call KMS.

Service Limits & Quotas:

Customer-managed keys per region: default soft limit 100,000.
Grants per key: 50,000.
Cryptographic API request rate: starts at 5,500-30,000 requests per second per region depending on operation and key spec — soft quota, raisable.
Encrypt payload size (symmetric): 4 KB max — use envelope encryption for larger data.
Key deletion pending window: 7 to 30 days (no instant delete by design).

Pricing Model:

$1/month per customer-managed key (prorated hourly), per region.
$0.03 per 10,000 requests for symmetric encrypt/decrypt/generate-data-key (asymmetric and HMAC are higher).
Free tier: 20,000 requests/month.
Common cost surprise: S3 buckets with SSE-KMS and high object access rates — every GetObject issues a KMS Decrypt call. Use S3 Bucket Keys to reduce KMS calls by ~99%.
Custom key stores (CloudHSM): additional CloudHSM cluster cost (~$1.45/hr per HSM).

Code Example — Envelope Encryption:


import boto3, base64, os
from cryptography.hazmat.primitives.ciphers.aead import AESGCM

kms = boto3.client("kms", region_name="us-west-2")
KEY_ID = "alias/app-data"

def encrypt(plaintext: bytes, context: dict) -> dict:
    # 1. Ask KMS for a fresh data key (256-bit AES)
    resp = kms.generate_data_key(
        KeyId=KEY_ID, KeySpec="AES_256", EncryptionContext=context
    )
    dek_plain, dek_encrypted = resp["Plaintext"], resp["CiphertextBlob"]

    # 2. Encrypt locally with the plaintext DEK, then discard it
    nonce = os.urandom(12)
    ct = AESGCM(dek_plain).encrypt(nonce, plaintext, None)
    del dek_plain

    return {
        "ciphertext": base64.b64encode(nonce + ct).decode(),
        "encrypted_dek": base64.b64encode(dek_encrypted).decode(),
        "context": context,
    }

def decrypt(blob: dict) -> bytes:
    dek = kms.decrypt(
        CiphertextBlob=base64.b64decode(blob["encrypted_dek"]),
        EncryptionContext=blob["context"],
    )["Plaintext"]
    raw = base64.b64decode(blob["ciphertext"])
    return AESGCM(dek).decrypt(raw[:12], raw[12:], None)

Common Interview Questions:

What is envelope encryption and why use it?

Encrypt the payload locally with a randomly generated data encryption key (DEK), then encrypt the DEK with KMS. You store the encrypted DEK alongside the ciphertext. Benefits: KMS API limits and bandwidth don't constrain payload size; you can decrypt locally in tight loops by caching the unwrapped DEK in memory.

Key policy vs. IAM policy — which controls KMS access?

The key policy is mandatory and authoritative. IAM policies only grant access if the key policy delegates to IAM (typical: "Principal": {"AWS": "arn:aws:iam::ACCOUNT:root"} with "Action": "kms:*"). For cross-account access, the key policy must explicitly allow the external account, and the consumer's IAM policy must also allow the operation.

What is encryption context?

A non-secret key/value map bound cryptographically to the ciphertext. KMS will refuse to decrypt unless the same context is supplied. Acts as authenticated additional data (AAD) and shows up in CloudTrail — useful for audit and to prevent confused-deputy attacks.

What are S3 Bucket Keys and when should you enable them?

A bucket-level data key cached at the S3 service that decrypts most objects without per-object KMS calls. Reduces KMS request charges by ~99% on hot buckets. Always enable for new SSE-KMS buckets unless you need per-object key auditing.

Why can't you instantly delete a KMS key?

KMS enforces a 7-30 day pending deletion window because deleting a key permanently destroys all data encrypted with it. The waiting period gives you time to discover and re-encrypt or roll back. You can disable a key instantly to test impact before scheduling deletion.

When would you choose a multi-Region key over re-encrypting?

When the same ciphertext must be decrypted in multiple regions for DR or low-latency reads (e.g., DynamoDB Global Tables, S3 Cross-Region Replication of encrypted objects). Multi-Region keys share material across replicas so ciphertext is portable; otherwise you'd need to decrypt-and-re-encrypt at the boundary.

KMS is the trust anchor for AWS encryption — get the key policies and rotation strategy right, and almost every other security control benefits. Default to customer-managed keys for anything regulated, enable bucket keys to control cost, and treat the key policy as the most important access control document in the account.