AWS Certified Solutions Architect - Associate (SAA-C03) #3 Domain 1-2 Secure Architectures — KMS and Encryption

In #2 IAM in Depth we nailed down “who accesses what.” This time we go one step deeper, into encryption that keeps the data itself unreadable even if access is breached. On SAA, encryption questions mostly come along two axes: “how do you safely store/transmit this data?” and “who controls the key?” KMS sits at the center of that.

What is KMS #

AWS Key Management Service (KMS) is a managed service for creating and managing encryption keys. There are two important premises.

• KMS is a regional service. A key never leaves the region it was created in (multi-region keys are the exception).
• KMS directly encrypts up to 4 KB at a time. That’s why actual data is handled with envelope encryption (explained below).

Key types #

The deciding point on the exam is “do you need to audit or control key usage?” If you need to control the key policy directly and keep usage records via CloudTrail, the answer is a customer managed key (CMK). If you just need “as long as it’s encrypted,” an AWS managed key is enough.

Symmetric keys vs. asymmetric keys #

KMS keys are symmetric (256-bit AES) by default. The same key encrypts and decrypts, and the key material never leaves KMS. Asymmetric keys (RSA/ECC) encrypt with a public key and decrypt with a private key, or are used for signing/verification. Most storage encryption uses symmetric keys; asymmetric is only for when you need to exchange a public key with the outside world.

Envelope Encryption #

KMS only directly encrypts up to 4 KB, so how does it encrypt files tens of gigabytes large? The answer is envelope encryption.

1. Request data key generation from KMS (GenerateDataKey).
2. KMS returns two things — a plaintext data key and an encrypted data key.
3. Encrypt the actual data with the plaintext data key, then discard the plaintext key from memory.
4. Store the encrypted data together with the encrypted data key.
5. To decrypt, send the encrypted data key to KMS, receive the plaintext key, and decrypt the data with it.

The key idea is that the KMS key (KEK) only encrypts the data key (DEK), and the actual data is encrypted by the data key. This way even large data is handled with a single KMS call, and the KMS master key never leaves KMS. S3 SSE-KMS, EBS, and RDS encryption all use this approach internally.

at rest vs. in transit #

When the exam gives a requirement to “protect data both at rest and in transit,” compose the answer along two axes: KMS-based encryption for storage, TLS for transit.

S3 encryption options #

S3 storage encryption is divided by who holds the key.

If you need to “track who decrypted an object,” SSE-KMS; if there’s a regulation that “the key itself must not be on AWS,” SSE-C or client-side encryption is the direction.

EBS and RDS — encrypting resources that already exist #

A classic SAA trap lives here. Encryption for EBS volumes and RDS instances can only be enabled at creation time and can’t be toggled later. To encrypt an existing unencrypted resource, you need a workaround path.

• EBS — unencrypted volume → create a snapshot → copy the snapshot with encryption → create a new volume from that snapshot. EBS encryption also protects the volume, the snapshots, and the transfer between the instance and the volume.
• RDS — unencrypted instance → create a snapshot → copy the snapshot with encryption → restore to a new instance from that snapshot. There’s no option to encrypt the existing instance directly.

Key policies and cross-account sharing #

A KMS key always has a resource-based policy called the Key Policy attached. Key access is decided by the following combination.

• Key policy — the policy attached directly to the key. The default key policy gives the root account full permissions.
• IAM policy — effective only if the key policy allows delegation to IAM.
• Grant — temporary, fine-grained permission delegation.

To let another account use the key, allow that account’s Principal in the key policy, and on the other account, allow key usage via an IAM policy. For cross-account encrypted data (e.g., encrypted S3 shared with another account, encrypted snapshots), access is blocked if this key policy setting is missing.

KMS vs. CloudHSM #

If there’s a cue like “we must control the key material ourselves” or “a dedicated hardware security module is a regulatory requirement,” the answer is CloudHSM. For most everything else, KMS is enough.

Exam question patterns #

• “Encrypt stored data but audit who decrypted it.” → SSE-KMS (customer managed key)
• “There’s a regulation that the key must not be entrusted to AWS.” → SSE-C / client-side / CloudHSM
• “How do you encrypt an already-running unencrypted RDS?” → snapshot → encrypted copy → restore
• “How do you encrypt an unencrypted EBS volume?” → snapshot → encrypted copy → new volume
• “What’s the principle behind encrypting a tens-of-GB object with KMS?” → envelope encryption (data key)
• “Another account can’t restore our encrypted snapshot.” → the account isn’t allowed in the key policy

Common traps #

1) Thinking KMS directly encrypts all the data #

KMS only directly handles up to 4 KB. Large data is handled by the data key via envelope encryption.

2) Misunderstanding that EBS/RDS encryption can be turned on later #

It’s only possible at creation time. Existing resources go through the snapshot → encrypted copy path.

3) Thinking you can turn off rotation for an AWS managed key #

An AWS managed key rotates automatically on a 1-year cycle and can’t be turned off. To control the rotation cycle, use a customer managed key.

4) Touching only the IAM policy for cross-account #

Cross-account KMS access requires the key policy allowance first. If the other account isn’t in the key policy, it’s blocked no matter how much you allow in IAM.

Wrap-up #

What this post locked in:

• KMS is a regional service, and direct encryption goes up to 4 KB. Large data uses envelope encryption
• Key types — AWS managed (no control, free) vs. customer managed (controllable and auditable, $1/month)
• S3 — SSE-S3 / SSE-KMS (audit) / SSE-C / client-side. Choose based on the key-control requirement
• EBS and RDS are encrypted only at creation. Existing resources go through snapshot → encrypted copy
• Cross-account — key policy allowance comes first, then IAM
• CloudHSM — when regulation requires full, sole control of keys via dedicated hardware

Next — Domain 1-3 VPC Security #

With data encryption in hand, next comes security at the network boundary.

#4 Domain 1-3 VPC Security covers the difference between security groups and network ACLs (stateful vs. stateless), the two kinds of VPC Endpoint (Gateway , Interface), how to expose a service privately with PrivateLink, and VPC Flow Logs and bastion hosts.