KMS, Multi-Region Keys, Envelope Encryption, and Certificates

Why cryptography design shows up on SAP-C02

Task 1.2 on the AWS Certified Solutions Architect - Professional (SAP-C02) exam is not a checkbox that says turn encryption on. Independent OpenExamPrep teaching for this task is about who owns the key, which policy actually authorizes Decrypt, whether ciphertext is portable across Regions, and when a convenience key is the wrong control for a Payment Card Industry (PCI) or similarly regulated workload. A professional architect treats AWS Key Management Service (AWS KMS) as the default control plane, then justifies AWS CloudHSM, AWS Certificate Manager (ACM), and envelope encryption around it.

Harborline Payments runs a cardholder-data environment in us-east-1 with a disaster-recovery (DR) Region in us-west-2. Assessors want evidence of key custody, rotation, and which principal decrypted objects. That story drives every subsection below. This chapter does not claim OpenExamPrep partnership with AWS or PCI SSC; it teaches how architects use AWS-published controls to meet those evidence needs.

Three KMS key classes

AWS KMS documentation distinguishes customer managed keys, AWS managed keys, and AWS owned keys. Do not treat CMK as a fourth product. Current AWS docs use customer managed key for keys you create. Older stems still say CMK; map that phrase to customer managed.

Exam traps. AWS owned keys are not in your account, are not something you attach a customer key policy to, and are not a source of customer-visible KMS API history. AWS managed keys (historical aliases such as aws/ebs, aws/rds, aws/s3) are viewable in your account, rotate on an AWS-managed annual schedule, and are always single-Region. AWS documents AWS managed keys as a legacy type that new services have not been creating since 2021; default encryption-by-convenience is often an AWS owned key. Customer managed keys are the class that gives exclusive control of the key policy, grants, aliases, enable/disable, deletion schedule, and Regional placement. AWS documents a monthly existence charge plus usage charges above the free tier. This guide does not invent dollar amounts—confirm current figures on the AWS KMS pricing page when a cost stem appears.

Harborline encrypts Amazon S3 objects that store tokenized authorizations and Amazon RDS storage that holds settlement batches with customer managed keys, not AWS owned keys, because the assessor asked who can call Decrypt and whether that call is in CloudTrail.

Key policies versus IAM versus grants

Every KMS key must have exactly one key policy. No principal—including the account root user—has cryptographic permission unless a key policy, IAM policy, or grant allows it and nothing denies it.

IAM Allow is inert unless the key policy enables IAM. The default key policy's first statement names the account principal (arn:aws:iam::account-id:root) with kms:*. That statement does not give every IAM user kms:Decrypt. It lets account administrators attach IAM policies that then allow KMS actions. If you delete that enable-IAM statement and never name principals in the key policy, those IAM allows silently fail. IAM Deny still works even without key-policy permission.

Key policies are Regional. A us-east-1 key policy does not authorize a us-west-2 replica. Multi-Region key policies are independent properties and are not synchronized.

Grants are the third authorization path. Integrated services such as Amazon EBS, Amazon RDS, and Amazon S3 use grants so a service-linked principal can call GenerateDataKey or Decrypt without stuffing long-lived IAM users into the key policy. Grants are Regional and apply to one key. You cannot write one grant that covers a multi-Region primary and all replicas. Typical permissions include kms:CreateGrant and kms:RetireGrant, plus a retiring principal that can clean the grant up.

Use the kms:ViaService condition in the key policy or IAM so Harborline's application role can use the key only when the request comes from s3.us-east-1.amazonaws.com or rds.us-east-1.amazonaws.com. That is the PCI-friendly pattern: the same IAM role cannot call kms:Decrypt from a compromised bastion with a raw AWS CLI.

Envelope encryption

KMS symmetric keys are designed to wrap data keys, not to encrypt terabyte objects byte-by-byte through the KMS Encrypt API. Envelope encryption means:

1. The application or AWS service calls GenerateDataKey (or GenerateDataKeyWithoutPlaintext).
2. KMS returns a plaintext data key and a copy of that data key encrypted under the KMS key.
3. The service encrypts the object, volume, or database page with the data key (typically AES-256), then discards the plaintext data key.
4. Ciphertext is stored next to the encrypted data key.
5. Decrypt is the reverse: Decrypt on the encrypted data key, then local AES decrypt.

S3 SSE-KMS, EBS encryption, and RDS encryption all use this model inside the service. Diagrams should show two keys: the KMS key (key material stays in HSM-backed KMS) and the data key (lives with the object).

S3 Bucket Keys reduce KMS API volume by using a bucket-level envelope key. They do not change the customer-managed-versus-AWS-managed decision.

Multi-Region keys versus replicated ciphertext

Multi-Region keys share key material and a key ID in the mrk- form across a primary and replica keys you create with ReplicateKey. They are not global. AWS never auto-replicates them into extra Regions. Each replica is a full KMS key with its own ARN, key policy, grants, aliases, tags, and enabled state. You can use a replica even if the primary is disabled. AWS managed keys cannot be multi-Region.

The point of multi-Region keys is ciphertext portability: an S3 object or RDS snapshot encrypted under the primary can be decrypted in the replica Region without re-encrypting, because the replica holds the same material. Replicating SSE-KMS objects that used a single-Region customer managed key to another Region produces ciphertext that cannot be decrypted there until you re-encrypt under a key that exists in the destination, or until you use a related multi-Region replica.

Do not confuse four different designs:

• Cross-Region snapshot copy of an encrypted RDS instance, which requires a KMS key in the destination Region (often a replica of a multi-Region key, or a different customer managed key if you accept re-encryption).
• Copying a key ARN string into another Region. ARNs are Regional; that configuration simply fails.
• AWS managed keys as a DR strategy. They are always single-Region.
• Custom key stores. AWS documents that you cannot create multi-Region keys in a CloudHSM or external custom key store. You also cannot combine custom key stores with imported key material, asymmetric keys, HMAC keys, or automatic rotation.

Harborline's DR runbook: create a multi-Region primary in us-east-1, replicate to us-west-2, point both buckets and both RDS encryption settings at the related keys, and still write separate key policies so DR roles can Decrypt only after failover automation enables them. Each related key counts as one KMS key toward that Region's quotas and pricing; do not invent a shared global quota.

CloudHSM and custom key stores

Choose AWS CloudHSM when a control or assessor requires customer-owned, single-tenant HSMs you can inventory and manage, not because CloudHSM is more secure than KMS. AWS key-store documentation states custom key stores are not more secure than the standard KMS store; they have different management and cost implications. Cryptographic operations for KMS keys in a CloudHSM key store run on your cluster.

If the stem demands FIPS-validated KMS HSMs with full service integration and you do not need to own the HSM, stay on the standard KMS key store. If the stem demands key material that never exists in AWS, that is an external key store (XKS) conversation, not CloudHSM. Harborline uses CloudHSM only for the PAN tokenization service whose assessor insisted on a customer-inventoried HSM cluster; S3 and RDS stay on standard-store customer managed keys.

ACM public certificates versus AWS Private CA

ACM provisions TLS X.509 certificates for integrated services. Certificates in ACM are Regional. An Application Load Balancer (ALB) in eu-west-1 needs a certificate in eu-west-1. Amazon CloudFront custom viewer certificates are requested in us-east-1. You cannot copy a certificate between Regions; you request or import again and revalidate public names.

Public ACM certificates are publicly trusted and fit internet-facing ALB, CloudFront, and API Gateway. You validate domain control (DNS validation is the usual production choice). AWS documents that public certificates created before 17 June 2025 cannot be exported. Newer public certificates can be requested with export enabled if you must install the same public cert outside ACM-integrated services. Do not assume every public ACM cert is exportable.

AWS Private Certificate Authority (AWS Private CA) issues private certificates for internal PKI, mutual TLS between services, and private ALBs. Private certificates issued through ACM can be exported (certificate, chain, encrypted private key) for EC2, on-premises load balancers, or containers. CloudFront viewer certificates must be publicly trusted; a Private CA cert is the wrong tool for the public CloudFront viewer handshake. Imported third-party certificates are also Regional, and you own renewal.

S3, EBS, and RDS encryption patterns

Amazon S3 buckets encrypt new objects by default with SSE-S3 (Amazon S3 managed keys, AES-256). Choose SSE-KMS when you need a customer managed or AWS managed KMS key, key-policy isolation, and CloudTrail on Decrypt/GenerateDataKey. DSSE-KMS applies two independent AES-256 layers for frameworks that demand dual-layer encryption. SSE-C uses a customer-provided key on every request—impractical to share with most AWS analytics services.

Amazon EBS encryption uses KMS and encrypts at rest and in transit between the instance and the volume on the host. You can enable encryption by default per Region. Snapshots of encrypted volumes are encrypted. You encrypt an unencrypted volume through an encrypted copy or snapshot path; you do not unencrypt in place.

Amazon RDS encrypts storage with a KMS key chosen at create. You cannot turn encryption off later. You can export data to an unencrypted instance if a bad design must be unwound. Cross-Region copy uses envelope encryption and needs a destination-Region KMS key.

Harborline's production pattern: customer managed keys in the standard KMS store for S3 SSE-KMS and RDS; EBS encryption by default; ACM public certificates on the ALB; Private CA only for internal mTLS; multi-Region keys for the DR pair; CloudHSM only where the assessor insisted on customer-owned HSMs for PAN tokenization.

Traps to lock. Treating AWS owned keys as auditable PCI keys. Assuming AWS managed keys replicate. Sharing one grant across multi-Region replicas. Putting a CloudFront viewer cert in eu-west-1 only. Using Private CA for the public CloudFront handshake. Calling KMS Encrypt on multi-gigabyte files instead of envelope encryption. Creating multi-Region keys in a CloudHSM custom key store.