AWS KMS and Customer Managed Keys

Welcome back. This guide explains AWS KMS (Key Management Service) and how to protect data using Customer‑Managed Keys (CMKs). It covers KMS basics, CMK lifecycle and access control, envelope encryption patterns, service integrations, CloudFormation examples, and key rotation strategies. Use this as a concise reference when designing encryption and key management for AWS workloads. Data protection and KMS overview AWS KMS is the central, regionally scoped key management service used by many AWS services. For a dedicated hardware option, AWS CloudHSM is available, but KMS is the primary integration point used by S3, EBS, RDS, Lambda environment variables, Secrets Manager, SQS, and many other services when server-side encryption (SSE‑KMS) is enabled. Using KMS helps you meet compliance and audit requirements (GDPR, HIPAA, PCI DSS) and allows fine-grained controls such as cross-account access via key policies and grants. Remember: CMKs are regional. To use keys across regions you must use Multi-Region keys (replica keys) or replicate keys/data between regions.

A presentation slide titled "Scenario: The Data Protection Challenge" showing challenges (regulatory requirements, granular key control, cross-account/cross-region, audit requirements) on the left. On the right are AWS services that use encryption (Amazon S3, EBS, Redshift, RDS) with matching icons.

KMS core concepts KMS provides three main classes of keys:

AWS owned keys — managed entirely by AWS for internal service use.
AWS managed keys — created and managed by AWS for use by specific services; visible to you with limited control.
Customer managed keys (CMKs) — created and managed by you; full control over policies, rotation, grants, and (optionally) imported key material.

KMS supports key types: symmetric (AES‑GCM 256), asymmetric (RSA / ECC), and HMAC keys. CMKs are the primary construct for customer control and auditing.

A slide titled "AWS KMS Fundamentals." It lists core KMS components (customer-managed keys, key/IAM policies, key material, grants) and key types (256-bit AES-GCM symmetric, RSA/Elliptic Curve asymmetric, HMAC).

CMKs vs AWS keys High-level differences:

Key Class	Who Manages	Typical Use Case	Control Surface
AWS owned keys	AWS	Internal service usage (invisible to customers)	None
AWS managed keys	AWS (created for services)	Service-specific encryptions (visible)	Limited (view & use in service)
Customer managed keys (CMKs)	Customer	Bring-your-own-key policies, cross-account, custom rotation	Full — key policies, grants, rotation, import

A presentation slide titled "Customer Managed Keys (CMKs)" that compares three types of keys: Customer Managed Keys, AWS Managed Keys, and AWS Owned Keys. Each box briefly explains who creates/manages the keys and the level of customer control over encryption.

CMK lifecycle and states Typical CMK states and transitions:

Enabled — key is active for cryptographic operations.
Disabled — key cannot be used until re-enabled.
Pending deletion — after you schedule deletion, the key enters a waiting period before it is permanently deleted.

You can enable/disable keys and schedule deletion with a configurable retention period.

A diagram titled "Customer Managed Keys (CMKs)" showing a flowchart of key states and transitions: Enabled ↔ Enable Key ↔ Disable Key → Disabled → Schedule Deletion → Pending Deletion.

Scheduling a CMK for deletion is irreversible after the retention window ends — ensure you have recovered or rekeyed any data encrypted under the CMK before deletion completes. Use a conservative retention period for production keys.

Key policies, grants, and IAM KMS evaluates access in a specific order: key policies, grants, then IAM policies — and the key policy can enable or restrict IAM-based access. The evaluation flow:

Evaluate the key policy. If it explicitly allows the requester, proceed.
Check grants (temporary permissions attached to a CMK).
If neither the key policy nor grants allow access, evaluate IAM policies — but IAM can only authorize actions if the key policy allows IAM principals to use the key.

In short: a restrictive key policy can block IAM permissions. Key policies are required and serve as the primary gate for CMK usage.

A flowchart titled "Key Policies and Access Control" showing decision steps (e.g., Evaluate Key Policy, Check Grants, Evaluate IAM Policy) after an access request. The diagram leads to either "Access Granted" or "Access Denied" depending on the policy checks.

Key policies act as the primary gate for CMK use. Even when IAM policies allow an action, the key policy must either grant permissions directly or allow IAM principals to use the key. Review key policies when debugging denied KMS requests.

Example key policy Below is a practical key policy example that:

Grants full administration to a KeyAdmin user.
Grants Encrypt/Decrypt/GenerateDataKey to a role, constrained by an encryption context condition.

{
  "Version": "2012-10-17",
  "Id": "key-default-1",
  "Statement": [
    {
      "Sid": "Allow administration of the key",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:user/KeyAdmin" },
      "Action": [
        "kms:*"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow use of the key",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/KeyUserRole" },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey"
      ],
      "Resource": "*",
      "Condition": {
        "StringEquals": {
          "kms:EncryptionContext:Purpose": "FinanceApp"
        }
      }
    }
  ]
}

Envelope encryption (data keys) Envelope encryption is the recommended pattern for performant, scalable encryption in AWS:

Use KMS to generate a data key (GenerateDataKey), receiving a plaintext data key and an encrypted copy (ciphertext) protected by the CMK.
Encrypt large data locally using the plaintext data key (symmetric AES‑GCM).
Store the encrypted data key alongside the ciphertext.
To decrypt, use KMS to decrypt the encrypted data key, then use the returned plaintext data key to decrypt the data locally.

Benefits: high performance (local symmetric crypto), fewer KMS API calls, and a clear key hierarchy for auditing and separation of duties.

A presentation slide titled "Envelope Encryption" showing a "Benefits" section with three numbered cards. The cards list "Performance optimization (local encryption)", "Key hierarchy for different data sets", and "Protection of the master key" (with a faint fourth reading "Reduced API costs").

Implementation patterns Common ways to use KMS:

Direct KMS API calls (GenerateDataKey, Encrypt, Decrypt).
AWS Encryption SDK (higher-level envelope encryption helpers and multi‑language support).
Service-specific integrations (S3 SSE‑KMS, EBS, RDS, Secrets Manager, SQS, etc.).

Choose the pattern based on performance, key control, and language/platform support.

A presentation slide titled "Envelope Encryption" showing three implementation patterns: 01 Direct KMS API, 02 AWS Encryption SDK, and 03 Service-specific (S3, RDS, etc.), arranged as rounded boxes under a central "Implementation Patterns" label.

Example: direct use of KMS with boto3 and local AES‑GCM encryption This sample shows generating a 256‑bit data key from KMS, encrypting locally with AES‑GCM, and retaining the encrypted data key for later decryption.

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

kms_client = boto3.client("kms")

# Step 1: Generate data key (plaintext + encrypted copy)
response = kms_client.generate_data_key(
    KeyId="alias/YourCustomerManagedKey",
    KeySpec="AES_256"
)

plaintext_data_key = response["Plaintext"]          # bytes (32 bytes for AES_256)
encrypted_data_key = response["CiphertextBlob"]    # bytes (encrypted under the CMK)

# Step 2: Encrypt your data locally using the plaintext data key (AES-GCM)
aesgcm = AESGCM(plaintext_data_key)
nonce = os.urandom(12)
data = b"Sensitive data to encrypt"
encrypted_data = aesgcm.encrypt(nonce, data, associated_data=None)

# Step 3: Store encrypted_data, nonce, and encrypted_data_key together securely
# (encrypted_data_key is required to recover the plaintext data key from KMS later)
print("Encrypted Data Key (hex):", encrypted_data_key.hex())
print("Nonce (hex):", nonce.hex())
print("Encrypted Data (hex):", encrypted_data.hex())

Service integrations KMS integrates directly with many AWS services to provide at‑rest or envelope encryption, including:

Storage: S3 (SSE‑KMS), EBS, EFS
Databases: RDS, DynamoDB, Redshift
Compute & app: Lambda environment variables (via Secrets Manager recommended), Elastic Beanstalk
Messaging & secrets: SQS, SNS, Secrets Manager, Systems Manager Parameter Store

Use service-managed server-side encryption for convenience, or envelope encryption for advanced control and performance.

A diagram titled "Service Integration With KMS" showing AWS KMS in the center connected to four boxes (Storage, Compute, Database, Application Services) with example AWS services and encryption integrations like S3 SSE‑KMS, EBS/EFS, Lambda env var encryption, RDS/DynamoDB, SQS/SNS, and Secrets Manager.

CloudFormation examples (illustrative) Below are illustrative CloudFormation snippets showing typical references to a KMS key ARN. Update ARNs and parameters to match your account and region.

# Amazon S3 bucket with SSE-KMS encryption
S3Bucket:
  Type: AWS::S3::Bucket
  Properties:
    BucketName: my-secure-bucket
    BucketEncryption:
      ServerSideEncryptionConfiguration:
        - ServerSideEncryptionByDefault:
            SSEAlgorithm: aws:kms
            KMSMasterKeyID: arn:aws:kms:us-east-1:123456789012:key/abcd-efgh-ijkl

# Amazon EBS volume encrypted with KMS key
EBSVolume:
  Type: AWS::EC2::Volume
  Properties:
    Size: 100
    AvailabilityZone: us-east-1a
    Encrypted: true
    KmsKeyId: arn:aws:kms:us-east-1:123456789012:key/mnop-qrst-uvwx

# Lambda function (note: encrypt/decrypt environment values outside CFN or use Secrets Manager)
MyLambda:
  Type: AWS::Lambda::Function
  Properties:
    FunctionName: MyEncryptedLambda
    Handler: index.handler
    Role: arn:aws:iam::123456789012:role/lambda-execution-role
    Code:
      S3Bucket: my-code-bucket
      S3Key: lambda-code.zip
    Runtime: python3.9
    Environment:
      Variables:
        SECRET: "EncryptedValue"  # Use KMS / Secrets Manager to manage secret values

# SQS queue with KMS encryption enabled
SQSQueue:
  Type: AWS::SQS::Queue
  Properties:
    QueueName: my-secure-queue
    KmsMasterKeyId: arn:aws:kms:us-east-1:123456789012:key/abcd-efgh-ijkl
    KmsDataKeyReusePeriodSeconds: 300

# Secrets Manager secret encrypted with KMS key
SecretsManagerSecret:
  Type: AWS::SecretsManager::Secret
  Properties:
    Name: MySecret
    KmsKeyId: arn:aws:kms:us-east-1:123456789012:key/abcd-efgh-ijkl
    Description: "Secret encrypted with customer managed KMS key"

# Systems Manager Parameter Store SecureString with KMS key
SSMParameter:
  Type: AWS::SSM::Parameter
  Properties:
    Name: /myapp/database/password
    Type: SecureString
    Value: "MySuperSecretPassword"
    KeyId: arn:aws:kms:us-east-1:123456789012:key/abcd-efgh-ijkl

Key rotation strategies Rotation options and tradeoffs:

Strategy	When to use	Pros	Cons
Automatic rotation (KMS)	Symmetric CMKs with KMS-origin key material	Low operational overhead, built-in schedule	Not available for asymmetric keys or imported key material
Manual rotation	Asymmetric keys, imported material, or custom workflows	Full control of rekeying, timing, and re-encryption	Operationally complex; requires alias management and re-encryption planning

Production best practice: use key aliases (for example alias/my-key) in applications. When rotating, create a new CMK and repoint the alias to the new CMK. Applications continue to use the alias without configuration changes. Note: after alias repointing, existing ciphertexts remain encrypted under the original CMK; either keep the old CMK available for decryptions or re-encrypt data under the new CMK.

A slide titled "Key Rotation Strategies" showing a side-by-side comparison table of Automatic Rotation vs Manual Rotation across aspects like frequency, application impact, key material management, data re-encryption, alias usage, and complexity.

Summary

AWS KMS is the central key management service for most AWS encryption use cases.
Use CMKs when you require control over key policies, grants, and rotation.
Envelope encryption (GenerateDataKey + local symmetric encryption) is recommended for performance and scale.
Key policies are the primary access gate — ensure they allow intended IAM principals to use the CMK.
Use aliases to simplify rotation and reduce application changes.

Links and references

AWS KMS Developer Guide: https://docs.aws.amazon.com/kms/latest/developerguide/
AWS Encryption SDK: https://docs.aws.amazon.com/encryption-sdk/latest/developer-guide/
AWS CloudHSM: https://docs.aws.amazon.com/cloudhsm/latest/userguide/
AWS Key Management Service best practices: https://docs.aws.amazon.com/kms/latest/developerguide/best-practices.html

For most teams, combine service-side KMS integrations for convenience with envelope encryption for high‑throughput or client‑side confidentiality requirements. Review AWS documentation links above for the latest service features and limits.

Introduction

Domain 1 - SDLC Automation

Domain 2 - Configuration Management and IaC

Domain 3 - Resilient Cloud Solutions

Domain 4 - Monitoring and Logging

Domain 5 - Incident and Event Response

Domain 6 - Security and Compliance

AWS KMS and Customer Managed Keys

Watch Video