← Back to Tutorials
Tutorial 17 Intermediate

How to Configure AWS KMS for Enterprise Security

Master key management with customer managed keys, least-privilege policies, automatic rotation, and continuous compliance monitoring for regulatory requirements including CMMC and NIST 800-171.

30 min implementation
15 min read
Key Management

What You'll Learn

Why AWS KMS Configuration Is Critical

AWS Key Management Service (KMS) is the foundation of enterprise cloud encryption. Every encrypted S3 bucket, EBS volume, RDS database, and Secrets Manager secret relies on KMS keys for protection. Misconfigured KMS keys can expose sensitive data, violate compliance requirements, and block business-critical operations.

The IBM Cost of a Data Breach Report 2024 found that the average global breach cost reached $4.88 million—a 10% increase from the prior year and the largest spike since the pandemic. For organizations subject to CMMC requirements, encryption key management violations can result in loss of contract eligibility and removal from the Defense Industrial Base.

The Four Most Dangerous KMS Misconfigurations

1

Using AWS Managed Keys for Sensitive Data

AWS managed keys (aws/s3, aws/ebs, etc.) don't provide granular control over key policies, rotation schedules, or cross-account access. For compliance frameworks like CMMC, customer managed keys are required.

2

Overly Permissive Key Policies

Default key policies often grant broad permissions using wildcards or allow unrestricted IAM access. This violates the principle of least privilege and can expose encrypted data to unauthorized users.

3

No Automated Key Rotation

NIST SP 800-171 requires regular key rotation for protecting Controlled Unclassified Information (CUI). Manual rotation is error-prone and doesn't meet continuous compliance requirements.

4

Insufficient Audit Logging

Without proper CloudTrail integration and monitoring, you cannot demonstrate compliance with key usage requirements or detect unauthorized access attempts.

💡
FIPS 140-3 Level 3 Update: As of February 2025, AWS KMS HSMs are certified at FIPS 140-3 Security Level 3. This means standard AWS KMS now meets the highest FIPS validation levels—previously this required AWS CloudHSM.
1

Create Customer Managed Keys

~8 minutes

Customer managed keys provide the granular control required for enterprise security and compliance. Unlike AWS managed keys, you control the key policy, rotation schedule, and can share encrypted resources across accounts.

Prerequisites

  • AWS account with KMS full access permissions
  • AWS CLI configured with appropriate credentials
  • Understanding of your data classification levels
  • CloudTrail enabled for audit logging

Console Steps

1.1 Navigate to AWS KMS Console

  • Sign in to AWS Console
  • Navigate to Key Management Service (KMS)
  • Click "Customer managed keys" in the left navigation
  • Click "Create key"

1.2 Configure Key Specifications

  • Key type: Symmetric (for most encryption use cases)
  • Key usage: Encrypt and decrypt
  • Key spec: SYMMETRIC_DEFAULT
  • Regionality: Single-Region key (for data locality compliance)
  • Click "Next"
⚠️
Compliance Note: Use single-region keys for sensitive data to maintain data locality compliance. Multi-region keys can violate data sovereignty requirements for certain government contracts.

1.3 Add Key Metadata

  • Alias: alias/production-encryption-2026
  • Description: Production encryption key for sensitive data - Created [DATE]
  • Tags:
    • Environment: Production
    • DataClassification: Sensitive
    • Owner: SecurityTeam
    • CostCenter: Security
  • Click "Next"
AWS CLI - Create Customer Managed Key 
# Create customer managed key
aws kms create-key \
    --description "Production encryption key for sensitive data" \
    --key-usage ENCRYPT_DECRYPT \
    --key-spec SYMMETRIC_DEFAULT \
    --tags TagKey=Environment,TagValue=Production \
           TagKey=DataClassification,TagValue=Sensitive \
           TagKey=Owner,TagValue=SecurityTeam

# Note the KeyId from the output, then create an alias
aws kms create-alias \
    --alias-name alias/production-encryption-2026 \
    --target-key-id YOUR-KEY-ID

# Verify the key was created
aws kms describe-key --key-id alias/production-encryption-2026

1.4 Define Key Administrative Permissions

  • Select specific IAM users/roles for key administration (NOT root)
  • Recommended administrators:
    • Security team lead IAM role
    • KMS administrator role
    • Break-glass emergency access role
  • Enable "Allow key administrators to delete this key"
  • Click "Next"

1.5 Define Key Usage Permissions

  • Select specific IAM users and roles that need to encrypt/decrypt data
  • Do NOT select wildcard permissions or "All IAM users"
  • Click "Next"
✓
Key Created: Your customer managed key is now created with proper metadata and initial permissions. Next, we'll configure a more restrictive key policy.
2

Configure Enterprise-Grade Key Policies

~8 minutes

Key policies are the primary access control mechanism for KMS keys. For compliance, policies must implement strict access controls, condition-based restrictions, and comprehensive auditing.

Console Steps

2.1 Access Key Policy Editor

  • In the KMS console, click on your newly created key
  • Go to the "Key policy" tab
  • Click "Switch to policy view" for advanced editing

2.2 Implement Secure Key Policy

Replace the default policy with a least-privilege policy:

JSON - Enterprise Key Policy 
{
    "Version": "2012-10-17",
    "Id": "enterprise-key-policy",
    "Statement": [
        {
            "Sid": "EnableIAMUserPermissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::ACCOUNT-ID:root"
            },
            "Action": "kms:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "kms:CallerAccount": "ACCOUNT-ID"
                }
            }
        },
        {
            "Sid": "KeyAdministration",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::ACCOUNT-ID:role/KMSAdministrator",
                    "arn:aws:iam::ACCOUNT-ID:role/SecurityTeamLead"
                ]
            },
            "Action": [
                "kms:Create*",
                "kms:Describe*",
                "kms:Enable*",
                "kms:List*",
                "kms:Put*",
                "kms:Update*",
                "kms:Revoke*",
                "kms:Disable*",
                "kms:Get*",
                "kms:Delete*",
                "kms:ScheduleKeyDeletion",
                "kms:CancelKeyDeletion",
                "kms:TagResource",
                "kms:UntagResource"
            ],
            "Resource": "*"
        },
        {
            "Sid": "KeyUsageForEncryption",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::ACCOUNT-ID:role/ApplicationRole",
                    "arn:aws:iam::ACCOUNT-ID:role/DataProcessingRole"
                ]
            },
            "Action": [
                "kms:Encrypt",
                "kms:Decrypt",
                "kms:ReEncrypt*",
                "kms:GenerateDataKey*",
                "kms:DescribeKey"
            ],
            "Resource": "*"
        },
        {
            "Sid": "DenyInsecureTransport",
            "Effect": "Deny",
            "Principal": "*",
            "Action": "*",
            "Resource": "*",
            "Condition": {
                "Bool": {
                    "aws:SecureTransport": "false"
                }
            }
        }
    ]
}
⚠️
Important: Replace ACCOUNT-ID with your actual AWS account ID. Test key access after applying the policy to ensure your applications still function correctly.

2.3 Add Encryption Context Requirements (Optional)

For additional security, require encryption context for all operations:

JSON - Policy Statement with Encryption Context 
{
    "Sid": "RequireEncryptionContext",
    "Effect": "Allow",
    "Principal": {
        "AWS": "arn:aws:iam::ACCOUNT-ID:role/ApplicationRole"
    },
    "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:GenerateDataKey*"
    ],
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "kms:EncryptionContext:Environment": "Production"
        }
    }
}

2.4 Validate Policy Syntax

  • Click "Save changes" to validate JSON syntax
  • Test key access with AWS CLI:
AWS CLI - Test Key Access 
# Test key accessibility
aws kms describe-key --key-id alias/production-encryption-2026

# Test encryption operation
aws kms encrypt \
    --key-id alias/production-encryption-2026 \
    --plaintext "test data" \
    --query CiphertextBlob \
    --output text
✓
Policy Configured: Your key policy now implements least-privilege access control. Only specified roles can administer or use the key.
3

Enable Automatic Key Rotation

~5 minutes

Automatic key rotation meets NIST SP 800-171 requirements for cryptographic key management. AWS KMS handles rotation transparently—existing encrypted data remains accessible while new data uses the new key material.

Console Steps

3.1 Enable Automatic Key Rotation

  • In your KMS key details, go to the "Key rotation" tab
  • Click "Edit"
  • Enable "Automatically rotate this KMS key"
  • Set rotation period (90-2560 days, default 365)
  • Click "Save"
AWS CLI - Enable Key Rotation 
# Enable automatic rotation with default 365-day period
aws kms enable-key-rotation \
    --key-id alias/production-encryption-2026

# Or specify a custom rotation period (e.g., 180 days)
aws kms enable-key-rotation \
    --key-id alias/production-encryption-2026 \
    --rotation-period-in-days 180

# Verify rotation is enabled
aws kms get-key-rotation-status \
    --key-id alias/production-encryption-2026
💡
How Rotation Works: When AWS KMS rotates a key, it generates new cryptographic material but keeps all previous versions. New encrypt operations use the new material, while decrypt operations automatically use the correct version based on the ciphertext.

3.2 Enable Rotation for All Customer Managed Keys

Use this script to enable rotation across all your customer managed keys:

Bash - Enable Rotation for All Keys 
#!/bin/bash
# Enable rotation for all customer managed keys in current region

echo "Checking key rotation status for all customer managed keys..."

for key_id in $(aws kms list-keys --query 'Keys[].KeyId' --output text); do
    # Get key metadata
    key_manager=$(aws kms describe-key --key-id "$key_id" \
        --query 'KeyMetadata.KeyManager' --output text 2>/dev/null)
    key_state=$(aws kms describe-key --key-id "$key_id" \
        --query 'KeyMetadata.KeyState' --output text 2>/dev/null)
    key_spec=$(aws kms describe-key --key-id "$key_id" \
        --query 'KeyMetadata.KeySpec' --output text 2>/dev/null)
    
    # Only process enabled, customer managed, symmetric keys
    if [[ "$key_manager" == "CUSTOMER" && "$key_state" == "Enabled" && "$key_spec" == "SYMMETRIC_DEFAULT" ]]; then
        rotation_status=$(aws kms get-key-rotation-status --key-id "$key_id" \
            --query 'KeyRotationEnabled' --output text 2>/dev/null)
        
        if [[ "$rotation_status" == "False" ]]; then
            echo "Enabling rotation for key: $key_id"
            aws kms enable-key-rotation --key-id "$key_id"
        else
            echo "Rotation already enabled for: $key_id"
        fi
    fi
done

echo "Key rotation check complete."
✓
Rotation Enabled: Your key now meets annual rotation requirements. AWS KMS will automatically rotate the key material without any action required from you.
4

Implement Monitoring and Compliance

~9 minutes

Continuous monitoring is essential for detecting unauthorized key access and maintaining compliance. Set up CloudWatch alarms, CloudTrail logging, and AWS Config rules to ensure your KMS configuration remains secure.

Console Steps

4.1 Verify CloudTrail Logging

  • Navigate to CloudTrail console
  • Verify you have a trail configured to log management events
  • Ensure the trail covers all regions
  • KMS API calls are automatically logged when CloudTrail is enabled

4.2 Create CloudWatch Alarms for KMS Events

Set up alarms to detect suspicious key activity:

AWS CLI - Create KMS Monitoring Alarms 
# First, create a CloudWatch Logs metric filter for key policy changes
aws logs put-metric-filter \
    --log-group-name "CloudTrail/DefaultLogGroup" \
    --filter-name "KMSKeyPolicyChanges" \
    --filter-pattern '{ ($.eventSource = kms.amazonaws.com) && (($.eventName = PutKeyPolicy) || ($.eventName = ScheduleKeyDeletion) || ($.eventName = DisableKey)) }' \
    --metric-transformations \
        metricName=KMSPolicyChanges,metricNamespace=Security/KMS,metricValue=1

# Create alarm for key policy changes
aws cloudwatch put-metric-alarm \
    --alarm-name "KMS-Key-Policy-Changes" \
    --alarm-description "Alert when KMS key policies are modified" \
    --metric-name KMSPolicyChanges \
    --namespace Security/KMS \
    --statistic Sum \
    --period 300 \
    --threshold 1 \
    --comparison-operator GreaterThanOrEqualToThreshold \
    --evaluation-periods 1 \
    --alarm-actions arn:aws:sns:us-east-1:ACCOUNT-ID:security-alerts

# Create alarm for failed decrypt operations (potential breach indicator)
aws logs put-metric-filter \
    --log-group-name "CloudTrail/DefaultLogGroup" \
    --filter-name "KMSDecryptFailures" \
    --filter-pattern '{ ($.eventSource = kms.amazonaws.com) && ($.eventName = Decrypt) && ($.errorCode = "*") }' \
    --metric-transformations \
        metricName=KMSDecryptFailures,metricNamespace=Security/KMS,metricValue=1

aws cloudwatch put-metric-alarm \
    --alarm-name "KMS-Decrypt-Failures" \
    --alarm-description "Alert on failed KMS decrypt operations" \
    --metric-name KMSDecryptFailures \
    --namespace Security/KMS \
    --statistic Sum \
    --period 300 \
    --threshold 5 \
    --comparison-operator GreaterThanThreshold \
    --evaluation-periods 1 \
    --alarm-actions arn:aws:sns:us-east-1:ACCOUNT-ID:security-alerts

4.3 Enable AWS Config Rules for KMS

  • Navigate to AWS Config console
  • Click "Rules" → "Add rule"
  • Add these managed rules:
    • cmk-backing-key-rotation-enabled: Checks rotation is enabled
    • kms-cmk-not-scheduled-for-deletion: Alerts on key deletion
AWS CLI - Enable AWS Config Rules 
# Enable key rotation check rule
aws configservice put-config-rule \
    --config-rule '{
        "ConfigRuleName": "cmk-backing-key-rotation-enabled",
        "Description": "Checks that key rotation is enabled for customer managed keys",
        "Source": {
            "Owner": "AWS",
            "SourceIdentifier": "CMK_BACKING_KEY_ROTATION_ENABLED"
        },
        "MaximumExecutionFrequency": "TwentyFour_Hours"
    }'

# Enable key deletion alert rule
aws configservice put-config-rule \
    --config-rule '{
        "ConfigRuleName": "kms-cmk-not-scheduled-for-deletion",
        "Description": "Checks that customer managed keys are not scheduled for deletion",
        "Source": {
            "Owner": "AWS",
            "SourceIdentifier": "KMS_CMK_NOT_SCHEDULED_FOR_DELETION"
        },
        "MaximumExecutionFrequency": "One_Hour"
    }'

4.4 Create KMS Compliance Dashboard

Set up a CloudWatch dashboard to monitor KMS health:

AWS CLI - Create KMS Dashboard 
aws cloudwatch put-dashboard \
    --dashboard-name "KMS-Security-Dashboard" \
    --dashboard-body '{
        "widgets": [
            {
                "type": "metric",
                "x": 0,
                "y": 0,
                "width": 12,
                "height": 6,
                "properties": {
                    "title": "KMS API Calls",
                    "metrics": [
                        ["AWS/KMS", "APICallsCount", {"stat": "Sum"}]
                    ],
                    "period": 300,
                    "region": "us-east-1"
                }
            },
            {
                "type": "metric",
                "x": 12,
                "y": 0,
                "width": 12,
                "height": 6,
                "properties": {
                    "title": "KMS Security Events",
                    "metrics": [
                        ["Security/KMS", "KMSPolicyChanges", {"stat": "Sum"}],
                        ["Security/KMS", "KMSDecryptFailures", {"stat": "Sum"}]
                    ],
                    "period": 300,
                    "region": "us-east-1"
                }
            }
        ]
    }'
✓
Monitoring Active: You now have comprehensive monitoring for KMS key activity, policy changes, and compliance status.

Validate Your KMS Configuration

Use this comprehensive checklist to verify your KMS setup meets security and compliance requirements:

Bash - KMS Compliance Validation Script 
#!/bin/bash
# KMS Compliance Validation Script

echo "========================================="
echo "KMS Security Configuration Validation"
echo "========================================="

# Check for customer managed keys
echo -e "\n[1] Checking for customer managed keys..."
cmk_count=$(aws kms list-keys --query 'Keys[].KeyId' --output text | wc -w)
echo "Found $cmk_count keys in account"

# Check rotation status for each key
echo -e "\n[2] Checking key rotation status..."
for key_id in $(aws kms list-keys --query 'Keys[].KeyId' --output text); do
    key_manager=$(aws kms describe-key --key-id "$key_id" \
        --query 'KeyMetadata.KeyManager' --output text 2>/dev/null)
    key_spec=$(aws kms describe-key --key-id "$key_id" \
        --query 'KeyMetadata.KeySpec' --output text 2>/dev/null)
    
    if [[ "$key_manager" == "CUSTOMER" && "$key_spec" == "SYMMETRIC_DEFAULT" ]]; then
        rotation=$(aws kms get-key-rotation-status --key-id "$key_id" \
            --query 'KeyRotationEnabled' --output text 2>/dev/null)
        if [[ "$rotation" == "True" ]]; then
            echo "✓ Key $key_id: Rotation ENABLED"
        else
            echo "✗ Key $key_id: Rotation DISABLED (requires attention)"
        fi
    fi
done

# Check CloudTrail logging
echo -e "\n[3] Checking CloudTrail configuration..."
trails=$(aws cloudtrail describe-trails --query 'trailList[?IsMultiRegionTrail==`true`].Name' --output text)
if [[ -n "$trails" ]]; then
    echo "✓ Multi-region CloudTrail trail found: $trails"
else
    echo "✗ No multi-region CloudTrail trail found"
fi

# Check AWS Config rules
echo -e "\n[4] Checking AWS Config rules..."
rotation_rule=$(aws configservice describe-config-rules \
    --config-rule-names cmk-backing-key-rotation-enabled 2>/dev/null \
    --query 'ConfigRules[0].ConfigRuleState' --output text)
if [[ "$rotation_rule" == "ACTIVE" ]]; then
    echo "✓ Key rotation Config rule is ACTIVE"
else
    echo "✗ Key rotation Config rule not found or inactive"
fi

echo -e "\n========================================="
echo "Validation Complete"
echo "========================================="

Common Mistakes to Avoid

✗

Using AWS managed keys for all workloads. AWS managed keys don't allow custom key policies, cross-account sharing, or compliance-specific configurations. Use customer managed keys for sensitive data.

✗

Granting KMS permissions only through IAM policies. Key policies are the primary access control mechanism. Always configure explicit key policies rather than relying solely on IAM.

✗

Sharing keys across environments. Production, staging, and development should use separate keys to maintain proper access isolation and audit trails.

✗

Not testing key access after policy changes. Always verify applications still function after modifying key policies. A misconfigured policy can break encryption/decryption operations.

✗

Ignoring key usage metrics. Monitor key usage patterns to detect anomalies. Sudden spikes in decrypt operations could indicate unauthorized access attempts.

Want Continuous KMS Security Monitoring?

Don't wait for compliance audits to discover KMS misconfigurations. AWSight provides continuous monitoring of your encryption key policies, rotation status, and usage patterns—alerting you before issues become compliance failures.

View Pricing Plans Browse All Tutorials

References