← Design Secure Architectures

▶ Play from here · 236 min

Starts this lesson and continues through 21 more to the end of certification prep.

Encryption and key management

Why this lesson matters

Task statement 1.3 — "Determine appropriate data security controls" — lists skills in "Encrypting data at rest (for example, AWS Key Management Service [AWS KMS])", "Encrypting data in transit (for example, AWS Certificate Manager [ACM] using TLS)", "Implementing access policies for encryption keys", and "Rotating encryption keys and renewing certificates".

Notice what those four have in common. None of them is "turn on encryption". Encryption at rest is mostly a checkbox now — S3 does it whether you ask or not. What the exam tests is who holds the key, who can be stopped from using it, and what happens when it rotates. That is a permissions question wearing a cryptography costume, which is why it belongs in Domain 1 and not Domain 3.

Three key types, and the cost/control trade

Verbatim definitions from AWS KMS keys (verified 2026-09-21):

Customer managed keys — "The KMS keys that you create are customer managed keys. Customer managed keys are KMS keys in your AWS account that you create, own, and manage. You have full control over these KMS keys, including establishing and maintaining their key policies, IAM policies, and grants, enabling and disabling them, rotating their cryptographic material, adding tags, creating aliases … and scheduling the KMS keys for deletion."

AWS managed keys — "AWS managed keys are KMS keys in your account that are created, managed, and used on your behalf by an AWS service integrated with AWS KMS." Alias format aws/{service-name}, e.g. aws/redshift, aws/ebs, alias/aws/s3.

AWS owned keys — "AWS owned keys are a collection of KMS keys that an AWS service owns and manages for use in multiple AWS accounts. Although AWS owned keys are not in your AWS account, an AWS service can use an AWS owned key to protect the resources in your account."

The comparison table AWS publishes, which is the one to know:

Three consequences the exam leans on:

⚠️ AWS managed keys cannot be shared cross-account. "You cannot share resources encrypted under an AWS managed key with other accounts." So the moment a requirement says "share the encrypted snapshot / AMI / bucket with another account", the answer needs a customer managed key. This is probably the single highest-yield KMS fact on the exam.

⚠️ AWS owned keys give you no audit trail. "you are not charged for their existence or their usage, you cannot change their policies, you cannot audit activities on these keys, and you cannot delete them." If a requirement mentions auditing key usage or meeting a compliance obligation to show who decrypted what, AWS owned keys are out.

AWS managed keys are a legacy type. "AWS managed keys are a legacy key type that is no longer being created for new AWS services as of 2021. Instead, new (and legacy) AWS services are using what's known as an AWS owned key to encrypt customer data by default."

AWS's own one-line decision rule: "Use customer managed keys when control is important, but use AWS owned keys when convenience is most important."

Why a key policy is not optional

This is the KMS fact that trips up people who are fluent in IAM, and it is worth quoting at length. From Key policies in AWS KMS, verified 2026-09-21:

"A key policy is a resource policy for an AWS KMS key. Key policies are the primary way to control access to KMS keys. Every KMS key must have exactly one key policy. … You can also use IAM policies and grants to control access to the KMS key, but every KMS key must have a key policy."

"No AWS principal, including the account root user or key creator, has any permissions to a KMS key unless they are explicitly allowed, and never denied, in a key policy, IAM policy, or grant."

"Unless the key policy explicitly allows it, you cannot use IAM policies to allow access to a KMS key. Without permission from the key policy, IAM policies that allow permissions have no effect. (You can use an IAM policy to deny a permission to a KMS key without permission from a key policy.) The default key policy enables IAM policies."

Read that third quote twice. It inverts lesson 1's union rule for this one service. Everywhere else in AWS, an identity policy alone can grant access to a resource. With KMS, the key policy must open the door before an IAM policy can walk through it. The default key policy contains the statement that enables IAM policies — which is why most people never notice — but if someone writes a restrictive key policy without it, every IAM administrator in the account loses access to that key.

That is how accounts lock themselves out of their own keys. It is not recoverable by an account admin, because the root user has no inherent permission either.

⚠️ Key policies are Regional. "Unlike IAM policies, which are global, key policies are Regional. A key policy controls access only to a KMS key in the same Region. It has no effect on KMS keys in other Regions." A cross-Region DR design needs keys — and key policies — in both Regions, or a multi-Region key.

Grants are the third mechanism, alongside key policies and IAM policies. The exam-relevant shape: grants are how AWS services get temporary, scoped permission to use a key on your behalf.

The key hierarchy, and what "envelope encryption" means

From the same concepts page, verbatim, because the wording matters:

"The HBK is generated on an HSM in the domain and is designed never to be exported from the HSM in plaintext."

The four-level hierarchy AWS documents:

The mechanic of envelope encryption, in AWS's words: "You can make requests through AWS KMS to use your KMS keys to directly protect information or request additional HSM-generated keys that are protected under your KMS key. These keys are called customer data keys, or CDKs. CDKs can be returned encrypted as ciphertext (CT), in plaintext, or both."

And the containment property that answers "is my data key safe": "All objects encrypted under a KMS key (either customer-supplied data or HSM-generated keys) can be decrypted only on an HSM via a call through AWS KMS." Plus: "The returned ciphertext, or the decrypted payload, is never stored within AWS KMS."

So the pattern you should be able to describe in an interview or an exam answer: you ask KMS for a data key, you get it twice — plaintext and encrypted — you encrypt your data locally with the plaintext copy, you throw the plaintext away, and you store the encrypted copy next to the ciphertext. To read the data you send the encrypted key back to KMS. That's why you can encrypt a terabyte with a service whose direct Encrypt call handles only small payloads.

Rotation — what actually changes

From Rotate AWS KMS keys, verified 2026-09-21. This is the section where intuition is usually wrong.

What rotation changes, and what it doesn't:

"Key rotation changes only the current key material, which is the cryptographic secret that is used in encryption operations. When you use the rotated KMS key to decrypt ciphertext, AWS KMS uses the key material that was used to encrypt it. You cannot select a particular key material for decrypt operations, AWS KMS automatically chooses the correct key material."

"The KMS key is the same logical resource, regardless of whether or how many times its key material changes. The properties of the KMS key do not change."

So the key ID, the key ARN and the alias all stay the same. Rotation is invisible to your applications: "you can safely use a rotated KMS key in applications and AWS services without code changes."

⚠️ Rotation does not re-encrypt anything. AWS puts this in a note: *"Key rotation has no effect on the data that the KMS key protects. It does not rotate the data keys that the KMS key generated or re-encrypt any data protected by the KMS key. Key rotation will not mitigate the effect of a compromised data key."*

That last sentence is the exam trap. "We rotated the key, so the leaked data is safe" is false. If the requirement is that old ciphertext must become unreadable, rotation is the wrong control — you need to re-encrypt the data (S3 Batch Operations, for example) or destroy the key.

The three rotation modes and their eligibility:

The rotation period: "If you do not specify a value for RotationPeriodInDays when you enable automatic key rotation, the default value is 365 days." And the worked example: a key created 1 January 2022 with rotation enabled 15 March 2022 rotates on 15 March 2023, 15 March 2024, and every 365 days after — "the rotation date depends on the date that rotation was most recently enabled", not the creation date.

AWS managed keys: "AWS KMS automatically rotates AWS managed keys every year (approximately 365 days). You cannot enable or disable key rotation for AWS managed keys." (Changed from ~1,095 days in May 2022, per the doc's own note.)

Old key material is kept: "AWS KMS retains all key material for a KMS key with AWS_KMS origin, even if key rotation is disabled. AWS KMS deletes key material only when you delete the KMS key." Which is why decrypting old ciphertext keeps working, and why deleting a key is the destructive act, not rotating it.

Cost: "AWS KMS charges a monthly fee for first and second rotation of key material maintained for your KMS key. This price increase is capped at the second rotation, and any subsequent rotations will not be billed." And "Each KMS key counts as one key when calculating key resource quotas, regardless of the number of rotated key material versions."

Monitoring: rotation writes a KMS CMK Rotation event to EventBridge and a RotateKey event to CloudTrail; GetKeyRotationStatus tells you whether automatic rotation is on, and ListKeyRotations lists completed rotations. That's the evidence you hand an auditor.

Multi-Region keys: key rotation is "a shared property". You enable automatic rotation, and initiate on-demand rotation, only on the primary key. AWS then "creates new key material for the primary key and then copies the new key material across Region boundaries to all related replica keys. The key material never leaves AWS KMS unencrypted." And no data is encrypted with the new material until it exists in every replica.

S3 encryption at rest — the four options

From Protecting data with encryption, verified 2026-09-21. The headline, verbatim:

"Amazon S3 now applies server-side encryption with Amazon S3 managed keys (SSE-S3) as the base level of encryption for every bucket in Amazon S3. Starting January 5, 2023, all new object uploads to Amazon S3 are automatically encrypted at no additional cost and with no impact on performance."

"All Amazon S3 buckets have encryption configured by default, and all new objects that are uploaded to an S3 bucket are automatically encrypted at rest. Server-side encryption with Amazon S3 managed keys (SSE-S3) is the default encryption configuration for every bucket in Amazon S3."

⚠️ "Enable encryption on the bucket" is a wrong answer for new objects — they are already encrypted. The real questions are which key and who controls it, which is why this section belongs next to the key-policy section rather than on its own.

⚠️ Changing the bucket default does not re-encrypt existing objects. "When you change the default encryption configuration of your bucket to SSE-KMS, the encryption type of the existing Amazon S3 objects in the bucket is not changed." The documented fix is S3 Batch Operations with the Copy objects action — "which writes them back to the same bucket as SSE-KMS encrypted objects. A single Batch Operations job can perform the specified operation on billions of objects." Remember this alongside the KMS rotation trap; they are the same misconception in two places.

To measure coverage: "To see which percentage of your storage bytes are encrypted, you can use Amazon S3 Storage Lens metrics."

⚠️ I did not verify S3 Bucket Keys or their stated reduction in KMS request costs from a fetched page in this pass. Bucket Keys are a real and commonly-examined cost optimisation for SSE-KMS at high request rates — read bucket-key.html before quoting a percentage.

In transit: ACM

From What is AWS Certificate Manager?, verified 2026-09-21:

"You are not subject to an additional charge for SSL/TLS certificates that you manage with AWS Certificate Manager. You pay only for the AWS resources that you create to run your website or application."

Two placement rules, both verbatim, and both directly examinable:

"Certificates in ACM are regional resources. To use a certificate with Elastic Load Balancing for the same fully qualified domain name (FQDN) or set of FQDNs in more than one AWS region, you must request or import a certificate for each region. … You cannot copy a certificate between regions."

"To use an ACM certificate with Amazon CloudFront, you must request or import the certificate in the US East (N. Virginia) region. ACM certificates in this region that are associated with a CloudFront distribution are distributed to all the geographic locations configured for that distribution."

us-east-1 for CloudFront, every time. This appears on the exam in both directions — as the right answer, and as a plausible-looking distractor that puts the certificate in the application's Region.

Other verified facts: ACM handles "creating, storing, and renewing public and private SSL/TLS X.509 certificates"; you can either issue directly with ACM or import third-party certificates; wildcard certificates "can protect an unlimited number of subdomains"; and certificates signed by AWS Private CA can be exported "for use anywhere in your internal PKI".

⚠️ I did not verify, in this pass, the rule that managed renewal does not apply to imported certificates. It is widely stated and exam-relevant — confirm it on docs.aws.amazon.com/acm/latest/userguide/managed-renewal.html yourself. What the page I fetched does say is that ACM "handles the complexity of creating, storing, and renewing" certificates it manages.

Note also what ACM is not for: for public certificates on your own EC2 web servers, AWS now points at ACME automation rather than ACM export — "For publicly trusted web certificates on these servers, use the ACME protocol to automate issuance and renewal directly on your hosts."

Check yourself

1. You must share an encrypted EBS snapshot with another AWS account. Which key type, and why?
2. A compliance requirement says you must be able to prove who decrypted a file. Which key types are eliminated?
3. A key was used to encrypt data that has now leaked. Does rotating the key help?
4. You switch a bucket's default encryption to SSE-KMS. What is the state of the 40 million existing objects, and what fixes it?
5. An ALB in eu-west-2 and a CloudFront distribution both need a certificate for shop.example.com. How many certificates, in which Regions?

Answers

1. A customer managed key. "You cannot share resources encrypted under an AWS managed key with other accounts." Only a customer managed key has a key policy you control, which is what lets you grant the other account.
2. AWS owned keys. "you cannot audit activities on these keys." Customer managed and AWS managed keys both log to CloudTrail, so either would satisfy the requirement.
3. No. "Key rotation will not mitigate the effect of a compromised data key", and rotation "does not … re-encrypt any data protected by the KMS key." You need to re-encrypt the data or destroy the key.
4. They stay as they were — "the encryption type of the existing Amazon S3 objects in the bucket is not changed." Fix with S3 Batch Operations using the Copy objects action.
5. Two. Certificates are Regional and cannot be copied between Regions: one in eu-west-2 for the ALB, and one in us-east-1 for CloudFront.

Teaching this section

• Lead with the key policy inversion, not with the key types. "In KMS, an IAM policy alone is not enough" is the fact that surprises experienced people, and it's the one that causes real lockouts.
• Demo: show the default key policy and point at the statement that enables IAM policies. Then ask the room what happens if you delete it. (Nobody, including root, can use the key.)
• Best discussion prompt: "We rotate our KMS keys annually, so a leaked backup from 2023 is safe." Let them agree, then read the rotation note aloud. The gap between "rotated" and "re-encrypted" is the most useful thing in this lesson.
• Watch for: learners treating S3 encryption as something you enable. Push them to the real question: which key, and who can be stopped from using it?
• Timing: 35 min presented, 15 discussion. The rotation section always runs long because people have to unlearn something. Let it.