11.2 Encryption at Rest with AWS Key Management Service (KMS)

11.2 Encryption at Rest with AWS Key Management Service (KMS)

CloudOps Blueprint Focus: The AWS Certified CloudOps Engineer – Associate (SOA-C03) exam tests your mastery of AWS Key Management Service (KMS). You must understand envelope encryption mechanics, differentiate between AWS Managed and Customer Managed keys, configure key policies for cross-account delegation, architect multi-Region encryption for disaster recovery, and enforce account-level default EBS volume encryption.

AWS KMS Cryptographic Foundations & Envelope Encryption

AWS Key Management Service (KMS) provides centralized, hardware-backed control over cryptographic keys used to encrypt data across AWS services and custom applications. KMS hardware security modules (HSMs) are validated under FIPS 140-2 Level 3 (and transitioning to FIPS 140-3), ensuring that plaintext key material never leaves the KMS boundary unencrypted.

Symmetric vs. Asymmetric KMS Keys

KMS supports two primary cryptographic key architectures:

• Symmetric Encryption Keys (Default): Uses a single 256-bit Advanced Encryption Standard key in Galois/Counter Mode (AES-256-GCM). The same key performs both encryption and decryption. Symmetric keys represent over 99% of AWS cloud operations and integrate natively with more than 100 AWS services (S3, EBS, RDS, DynamoDB, Secrets Manager).
• Asymmetric Keys: Contains an RSA (2048, 3072, or 4096-bit) or Elliptic Curve (ECC) public/private key pair. Used for digital signature verification, code signing, or encrypting payloads outside AWS where external parties hold the public key but cannot access KMS APIs directly.

Envelope Encryption Mechanics

A critical architectural limitation of AWS KMS is that the kms:Encrypt API accepts a maximum payload size of 4,096 bytes (4 KB). KMS is not designed to stream raw gigabytes of application data through its API. Instead, AWS implements Envelope Encryption:

+-----------------------------------------------------------------------------------+
|                         Envelope Encryption Workflow                              |
|                                                                                   |
|  1. Service calls kms:GenerateDataKey(KeyId='arn:aws:kms:...')                   |
|  2. KMS returns: [Plaintext Data Key (256-bit)] + [Encrypted Data Key (Ciphertext)]|
|  3. Service encrypts 50 GB Data with Plaintext Data Key using AES-256 locally     |
|  4. Service ERASES Plaintext Data Key from RAM immediately                       |
|  5. Service stores Encrypted Data Key ALONGSIDE the Ciphertext (Header/Metadata) |
|                                                                                   |
|  Decryption:                                                                      |
|  1. Service extracts Encrypted Data Key and calls kms:Decrypt(CiphertextKey)     |
|  2. KMS decrypts key using CMK and returns Plaintext Data Key to service RAM      |
|  3. Service decrypts 50 GB Data locally and wipes Plaintext Data Key from RAM     |
+-----------------------------------------------------------------------------------+

Envelope encryption provides two immense operational advantages:

1. Performance & Scalability: Massive datasets (such as multi-terabyte S3 objects or EBS volumes) are encrypted and decrypted locally at line rate using optimized CPU instructions (AES-NI), bypassing network transfer bottlenecks.
2. Network Resilience & Quota Protection: Only small 256-bit data keys traverse the network to KMS, avoiding KMS API throttling limits and reducing operational latency.

---

AWS KMS Key Hierarchy: Owned, Managed & Customer Managed Keys

Understanding the operational capabilities, pricing, and administrative boundaries of KMS key tiers is essential for the CloudOps exam.

Key Deletion Safety Buffer

Customer Managed Keys cannot be deleted immediately. When an administrator invokes kms:ScheduleKeyDeletion, KMS enforces a mandatory waiting period between 7 and 30 days (default: 30 days). During this pending deletion window, the key state changes to PendingDeletion, and all cryptographic operations fail. If an application breaks, operators can cancel deletion (kms:CancelKeyDeletion) before permanent, irrecoverable data loss occurs.

---

KMS Key Policies & Cross-Account Delegation

In AWS IAM, resource-based policies are usually optional. For AWS KMS, Key Policies are mandatory. Even an IAM user with full administrative privileges (AdministratorAccess with *.*) cannot access a KMS key unless the key policy explicitly authorizes them.

The Root Delegation Principle

For IAM policies in an account to take effect on a KMS key, the key policy must delegate access to the AWS account root principal:

{
  "Sid": "EnableIAMUserPermissions",
  "Effect": "Allow",
  "Principal": {
    "AWS": "arn:aws:iam::111122223333:root"
  },
  "Action": "kms:*",
  "Resource": "*"
}

This statement does not grant root access to arbitrary users; rather, it delegates authorization authority to the account's IAM engine, enabling IAM policies within Account 111122223333 to grant permissions to specific roles or users.

Segregation of Duties: Administrators vs. Users

Enterprise security requires separating key lifecycle management from cryptographic usage:

• Key Administrators: Granted permissions for administrative actions (kms:Create*, kms:Describe*, kms:Enable*, kms:Put*, kms:Update*, kms:Revoke*, kms:Disable*, kms:Get*, kms:Delete*, kms:ScheduleKeyDeletion, kms:CancelKeyDeletion). Administrators cannot decrypt application data.
• Key Users: Granted cryptographic operations only (kms:Encrypt, kms:Decrypt, kms:ReEncrypt*, kms:GenerateDataKey*, kms:DescribeKey). Key users cannot delete keys, alter policies, or change rotation settings.

Cross-Account KMS Access Handshake

Sharing an encrypted resource (such as an S3 bucket or EBS snapshot) between Account A (owning the key) and Account B (consuming the data) requires a two-sided handshake:

1. Account A Key Policy: Must explicitly add Account B's root ARN or specific IAM role ARN to the Principal element for cryptographic actions (kms:Decrypt, kms:GenerateDataKey*).
2. Account B IAM Policy: Must attach an IAM policy to the target role granting kms:Decrypt and kms:GenerateDataKey* referencing Account A's KMS key ARN.

If either side of this handshake is omitted, access is denied.

---

Multi-Region KMS Keys for Global Architectures & DR

Historically, KMS keys were strictly regional constructs. A key created in us-east-1 could never leave or decrypt data in eu-west-1. To support disaster recovery (DR) and global applications, AWS introduced Multi-Region KMS Keys.

Architectural Mechanics

• An administrator creates a Primary Key in one Region (e.g., us-east-1) and marks it as multi-Region.
• The administrator replicates the key to one or more secondary Regions (e.g., eu-west-1).
• Identical Key Material & ID: The replica key shares the exact same key ID, key material, and key ARN prefix (differing only in the Region identifier: arn:aws:kms:us-east-1:111122223333:key/mrk-... vs arn:aws:kms:eu-west-1:111122223333:key/mrk-...).

Operational Advantages in Disaster Recovery

In a disaster recovery scenario involving Amazon Aurora Global Databases or S3 Cross-Region Replication:

• Data encrypted under the primary key in us-east-1 can be decrypted locally in eu-west-1 by the replica key.
• Secondary database read replicas execute decryption calls against their local regional KMS endpoint.
• This completely eliminates cross-Region network latency, avoids cross-Region API call charges, and ensures that secondary Region operations continue uninterrupted even if the primary Region experiences a total control-plane outage.

---

Regional Default EBS Volume Encryption

Unencrypted block storage represents a critical compliance violation. Rather than auditing EC2 instance launch scripts or CloudFormation templates individually, CloudOps engineers enable Default EBS Encryption at the account level for each AWS Region:

aws ec2 enable-ebs-encryption-by-default --region us-east-1

Once enabled:

• Every newly created EBS volume and snapshot in that Region is automatically encrypted upon creation.
• If a user or launch template specifies no encryption, EC2 automatically encrypts the volume using the default KMS key.
• Administrators can configure the default key to be the AWS-managed key (aws/ebs) or designate a custom Customer Managed Key (CMK) across the account.