Key Rotation & Management

Overview

Key rotation is the process of replacing cryptographic keys with new ones to limit the amount of data encrypted under a single key and reduce the impact of a potential key compromise. AWS provides both automatic and manual rotation options for different key types.

Understanding key rotation is important for the SAA-C03 exam because it's a fundamental security best practice for compliance frameworks like PCI-DSS, HIPAA, and SOC 2. You must know when automatic rotation is available, how to implement manual rotation, and how to manage key lifecycles across different AWS services.

Automatic Rotation Preserves Old Material

Automatic key rotation in KMS creates new key material while retaining old key material for decryption. Old data doesn't need to be re-encrypted, but new data uses the new key material.

Exam Tip

Focus on automatic vs manual rotation, key aliases for abstraction, cross-account key sharing, and key deletion/recovery procedures. Know which key types support automatic rotation.

Key Concepts

Automatic Key Rotation (KMS)

Automatic Key Rotation

KMS automatic rotation handles key material updates transparently:

Automatic Key Rotation Details

Aspect	Details
Period	Configurable: 90-2560 days (default 365)
Key ID/ARN	Unchanged
Old Key Material	Retained indefinitely
Old Data Decryption	Automatic (KMS tracks key material versions)
New Data Encryption	Uses new key material automatically

SHEnable Automatic Key Rotation

# Enable rotation (default 365 days)
aws kms enable-key-rotation --key-id alias/my-key

# Set custom rotation period (e.g., 180 days)
aws kms update-key-rotation-period \
  --key-id alias/my-key \
  --rotation-period-in-days 180

# Check rotation status
aws kms get-key-rotation-status --key-id alias/my-key

# List key rotations
aws kms list-key-rotations --key-id alias/my-key

Keys That Support Automatic Rotation

Automatic Rotation Support

Key Type	Automatic Rotation	Notes
Customer managed (symmetric)	Yes	Configurable period
AWS managed keys	Yes	~3 years (AWS-controlled)
Customer managed (asymmetric)	No	Must use manual rotation
Imported key material	No	Must use manual rotation
Custom key store (CloudHSM)	No	Must use manual rotation
HMAC keys	No	Must use manual rotation

Manual Key Rotation

For keys that don't support automatic rotation, use manual rotation with aliases:

Manual Key Rotation Process

TEXTManual Key Rotation Process

STEP 1: Create new key
  aws kms create-key --description "My app key v2"
  → Returns new key ID: 2222-2222-2222

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

STEP 3: Applications continue using alias
  → Encryption uses new key automatically
  → No code changes required

STEP 4: Keep old key for decryption
  → Old key (1111-1111-1111) still decrypts old data
  → Schedule deletion after data migration

STEP 5: Re-encrypt data (optional)
  → Decrypt with old key, encrypt with new key
  → Or let natural data lifecycle handle it

Key Aliases

Key Alias Best Practices

Aliases provide abstraction between applications and KMS keys:

TEXTKey Alias Best Practices

Alias Naming Conventions:
├── alias/production/database-key
├── alias/production/s3-encryption
├── alias/development/app-secrets
└── alias/shared/cross-account-key

Benefits:
├── No code changes during key rotation
├── Meaningful names for key purpose
├── Easy to identify key usage
├── One alias per key (but keys can have multiple aliases)

Alias Rules:
├── Must start with "alias/"
├── Cannot start with "alias/aws/" (reserved)
├── Unique within account and region
├── Maximum 256 characters
└── Can be updated to point to different key

How It Works

Automatic Rotation Internals

Key Material Versioning

KMS retains all key material versions. When decrypting, KMS automatically determines which version was used to encrypt the data.

TEXTHow Automatic Rotation Works

Year 1: Key created
  Key ID: 1234-5678
  Key Material Version: v1
  All encrypt/decrypt uses v1

Year 2: Rotation occurs
  Key ID: 1234-5678 (UNCHANGED)
  Key Material Versions: v1, v2
  NEW encryptions use v2
  OLD data decrypts using v1 (automatic)

Year 3: Another rotation
  Key ID: 1234-5678 (UNCHANGED)
  Key Material Versions: v1, v2, v3
  NEW encryptions use v3
  OLD data decrypts using appropriate version

Key Point: KMS automatically determines which
key material version to use based on metadata
stored with each encrypted data key.

Cross-Account Key Sharing — Figure 3: Share KMS keys across accounts with key policies and grants

JSONCross-Account Key Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Allow use from external account",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::444455556666:root"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    },
    {
      "Sid": "Allow grant creation",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::444455556666:root"
      },
      "Action": [
        "kms:CreateGrant",
        "kms:ListGrants",
        "kms:RevokeGrant"
      ],
      "Resource": "*",
      "Condition": {
        "Bool": {
          "kms:GrantIsForAWSResource": "true"
        }
      }
    }
  ]
}

Key Deletion Process

Key Deletion is Permanent

There is NO recovery after deletion completes. Always use the maximum 30-day waiting period for production keys.

TEXTKey Deletion Lifecycle

ACTIVE KEY
    ↓
Schedule deletion (7-30 day waiting period)
    ↓
PENDING DELETION (key disabled)
    ↓
During waiting period:
  - Key cannot be used for cryptographic operations
  - CloudWatch alarm triggered
  - Can cancel deletion if needed
    ↓
After waiting period:
  - Key and all key material PERMANENTLY deleted
  - Data encrypted with key becomes UNRECOVERABLE
  - Key ID cannot be reused

IMPORTANT: There is NO recovery after deletion completes!

SHSchedule Key Deletion

# Schedule deletion with 30-day waiting period (recommended)
aws kms schedule-key-deletion \
  --key-id 1234-5678-abcd \
  --pending-window-in-days 30

# Cancel deletion during waiting period
aws kms cancel-key-deletion \
  --key-id 1234-5678-abcd

# Re-enable key after cancellation
aws kms enable-key --key-id 1234-5678-abcd

Use Cases

Use Case 1: Annual Key Rotation for Compliance

Scenario: PCI-DSS requires annual cryptographic key rotation.

Solution:

Enable automatic rotation on customer managed KMS keys
Set rotation period to 365 days
Document rotation schedule for auditors
Monitor rotations via CloudTrail

SHCompliance Key Rotation Setup

# Enable automatic rotation
aws kms enable-key-rotation --key-id alias/pci-card-data-key

# Verify rotation is enabled
aws kms get-key-rotation-status --key-id alias/pci-card-data-key

# Set up CloudWatch alarm for rotation events
# Monitor for KMS:RotateKey events in CloudTrail

Use Case 2: Rotating Imported Key Material

Scenario: Organization uses imported key material that doesn't support automatic rotation.

Solution:

Create new KMS key with new imported material
Update key alias to point to new key
Keep old key for decryption
Re-encrypt data during maintenance window
Schedule old key deletion after migration

Use Case 3: Emergency Key Rotation

Scenario: Security incident requires immediate key rotation.

Solution:

Create new key immediately
Update alias to new key
Disable old key (prevents new encryptions)
Audit all usage of compromised key
Re-encrypt sensitive data as priority
Schedule old key deletion after recovery

SHEmergency Key Rotation

# 1. Create new key
NEW_KEY=$(aws kms create-key --description "Emergency replacement" \
  --query 'KeyMetadata.KeyId' --output text)

# 2. Update alias to new key
aws kms update-alias \
  --alias-name alias/production-key \
  --target-key-id $NEW_KEY

# 3. Disable old key immediately
aws kms disable-key --key-id OLD_KEY_ID

# 4. Investigate and re-encrypt critical data

Use Case 4: Multi-Region Key Rotation

Scenario: Application uses multi-region keys for disaster recovery.

Solution:

Enable rotation on primary key
Rotation automatically applies to all replicas
Same key material across all regions
No additional configuration needed

Best Practices

Key Rotation Best Practices

Enable automatic rotation for all customer managed keys
- Set appropriate period based on compliance requirements
- 365 days is common for most frameworks
- Some may require 90 days (high security)
Use aliases for all key references
- Never hardcode key IDs in applications
- Enables seamless manual rotation
- Easier key management and auditing
Document key rotation procedures
- Include in runbooks
- Define who can rotate keys
- Specify communication procedures
Test rotation in non-production first
- Verify applications handle rotation
- Check for hardcoded key references
- Test decryption of old data

Key Lifecycle Best Practices

Never delete keys without verification
- Audit all services using the key
- Check S3 buckets, EBS volumes, RDS instances
- Verify no active grants or policies
Use maximum deletion waiting period (30 days)
- Provides recovery window
- Set CloudWatch alarm for pending deletions
- Review deletions during waiting period
Disable before deleting
- Disable key first
- Monitor for failed cryptographic operations
- Identify dependent resources
Maintain key inventory
- Tag keys with owner, purpose, environment
- Regular audit of key usage
- AWS Config rules for compliance

Security Best Practices

Separate keys by environment
- Production keys separate from development
- Different keys for different applications
- Limit blast radius
Audit key usage regularly
- CloudTrail logs all KMS operations
- Set up alerts for unusual activity
- Review who has access to keys
Implement least privilege
- Separate encrypt and decrypt permissions
- Use conditions in key policies
- Grant minimum required permissions

Common Exam Scenarios

Exam Scenarios

Scenario	Solution	Why
Annual key rotation requirement	Enable automatic rotation	KMS handles transparently
Rotate imported key material	Manual rotation with aliases	Imported keys dont support auto-rotation
Applications reference key by ID	Use aliases, update alias target	No code changes needed
Accidentally deleted key	Cancel deletion during waiting period	7-30 day recovery window
Key compromised	Create new key, update alias, disable old	Emergency rotation procedure
Share key across accounts	Add external account to key policy	Key policy required for cross-account
Rotate asymmetric key	Manual rotation with aliases	Asymmetric keys dont auto-rotate
Track who rotated keys	CloudTrail logs	All KMS operations are logged

Common Pitfalls

Pitfall 1: Hardcoding Key IDs

Mistake: Embedding key IDs directly in application code.

Why it fails: Manual rotation requires code changes and redeployment

Correct Approach: Always use key aliases in applications

Pitfall 2: Deleting Keys Without Audit

Mistake: Deleting KMS key without checking dependencies.

Why it fails: Data encrypted with deleted key becomes permanently inaccessible

Correct Approach: Audit all resources using the key; disable first to identify dependencies

Pitfall 3: Short Deletion Waiting Period

Mistake: Setting 7-day deletion window for production keys.

Why it fails: Limited time to identify and resolve issues

Correct Approach: Use 30-day waiting period for production keys

Pitfall 4: Assuming All Keys Auto-Rotate

Mistake: Expecting automatic rotation for imported or asymmetric keys.

Why it fails: Only symmetric customer managed keys support auto-rotation

Correct Approach: Implement manual rotation for unsupported key types

Pitfall 5: Forgetting Old Key Material

Mistake: Thinking rotation replaces old key material.

Why it fails: Old data still needs old key material for decryption

Correct Approach: Understand that KMS retains all key material versions

Security

AWS KMS

Key management and automatic rotation

Security

AWS Secrets Manager

Automatic rotation of database credentials

Management

AWS CloudTrail

Audit trail for all key operations

Management

AWS Config

Compliance rules for key rotation

Monitoring

Amazon CloudWatch

Alarms for key deletion and rotation events

Security

AWS CloudHSM

Hardware security modules for custom key stores

Quick Reference

Rotation Support Matrix

Key Type	Auto-Rotation	Manual Rotation
Symmetric (customer managed)	Yes	Yes
Symmetric (AWS managed)	Yes (AWS-controlled)	No
Asymmetric RSA	No	Yes
Asymmetric ECC	No	Yes
HMAC	No	Yes
Imported key material	No	Yes
CloudHSM key store	No	Yes

Key Deletion Waiting Periods

Deletion Waiting Periods

Setting	Period
Minimum	7 days
Maximum	30 days
Default	30 days
Recommended	30 days (production)

Rotation Monitoring

JSONCloudWatch Alarm for Rotation

{
  "AlarmName": "KMS-Key-Rotation-Monitor",
  "MetricName": "RotateKey",
  "Namespace": "AWS/KMS",
  "Statistic": "Sum",
  "Period": 86400,
  "EvaluationPeriods": 1,
  "Threshold": 1,
  "ComparisonOperator": "GreaterThanOrEqualToThreshold"
}

CLI Commands

SHKey Rotation CLI Commands

# Enable automatic rotation
aws kms enable-key-rotation --key-id KEY_ID

# Disable automatic rotation
aws kms disable-key-rotation --key-id KEY_ID

# Check rotation status
aws kms get-key-rotation-status --key-id KEY_ID

# List all key rotations
aws kms list-key-rotations --key-id KEY_ID

# Rotate key immediately (on-demand)
aws kms rotate-key-on-demand --key-id KEY_ID

# Update alias for manual rotation
aws kms update-alias \
  --alias-name alias/my-key \
  --target-key-id NEW_KEY_ID

# Schedule key deletion
aws kms schedule-key-deletion \
  --key-id KEY_ID \
  --pending-window-in-days 30

Test Your Knowledge

A company needs to rotate KMS keys annually for PCI-DSS compliance. The keys are customer managed symmetric keys. What is the recommended approach?

AManually create new keys each year

BEnable automatic key rotation

CUse AWS managed keys

DRe-encrypt all data with new keys

Which KMS key type does NOT support automatic key rotation?

ACustomer managed symmetric keys

BAWS managed keys

CImported key material

DAll key types support automatic rotation

An application hardcodes a KMS key ID. The security team needs to rotate the key. What is the best approach for future flexibility?

AUpdate the key ID in application code

BCreate a key alias and update application to use alias

CDelete the old key and create new one with same ID

DUse AWS managed keys instead

A KMS key was accidentally scheduled for deletion. What is the recovery window?

ANo recovery possible

B7 to 30 days depending on configuration

C24 hours

D90 days

Key concepts

Overview

Automatic Rotation Preserves Old Material

Key Concepts

Automatic Key Rotation (KMS)

Automatic Key Rotation

Automatic Key Rotation Details

Keys That Support Automatic Rotation

Automatic Rotation Support

Manual Key Rotation

Manual Key Rotation Process

Key Aliases

Key Alias Best Practices

How It Works

Automatic Rotation Internals

Key Material Versioning

Cross-Account Key Sharing

Key Deletion Process

Key Deletion is Permanent

Use Cases

Use Case 1: Annual Key Rotation for Compliance

Use Case 2: Rotating Imported Key Material

Use Case 3: Emergency Key Rotation

Use Case 4: Multi-Region Key Rotation

Best Practices

Key Rotation Best Practices

Key Lifecycle Best Practices

Security Best Practices

Common Exam Scenarios

Exam Scenarios

Common Pitfalls

Pitfall 1: Hardcoding Key IDs

Pitfall 2: Deleting Keys Without Audit

Pitfall 3: Short Deletion Waiting Period

Pitfall 4: Assuming All Keys Auto-Rotate

Pitfall 5: Forgetting Old Key Material

Related Services

AWS KMS

AWS Secrets Manager

AWS CloudTrail

AWS Config

Amazon CloudWatch

AWS CloudHSM

Quick Reference

Rotation Support Matrix

Rotation Support Matrix

Key Deletion Waiting Periods

Deletion Waiting Periods

Rotation Monitoring

CLI Commands

Test Your Knowledge

Further Reading

Related services