ExamFinch.com My Study

Study guide

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

Practice this exam

AWS Certified CloudOps Engineer – Associate SOA-C03

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Monitoring & Observability Infrastructure

1.1 Configuring Workload Observability 1.2 CloudWatch Agent Architecture & Deployment 1.3 Metric Alarms, Anomaly Detection & Composite Alarms

2 Chapter 2: Alarms, Dashboards & Event-Driven Remediation

2.1 CloudWatch Dashboards & Multi-Account Visibility 2.2 Notification Architecture & Alarm Invocation 2.3 Amazon EventBridge Rules, Event Buses & Troubleshooting 2.4 Automated Remediation with Systems Manager & Lambda

3 Chapter 3: Performance Optimization for Compute, Storage & Databases

3.1 EC2 & Compute Performance Optimization 3.2 Amazon EBS Performance Metrics & Volume Tuning 3.3 S3 Performance Strategies & Data Transfer 3.4 Shared Storage (EFS/FSx) & Database Performance

4 Chapter 4: Compute & Database Scalability and Elasticity

4.1 EC2 Auto Scaling Policies & Elasticity 4.2 Auto Scaling Advanced Operations: Warm Pools & Lifecycle Hooks 4.3 Dynamic Scalability Through Caching 4.4 Managed Database Scaling: RDS, Aurora & DynamoDB

5 Chapter 5: High Availability, Fault Tolerance & Load Balancing

5.1 Elastic Load Balancing (ALB/NLB) Configuration & Troubleshooting 5.2 Route 53 Health Checks & DNS Failover 5.3 Multi-AZ Architecture & Fault-Tolerant Deployments

6 Chapter 6: Backup, Data Protection & Disaster Recovery

6.1 Centralized Backup Automation & AWS Backup 6.2 Database Restore Strategies & RTO/RPO Management 6.3 Storage Versioning, Replication & Immutability 6.4 Disaster Recovery Patterns & Multi-Region Resilience

7 Chapter 7: Infrastructure as Code with CloudFormation & AWS CDK

7.1 CloudFormation Foundations & Resource Modeling 7.2 Managing Stacks, Drift Detection & Change Sets 7.3 Infrastructure as Code with AWS CDK 7.4 Identifying & Remediating Deployment Failures

8 Chapter 8: Multi-Account Provisioning, Containers & Third-Party IaC

8.1 Golden Images with EC2 Image Builder & Amazon ECR 8.2 Multi-Account & Multi-Region Resource Sharing 8.3 Deployment Strategies & Container Deployments 8.4 Third-Party Automation with Terraform & Git Workflows

9 Chapter 9: Systems Manager & Event-Driven Operations Automation

9.1 AWS Systems Manager Core Management & Run Command 9.2 Systems Manager Patch Manager & Session Manager 9.3 Event-Driven Operations Automation

10 Chapter 10: Identity, Access Management & Governance

10.1 Advanced IAM Policies, Roles & Policy Conditions 10.2 Auditing Access with CloudTrail Lake & IAM Access Analyzer 10.3 Multi-Account Security: Organizations, SCPs & Identity Center 10.4 Compliance Enforcement with AWS Config & Conformance Packs

11 Chapter 11: Data Security, Encryption & Vulnerability Management

11.1 Data Classification & Amazon S3 Security 11.2 Encryption at Rest with AWS Key Management Service (KMS) 11.3 Encryption in Transit with AWS Certificate Manager (ACM) 11.4 Secrets Management & Centralized Security Findings

12 Chapter 12: VPC Architecture, Endpoints & Network Protection

12.1 VPC Core Architecture, Subnetting & High Availability NAT 12.2 Private Network Connectivity: VPC Endpoints & Peering 12.3 Network Protection & Edge Security Auditing

13 Chapter 13: DNS, Route 53 Routing & Content Delivery

13.1 DNS Architecture & Route 53 Resolver for Hybrid Clouds 13.2 Route 53 Advanced Routing Policies & Query Logging 13.3 Global Content & Service Distribution: CloudFront & Global Accelerator

14 Chapter 14: Network Troubleshooting, Traffic Analysis & Hybrid Connectivity

14.1 VPC Configuration Troubleshooting & Analysis Tools 14.2 Network Traffic Analysis: VPC Flow Logs & Log Analytics 14.3 CloudFront Caching & Hybrid Connectivity Troubleshooting

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

Key Takeaways Explain This Topic AI

AWS KMS integrates Hardware Security Modules (HSMs) to protect root key material, enforcing envelope encryption where KMS generates plaintext and encrypted data keys while never encrypting data payloads greater than 4 KB directly.

AWS KMS distinguishes between AWS Owned Keys (internal, free), AWS Managed Keys (aws/service, free maintenance, default policy), and Customer Managed Keys (CMKs, full policy control, annual/on-demand rotation, deletion scheduling).

Key policies serve as the primary authorization layer for KMS keys requiring explicit delegation to IAM, while cross-account key access mandates dual authorization across both the owning account's key policy and the external account's IAM policy.

Multi-Region KMS keys replicate identical key material and key IDs across AWS Regions, allowing local decryption of replicated data (such as Aurora Global Databases and S3 CRR) without cross-Region API calls.

Account-level default EBS encryption ensures that all newly created EBS volumes and snapshots in an AWS Region are automatically encrypted using a designated KMS key.

Last updated: September 2026

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:

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.

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.

Feature / Dimension AWS Owned Keys AWS Managed Keys Customer Managed Keys (CMK)

Naming Convention Internal / Hidden aws/<service-name> (e.g., aws/s3 , aws/ebs ) Custom alias (e.g., alias/prod-database-key )

Account Visibility Not visible in customer account Visible in KMS console under "AWS Managed Keys" Visible in KMS console under "Customer Managed Keys"

Monthly Maintenance Fee Free Free ($0.00 / month) $1.00 per key / month

Key Policy Modification Cannot view or modify View only; cannot modify policy Full control over key policies and grants

Automatic Key Rotation Managed internally by AWS Rotated automatically every 1 or 3 years Optional annual rotation or on-demand rotation

Cross-Account Sharing Impossible Strictly prohibited (cannot be shared) Fully supported via cross-account key policies

  • Key Deletion Managed by AWS Cannot be deleted by customer Scheduled deletion with 7 to 30-day buffer
  • 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 :

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* ).

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.