AWS KMS (Key Management Service)

Overview

AWS Key Management Service (KMS) is a managed service that makes it easy to create and control the cryptographic keys used to protect your data. KMS is integrated with most AWS services and provides centralized key management with full audit capability through CloudTrail.

Understanding KMS is critical for the SAA-C03 exam because it's the foundation for encryption across AWS. You must understand key types, key policies, grants, envelope encryption, and how KMS integrates with other services. This is a high-weight exam topic.

Key Concepts

KMS Key Types

AWS Managed Keys

AWS managed keys are created automatically when you first use encryption in an AWS service:

AWS Managed Key Format: aws/service-name

Examples:
├── aws/s3         → Amazon S3 encryption
├── aws/ebs        → EBS volume encryption
├── aws/rds        → RDS database encryption
├── aws/lambda     → Lambda environment variables
├── aws/secretsmanager → Secrets Manager secrets
└── aws/dynamodb   → DynamoDB encryption

Characteristics:
- Created automatically on first use
- Cannot modify key policy
- Cannot share across accounts
- Automatic annual rotation
- No monthly key fee
- Cannot use for client-side encryption

Customer Managed Keys (CMKs)

Customer managed keys provide full control over key lifecycle and access:

Customer Managed Key Features:

Control:
├── Define key policies
├── Enable/disable keys
├── Set key rotation
├── Create aliases
├── Tag keys
└── Delete keys (with waiting period)

Usage:
├── Encrypt/decrypt data
├── Generate data keys
├── Sign/verify
└── Derive shared secrets (ECDH)

Cross-Account:
├── Share via key policy
├── Use with grants
└── Use in other services

Key Policies

Every KMS key must have a key policy. Key policies are the primary way to control access to KMS keys.

{
  "Version": "2012-10-17",
  "Id": "key-default-1",
  "Statement": [
    {
      "Sid": "Enable IAM policies",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    }
  ]
}

Key Policy vs IAM Policy

{
  "Sid": "Allow external account",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::444455556666:root"
  },
  "Action": [
    "kms:Encrypt",
    "kms:Decrypt",
    "kms:GenerateDataKey"
  ],
  "Resource": "*"
}

Grants

Grants provide temporary, scoped permissions to KMS keys without modifying the key policy:

# Create a grant for an EC2 instance role
aws kms create-grant \
  --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \
  --grantee-principal arn:aws:iam::111122223333:role/EC2Role \
  --operations Decrypt Encrypt \
  --retiring-principal arn:aws:iam::111122223333:role/AdminRole

# Response includes GrantToken for immediate use
{
  "GrantToken": "AQpAM...",
  "GrantId": "1a2b3c..."
}

How It Works

Envelope Encryption

ENCRYPT:
1. Call GenerateDataKey API
   └── KMS returns:
       ├── Plaintext data key (use for encryption)
       └── Encrypted data key (store with data)

2. Encrypt data with plaintext data key (AES-256)

3. Store:
   ├── Encrypted data
   └── Encrypted data key (envelope)

4. Discard plaintext data key from memory

DECRYPT:
1. Retrieve encrypted data key

2. Call Decrypt API
   └── KMS decrypts data key using KMS key

3. Decrypt data with plaintext data key

4. Discard plaintext data key from memory

Data Key Caching

For high-volume encryption, use the AWS Encryption SDK with data key caching:

Without caching:
├── 10,000 encryptions = 10,000 GenerateDataKey calls
├── Latency: ~50ms per call
└── Cost: Higher KMS usage

With caching:
├── 10,000 encryptions = ~10 GenerateDataKey calls
├── Cache reuses data keys (by byte limit or time)
└── Cost: Much lower KMS usage

Cache limits (configurable):
├── Max age: How long to cache key
├── Max bytes: Encrypt up to X bytes
├── Max messages: Encrypt up to X messages
└── Security tradeoff: More reuse = more exposure if key compromised

Multi-Region Keys

Primary Key (us-east-1):
  Key ID: mrk-1234abcd...
  ARN: arn:aws:kms:us-east-1:111122223333:key/mrk-1234...
  Type: Primary

Replica Key (eu-west-1):
  Key ID: mrk-1234abcd...  ← Same key ID!
  ARN: arn:aws:kms:eu-west-1:111122223333:key/mrk-1234...
  Type: Replica

Use Cases:
├── Disaster recovery
├── Global data with local access
├── Signed data verification across regions
└── Low-latency decryption in multiple regions

Key Point: Data encrypted in one region can be decrypted in another

Key Rotation

Automatic Key Rotation

Automatic Rotation (Customer Managed Keys):
├── Period: Every 365 days (configurable 90-2560 days)
├── Creates new key material
├── Retains old key material indefinitely
├── Same key ID and ARN
├── Old data automatically decrypted with old material
└── New data encrypted with new material

AWS Managed Keys:
└── Automatic rotation every ~3 years (varies by service)

Cannot rotate:
├── Imported key material
├── Asymmetric keys
└── Keys in custom key stores (CloudHSM)

Manual Key Rotation

For keys that don't support automatic rotation:

1. Create new KMS key

2. Update alias to point to new key:
   aws kms update-alias \
     --alias-name alias/my-app-key \
     --target-key-id new-key-id

3. Applications using alias automatically use new key

4. Keep old key for decryption of existing data

5. Re-encrypt data when practical (optional)

6. Schedule old key deletion after data migration

Use Cases

Use Case 1: S3 Encryption with Customer Managed Key

Scenario: Company requires using its own keys for S3 encryption with full audit trail.

Solution:

• Create customer managed KMS key
• Configure S3 bucket default encryption with SSE-KMS
• Enable CloudTrail logging for KMS key usage
• Audit who decrypted what objects

Use Case 2: Cross-Account Encrypted Data Sharing

Scenario: Production account stores encrypted data; analytics account needs to read it.

Solution:

1. Create KMS key in production account
2. Add cross-account access in key policy:

{
  "Sid": "AllowAnalyticsAccount",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::ANALYTICS_ACCOUNT:role/DataAnalysisRole"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*"
}

1. Analytics account role also needs IAM permissions for KMS
2. Analytics role can now decrypt data from S3

Use Case 3: Encrypt EBS Volumes by Default

Scenario: Compliance requires all EBS volumes encrypted with company-managed keys.

Solution:

• Create customer managed KMS key for EBS
• Enable EBS encryption by default at account level
• Set default KMS key to customer managed key
• All new volumes automatically encrypted

# Enable default encryption
aws ec2 enable-ebs-encryption-by-default

# Set default key (customer managed)
aws ec2 modify-ebs-default-kms-key-id \
  --kms-key-id alias/ebs-default-key

Use Case 4: Disaster Recovery with Multi-Region Keys

Scenario: Application encrypts data in us-east-1; need to decrypt in eu-west-1 for DR.

Solution:

• Create multi-region primary key in us-east-1
• Create replica in eu-west-1
• Replicate encrypted S3 data to eu-west-1
• DR application can decrypt using regional replica
• Same key ID works in both regions

Best Practices

Key Management Best Practices

1. Use aliases for key abstraction

   • Reference keys by alias, not key ID
   • Easier rotation and key replacement
   • Example: alias/production-data-key

2. Enable automatic rotation for customer managed keys

   • Set appropriate rotation period (365 days default)
   • KMS handles rotation transparently
   • Old data remains decryptable

3. Use separate keys per environment/application

   • Production vs development keys
   • Blast radius reduction
   • Independent key policies

4. Implement least privilege in key policies

   • Grant only required actions
   • Use conditions for additional control
   • Separate encrypt and decrypt permissions when possible

Security Best Practices

1. Enable CloudTrail logging for all KMS operations

   • Track who used keys and when
   • Detect unauthorized access attempts
   • Required for compliance

2. Use grants for temporary permissions

   • Avoid modifying key policies frequently
   • Time-limited access
   • Easy to revoke

3. Set key deletion waiting period to maximum (30 days)

   • Recovery time if accidental deletion
   • Review pending deletions regularly

4. Monitor with CloudWatch

   • Set alarms for unusual API activity
   • Track ThrottlingException errors
   • Monitor key state changes

Cost Optimization

1. Use AWS managed keys when possible

   • No monthly key fee
   • Suitable for most use cases

2. Consider data key caching for high volume

   • Reduces GenerateDataKey calls
   • Use AWS Encryption SDK

3. Clean up unused keys

   • Disabled keys still incur charges
   • Schedule deletion for unneeded keys

Common Exam Scenarios

Common Pitfalls

Related Services

Quick Reference

KMS Limits

KMS Pricing

Key Alias Format

Alias Format: alias/key-name

Examples:
├── alias/aws/s3          (AWS managed - cannot create)
├── alias/my-app-key      (Customer managed)
├── alias/production/db   (Hierarchical naming)
└── alias/mrk-replica     (Multi-region)

Rules:
├── Must start with alias/
├── Cannot start with alias/aws/ (reserved)
├── Unique within account and region
└── Can point to only one key

CLI Commands

# Create customer managed key
aws kms create-key \
  --description "My application key" \
  --key-usage ENCRYPT_DECRYPT \
  --key-spec SYMMETRIC_DEFAULT

# Create alias
aws kms create-alias \
  --alias-name alias/my-app-key \
  --target-key-id 1234abcd-12ab-34cd-56ef-1234567890ab

# Enable key rotation
aws kms enable-key-rotation \
  --key-id alias/my-app-key

# Encrypt data (< 4 KB)
aws kms encrypt \
  --key-id alias/my-app-key \
  --plaintext fileb://data.txt \
  --output text --query CiphertextBlob | base64 --decode > encrypted.bin

# Generate data key (for envelope encryption)
aws kms generate-data-key \
  --key-id alias/my-app-key \
  --key-spec AES_256

Test Your Knowledge

Further Reading

• AWS KMS Developer Guide
• KMS Key Policies
• Envelope Encryption
• Multi-Region Keys
• AWS Encryption SDK
• KMS Best Practices