Data Encryption and Key Management

AWS data encryption and key management is the collection of AWS services and patterns that protect data both at rest (on disk, in object stores, in databases) and in transit (on the wire between clients and AWS services, and between AWS services themselves). The flagship AWS service is AWS Key Management Service (AWS KMS), which creates and controls the cryptographic keys that Amazon S3, Amazon EBS, Amazon RDS, Amazon DynamoDB, AWS Lambda, and dozens of other AWS services use to encrypt your data. For workloads that need single-tenant FIPS 140-2 Level 3 hardware, AWS CloudHSM gives you your own cluster of hardware security modules. For TLS certificates that terminate HTTPS on Elastic Load Balancers, Amazon CloudFront, and Amazon API Gateway, AWS Certificate Manager (ACM) handles issuance, renewal, and deployment automatically. Together, AWS KMS, AWS CloudHSM, and AWS Certificate Manager form the AWS data encryption and key management layer.

On the SAA-C03 exam, Task Statement 1.3 ("Determine appropriate data security controls") expects you to pick the right AWS data encryption and key management service for each scenario, reason about envelope encryption, distinguish SSE-S3 from SSE-KMS from SSE-C from DSSE-KMS, know when CloudHSM beats AWS KMS, understand AWS KMS key rotation, and apply TLS in-transit encryption correctly. This guide walks through every construct in plain language, highlights the traps that catch repeat test takers, and gives you memorable analogies so the data encryption and key management vocabulary sticks.

What is AWS Data Encryption and Key Management?

AWS data encryption and key management is the AWS-native framework for applying cryptography to customer data throughout its lifecycle. Encryption at rest transforms data into ciphertext before it is written to storage (Amazon S3 objects, Amazon EBS volumes, Amazon RDS tables, Amazon DynamoDB items, Amazon EFS files) so that stolen media or an unauthorized AWS operator cannot read it. Encryption in transit wraps data in TLS so that a network eavesdropper between the client and the AWS service, or between two AWS services, sees only ciphertext.

Both halves depend on keys, and keys are the hard part. A leaked key defeats the strongest algorithm, so AWS data encryption and key management treats where keys live, who can use them, when they rotate, and how they are audited as first-class design concerns. AWS KMS is AWS's answer to most of those questions: a managed AWS service with hardware security modules behind the scenes that never exposes your key material to a person or a process outside the AWS KMS boundary.

Why AWS data encryption and key management matters for SAA-C03

Task 1.3 ("Determine appropriate data security controls") contributes roughly a quarter of the 30% Design Secure Architectures domain, and AWS data encryption and key management is the dominant sub-topic inside it. Exam writers love scenarios that test: "which AWS KMS key type lets you audit who used it?" (customer-managed key), "how do I enforce FIPS 140-2 Level 3?" (AWS CloudHSM), "how do I terminate TLS on an Application Load Balancer without buying certificates?" (AWS Certificate Manager), and "which S3 encryption option gives me ownership of the key?" (SSE-C or SSE-KMS with a customer-managed key). Answer those four confidently and AWS data encryption and key management stops being a weak area.

Plain-Language Explanation: AWS Data Encryption and Key Management

Theory sticks when it maps to something physical. Here are four distinct analogies that together cover every major AWS data encryption and key management construct on SAA-C03.

Analogy 1: The Bank Vault with Safe Deposit Boxes (Envelope Encryption)

Picture a large bank with a main vault and thousands of safe deposit boxes inside it. The main vault is the AWS KMS key — it lives behind very thick walls, a bank manager (AWS KMS service) controls access, and it never physically leaves the bank. Each safe deposit box key is an AWS KMS data key — the bank manager generates a fresh one every time a customer wants to store something new. Your actual documents (customer data) are locked inside the safe deposit box with the data key. To put away the documents, the customer asks AWS KMS to generate a fresh data key, uses the plaintext copy of that data key to lock the documents, immediately sends the plaintext copy back to the vault (it's erased from memory), and keeps only the encrypted copy of the data key next to the documents. To open the box later, the customer hands the encrypted data key back to the bank manager, who decrypts it inside the vault and hands back a plaintext data key to unlock the documents. The vault key (AWS KMS key) never comes out. That is envelope encryption, and it is the pattern nearly every AWS service uses when it encrypts data with AWS KMS.

Analogy 2: The Hotel Master Key vs the Floor Safe (KMS vs CloudHSM)

Think of a hotel. AWS KMS is the hotel chain's central key-issuing desk — convenient, always staffed, shared with many rooms, but the hotel chain owns and operates the desk. AWS CloudHSM is your private floor safe in a dedicated suite — only you have the combination, nobody from the hotel chain can open it, and you alone are responsible for backups and availability of that safe. When a compliance auditor demands that nobody, not even AWS staff, can ever physically touch the key material and that the hardware is FIPS 140-2 Level 3 certified, you rent the private safe (AWS CloudHSM). Otherwise, the central desk (AWS KMS) is cheaper, simpler, and FIPS 140-2 Level 3 qualified for most common key operations in its default mode.

Analogy 3: The Swiss Army Knife with Multiple Blades (S3 Encryption Options)

Amazon S3 server-side encryption is a Swiss Army knife with four blades. SSE-S3 is the main blade — always sharp, always there, no setup: Amazon S3 picks a key, manages it, rotates it, and encrypts your objects. SSE-KMS is the specialized cutting blade — you choose which AWS KMS key to use (AWS-managed or customer-managed), you get AWS CloudTrail audit records of every decrypt call, and you can apply fine-grained AWS KMS key policies and grants. SSE-C is the custom tool you bring yourself — you send Amazon S3 the encryption key with every request, Amazon S3 uses it to encrypt or decrypt, and then Amazon S3 forgets the key. DSSE-KMS is the reinforced double blade — two independent layers of server-side encryption stacked on top of each other, aimed at regulated workloads that must meet a high-assurance standard. Pick the blade that matches the job: quick default → SSE-S3; need audit + key control → SSE-KMS; must own the key material → SSE-C; must meet dual-layer compliance → DSSE-KMS.

Analogy 4: The Post Office Delivery Envelope (TLS In-Transit Encryption with ACM)

TLS in transit is like sending a sealed envelope through the post office. The envelope is the TLS session, the wax seal is the TLS certificate, and the post office inspector is the TLS handshake that confirms the seal is genuine. AWS Certificate Manager is the stationery shop that prints wax seals for you, for free, and mails a new seal to your post office drop-off box (your Application Load Balancer, Amazon CloudFront distribution, Amazon API Gateway, or AWS App Runner) before the old one expires. You never see the private key material — ACM keeps it inside the AWS service, and you get automatic renewal every 13 months. If you need a private postal network inside your organization, AWS Certificate Manager Private CA is your in-house stationery press that prints seals only your organization recognizes, for internal microservice-to-microservice TLS.

AWS KMS Concepts: CMKs, AWS-Managed Keys, and Customer-Managed Keys

AWS KMS is built around one central object — the AWS KMS key, historically called the customer master key (CMK). Every other AWS KMS feature (data keys, grants, rotation, key policies) orbits around this object. Understanding the three flavors of AWS KMS key is the single biggest lever on AWS data encryption and key management SAA-C03 scores.

AWS-owned keys

AWS-owned keys are owned and managed by AWS on behalf of all customers. You cannot see them in the AWS KMS console, you cannot audit their use, you cannot rotate them, and you cannot change their key policy. Many AWS services use AWS-owned keys as their default encryption option when no other choice is configured. They cost nothing. On the SAA-C03 exam, AWS-owned keys show up as the default baseline that "covers encryption at rest" when no explicit key choice is needed.

AWS-managed keys

AWS-managed keys are created automatically in your AWS account the first time a particular AWS service needs to encrypt data there. They appear in your AWS KMS console with an alias that starts with aws/ (for example, aws/s3, aws/ebs, aws/rds). You can view them and audit their use in AWS CloudTrail, but you cannot modify their key policy, you cannot delete them, and you cannot disable automatic yearly rotation. AWS-managed keys cost nothing to store but the API calls against them count toward your AWS KMS request pricing.

Customer-managed keys (CMKs)

Customer-managed keys are the AWS KMS keys you explicitly create in your AWS account. You control:

• The AWS KMS key policy (who can administer the key, who can use the key).
• IAM policy integration (which principals AWS IAM can authorize).
• Grants (temporary scoped delegations).
• Automatic rotation (on or off; if on, AWS KMS rotates the key material every 365 days by default, or a configurable 90 to 2560 days).
• Deletion (with a mandatory 7 to 30 day waiting period).
• Multi-Region replication (for disaster recovery and low-latency cross-region workloads).

Customer-managed keys cost USD 1.00 per month per key and are the correct choice whenever the scenario demands audit visibility, custom access control, or explicit key ownership.

Symmetric vs asymmetric AWS KMS keys

Inside all three categories, AWS KMS keys come in two shapes:

• Symmetric AWS KMS keys use AES-256-GCM. One key material encrypts and decrypts, and the key material never leaves AWS KMS. Used for nearly every AWS data encryption and key management scenario in AWS services.
• Asymmetric AWS KMS keys use RSA or ECC key pairs. The public key can be exported and distributed; the private key stays inside AWS KMS. Used for digital signing, signature verification, and encrypt/decrypt workflows where only the sender has the public half.

Envelope Encryption — How AWS KMS Wraps Data Keys

Envelope encryption is the pattern that makes AWS KMS scalable. Without it, AWS KMS would have to encrypt and decrypt every byte of customer data through its own hardware; with it, AWS KMS only handles the tiny data keys, and the bulk data is encrypted locally in the AWS service that owns it.

The GenerateDataKey API call

When an AWS service such as Amazon S3 receives a PutObject request that specifies SSE-KMS, it calls kms:GenerateDataKey on your chosen AWS KMS key. AWS KMS returns two things in one response:

1. A plaintext data key (typically a 256-bit AES key).
2. The same data key encrypted with the AWS KMS key (ciphertext blob).

Amazon S3 uses the plaintext data key to encrypt the object bytes with AES-256-GCM, stores the ciphertext object alongside the encrypted data key, and immediately discards the plaintext data key from memory. To read the object later, Amazon S3 sends the encrypted data key back to AWS KMS with a kms:Decrypt call, receives the plaintext data key, decrypts the object, and again discards the plaintext data key.

Why envelope encryption matters

• AWS KMS key material never leaves AWS KMS. Even during active encryption, only the tiny data key makes a round trip. The AWS KMS key itself lives inside AWS KMS's hardware boundary for its entire lifetime.
• Throughput scales. AWS KMS does not have to encrypt every byte of a petabyte-scale Amazon S3 object; it only has to handle the data key. This lets AWS KMS serve very high request rates across all AWS services.
• Blast radius is limited. A compromised data key exposes one object. A compromised AWS KMS key would expose every data key ever wrapped with it — but the AWS KMS key lives inside an AWS KMS hardware security module and is never handed out.

S3 Encryption Options: SSE-S3, SSE-KMS, SSE-C, and DSSE-KMS

Amazon S3 exposes four server-side encryption (SSE) options plus client-side encryption. SAA-C03 questions often rest entirely on your ability to pick the right one.

SSE-S3 (default in 2023 and later)

SSE-S3 uses AES-256 with keys that Amazon S3 owns, manages, and rotates on your behalf. Since January 2023, SSE-S3 is the default for every new Amazon S3 object — if you do nothing, your data is encrypted at rest with SSE-S3. You get no visibility into the key and no AWS CloudTrail audit of the key's use. Free of direct AWS KMS charges. Use SSE-S3 when you just need encryption at rest with zero operational overhead and do not need to prove key ownership.

SSE-KMS

SSE-KMS uses an AWS KMS key (AWS-managed aws/s3 or a customer-managed key) to wrap each object's data key via envelope encryption. Advantages over SSE-S3:

• AWS CloudTrail audit trail of every encrypt and decrypt call.
• AWS KMS key policy control over who can use the key.
• Customer-managed key option for complete lifecycle control.
• Cross-account and multi-Region data sharing patterns via AWS KMS key policies.

Trade-offs: each Amazon S3 operation generates an AWS KMS API call, which counts against your AWS KMS request pricing and request throughput limits. For high-traffic Amazon S3 workloads, enable Amazon S3 Bucket Keys to reduce AWS KMS request volume by ~99% by caching a short-lived bucket-level intermediate key.

SSE-C (customer-provided key)

SSE-C asks you to supply the encryption key with every request. Amazon S3 uses the key to encrypt (on PUT) or decrypt (on GET) and then deletes it from memory; Amazon S3 never stores the SSE-C key. You are 100% responsible for key management and availability. If you lose the key, your object is unrecoverable. Used rarely, typically by regulated workloads that mandate full customer ownership of key material outside of any AWS-managed service.

DSSE-KMS (dual-layer server-side encryption, 2023+)

DSSE-KMS applies two independent layers of AES-256 server-side encryption, both tied to your AWS KMS key. The feature is aimed at U.S. federal workloads with Committee on National Security Systems (CNSS) data and other regulated scenarios that require dual-layer object encryption. Regular commercial workloads should stick with SSE-KMS.

Client-side encryption

Client-side encryption encrypts data on your side before it ever reaches Amazon S3; Amazon S3 then stores already-encrypted bytes. Use the AWS Encryption SDK or Amazon S3 Encryption Client for this. You manage the keys (typically via AWS KMS, via a customer key store in AWS CloudHSM, or via your own keystore). Use when the threat model distrusts the AWS service itself — for example, when regulators require that AWS cannot read the data under any circumstances.

EBS, RDS, EFS, and DynamoDB Encryption at Rest

Encryption at rest is not only an Amazon S3 topic. Every major storage and database AWS service integrates with AWS KMS in the same envelope-encryption pattern.

Amazon EBS encryption

Amazon Elastic Block Store volumes can be encrypted with an AWS KMS key at creation time; the encryption is transparent to the attached Amazon EC2 instance. The AWS KMS key wraps a volume-specific data key that encrypts every block of the volume and every snapshot taken from it. Snapshots copied across AWS Regions are re-encrypted with the destination region's AWS KMS key you specify. You can enable Amazon EBS Encryption by Default at the AWS Region level so every new volume in the AWS Region is automatically encrypted with the AWS KMS key of your choice.

Amazon RDS, Aurora, and Redshift encryption

Amazon RDS, Amazon Aurora, and Amazon Redshift all support encryption at rest with AWS KMS. The important SAA-C03 rule: encryption can only be enabled at creation time. To encrypt an existing unencrypted Amazon RDS database, take a snapshot, copy the snapshot with encryption enabled (choosing an AWS KMS key), and restore the encrypted snapshot into a new encrypted Amazon RDS instance. Read replicas inherit the source's encryption setting; encrypted sources produce encrypted replicas, and an unencrypted Amazon RDS database cannot have an encrypted read replica.

Amazon EFS and FSx encryption

Amazon EFS is encrypted at rest with AWS KMS at file system creation time and supports TLS encryption in transit with mount helper integration. Amazon FSx (Windows File Server, Lustre, NetApp ONTAP, OpenZFS) similarly supports AWS KMS encryption at rest and integrates with customer-managed keys when compliance demands it.

Amazon DynamoDB encryption

Amazon DynamoDB tables are always encrypted at rest — there is no option to disable it. Three key choices: AWS-owned (default, free), AWS-managed (aws/dynamodb), or customer-managed. Global tables replicate the encryption property to all replica AWS Regions, each with its own AWS KMS key selection.

AWS KMS Key Policies, IAM, and Grants — Three Layers of Access Control

AWS KMS is one of the few AWS services whose access control is not fully delegated to AWS IAM. Instead, access to an AWS KMS key is gated by three overlapping layers.

Key policies

Every AWS KMS key has a key policy — a JSON document attached directly to the AWS KMS key. It is the primary access control mechanism: if the key policy does not allow an action, no other policy can grant it, with narrow exceptions. The default key policy created by the AWS KMS console delegates administration to the AWS account root and specifies that AWS IAM policies in the same AWS account may authorize AWS KMS actions — this is what allows AWS IAM policies to grant kms:Decrypt to a user.

IAM policies

If and only if the key policy delegates to AWS IAM (via the standard "Enable IAM policies" statement), identity-based AWS IAM policies can grant AWS KMS actions to principals. Without that delegation clause in the key policy, AWS IAM policies are ignored for this AWS KMS key — which is a powerful way to lock a customer-managed key so that only explicit key policy principals can touch it.

Grants

A grant is a temporary, programmatic delegation of AWS KMS permissions from one principal to another. Grants are typically issued by AWS services on your behalf — for example, when Amazon EBS needs to let Amazon EC2 use an AWS KMS key for a specific volume, Amazon EBS creates a grant scoped to exactly that volume. Grants are additive to key policies and IAM policies; they never override an explicit deny in the key policy.

Cross-account AWS KMS key use

For an AWS principal in AWS Account B to encrypt or decrypt with an AWS KMS key owned by Account A, both must be configured:

1. Account A's key policy must allow the Account B principal (or the Account B root) to call the desired AWS KMS actions.
2. Account B's AWS IAM policy must grant that principal the same AWS KMS actions on the Account A AWS KMS key ARN.

This dual-policy model appears frequently in cross-account Amazon S3 scenarios: a bucket in Account A encrypted with a customer-managed AWS KMS key in Account A, and a consumer in Account B. If either the AWS KMS key policy or the Account B AWS IAM policy is missing the grant, the download fails with an AccessDeniedException referencing AWS KMS rather than Amazon S3.

AWS KMS Key Rotation — Automatic vs Manual

Rotation changes the underlying key material while preserving the key's identity (key ID and ARN). It is one of the most-tested single facts on SAA-C03.

Automatic rotation

For customer-managed symmetric AWS KMS keys, you can enable automatic key rotation. AWS KMS rotates the underlying cryptographic material every 365 days by default (configurable between 90 and 2560 days as of 2024). Critically:

• The AWS KMS key ID and ARN do not change — your applications keep referencing the same ARN.
• Old key material is retained so that previously encrypted data can still be decrypted.
• Rotation is transparent — no re-encryption of existing data is needed.
• AWS-managed keys rotate automatically every year and you cannot turn this off (nor can you modify the rotation period).
• Automatic rotation is only available for symmetric AWS KMS keys with AWS-owned key material. Asymmetric keys and keys with imported key material cannot be automatically rotated.

Manual rotation

For asymmetric AWS KMS keys and for AWS KMS keys with imported key material, rotation is manual. The pattern is:

1. Create a new AWS KMS key with fresh material.
2. Update the alias to point at the new AWS KMS key.
3. Re-encrypt existing ciphertext if you want the new material to protect it.

Applications that reference the alias (alias/my-app-key) rather than the underlying key ID continue to work without code changes.

AWS KMS keys with imported key material

You can import your own key material into an AWS KMS key (Bring Your Own Key, BYOK). Imported-material keys let you retain a master copy of the key outside AWS and delete the key material from AWS KMS whenever needed. They cannot use automatic rotation and they count as customer-managed keys for pricing.

AWS CloudHSM vs AWS KMS — Dedicated HSM vs Managed Key Service

AWS CloudHSM and AWS KMS both back their cryptographic operations with hardware security modules, but the ownership and compliance models differ sharply.

What AWS CloudHSM is

AWS CloudHSM provisions one or more single-tenant hardware security modules inside your Amazon VPC. You are the sole owner of those HSM appliances — AWS operates the physical hardware but has no visibility into the key material, the users, or the cryptographic operations performed on them. AWS CloudHSM is certified to FIPS 140-2 Level 3 (the HSM hardware is tamper-evident and tamper-responsive), and its operator (you) is also the sole root of trust.

Why a workload would choose AWS CloudHSM over AWS KMS

• Single-tenant hardware requirement. Some regulations (for example, certain U.S. DoD workloads, PCI PIN transaction processing, and specific EU financial regulations) demand that key material reside in an HSM dedicated to one customer.
• FIPS 140-2 Level 3 throughout the full operation stack. AWS KMS is FIPS 140-2 validated, but its multi-tenant architecture is distinct from CloudHSM's single-tenant HSM.
• Direct PKCS #11, JCE, or Microsoft CNG integration. On-premises applications and third-party software often require a standard HSM API that AWS KMS does not expose.
• Cryptographic operations not offered by AWS KMS. For example, SSL/TLS offload on a dedicated HSM, legacy 3DES, or custom elliptic curves.
• Custom key store for AWS KMS. You can link an AWS CloudHSM cluster as a custom key store for AWS KMS, so that AWS KMS keys stored there live on your CloudHSM HSM but still integrate with AWS services via AWS KMS APIs.

Why most workloads pick AWS KMS

• Fully managed. AWS KMS handles availability, scaling, rotation, and patching.
• Integrated with every major AWS service. Amazon S3, Amazon EBS, Amazon RDS, Amazon DynamoDB, AWS Lambda, and dozens more use AWS KMS out of the box.
• Cheaper. USD 1.00/month per customer-managed key vs a CloudHSM cluster starting at roughly USD 1.45/hour per HSM plus a minimum of two HSMs for high availability.
• Good enough FIPS posture for most enterprise and regulated workloads.

CloudHSM high availability and minimum cluster size

An AWS CloudHSM cluster is the unit of HA. A cluster with one HSM is allowed but offers no redundancy; AWS recommends at least two HSMs spread across at least two Availability Zones for production. CloudHSM synchronizes key material across every HSM in the cluster automatically; if one HSM fails, the remaining HSMs continue serving operations.

AWS Certificate Manager (ACM) — Public vs Private CA, Automatic Renewal, and Service Integrations

AWS Certificate Manager (ACM) is the AWS data encryption and key management service that provisions, deploys, and renews TLS/SSL certificates used to encrypt data in transit. On SAA-C03, ACM questions cluster around three topics: public vs private CA, automatic renewal, and which AWS services can use ACM certificates directly.

Public ACM certificates

A public ACM certificate is signed by Amazon's public certificate authority (Amazon Trust Services) and is trusted by every major browser, operating system, and HTTP client. Public ACM certificates are free when used with supported AWS services. Domain validation happens via DNS (an Amazon Route 53 or other DNS provider CNAME record, with Route 53 integration one-click easy) or email. Once validated, ACM issues the certificate and begins automatic renewal 60 days before expiration — as long as the validation record remains in place, you never handle renewal manually.

Private ACM certificates (AWS Private CA)

AWS Private CA (formerly ACM Private CA) provisions a private certificate authority hierarchy that you fully control. Private ACM certificates are trusted only by clients that trust your private root — typically internal microservices, container mesh traffic, and VPN clients. AWS Private CA is a paid AWS service (monthly CA fee + per-certificate issuance fee). Use it for zero-trust microservice-to-microservice TLS, IoT device fleets, and Kubernetes mesh deployments where a public certificate would be wasteful or leak internal names to public logs.

Where you can deploy ACM certificates

ACM-issued public certificates deploy automatically to a specific short list of AWS services:

• Elastic Load Balancing (Application Load Balancer, Network Load Balancer with TLS listeners, Classic Load Balancer).
• Amazon CloudFront distributions.
• Amazon API Gateway custom domain names.
• AWS App Runner custom domains.
• AWS Elastic Beanstalk (through the underlying load balancer).
• AWS Nitro Enclaves via the ACM-Nitro integration.

Notably, ACM public certificates cannot be exported. The private key never leaves ACM. For Amazon EC2 instances that need a certificate directly on the host, you must either use AWS Private CA (which can export) or use a third-party certificate, or, more commonly, front the Amazon EC2 instance with an ALB that holds the ACM certificate.

ACM in CloudFront vs regional AWS services

An ACM certificate used with Amazon CloudFront must be provisioned in the us-east-1 (N. Virginia) AWS Region, regardless of where the origin lives, because Amazon CloudFront is a global AWS service anchored there. Certificates for regional AWS services (ALB, API Gateway) must live in the same AWS Region as the service.

Encryption In-Transit: TLS, VPC Endpoints, and AWS Service Patterns

Encryption in transit protects data while it is moving between a client and an AWS service, or between two AWS services. The answer to "how do I enable encryption in transit?" is almost always "terminate TLS" — but the mechanics differ per AWS service.

Public-facing TLS with ACM

For HTTPS on an Application Load Balancer, Amazon CloudFront distribution, or Amazon API Gateway, attach an ACM certificate. The ALB/CloudFront/API Gateway terminates TLS and re-encrypts (or not, depending on configuration) to the backend. Amazon CloudFront supports HTTPS-only viewer policies, TLS 1.2 and 1.3 minimums, and can even re-encrypt to the origin with a separate certificate — end-to-end TLS.

VPC endpoints and AWS PrivateLink

When an Amazon VPC resource calls an AWS service, the traffic is encrypted in transit with TLS by default for every modern AWS service API. But the traffic still traverses the public AWS network boundary when the call leaves the Amazon VPC through an Internet Gateway or NAT Gateway. AWS PrivateLink (Interface VPC endpoints) keeps that traffic on the AWS private network:

• Traffic never leaves the Amazon VPC.
• TLS still terminates inside AWS, not on the public internet.
• No Internet Gateway, no NAT Gateway, no Direct Connect public VIF needed.
• Many regulated AWS architectures require VPC endpoints specifically to ensure traffic paths stay private.

Gateway VPC endpoints (for Amazon S3 and Amazon DynamoDB) provide a similar private path without the interface endpoint cost, but they operate at the routing layer rather than via PrivateLink.

AWS KMS VPC endpoints

AWS KMS itself supports an Interface VPC endpoint. Enabling it is a compliance win for architectures that must prove no AWS KMS traffic crosses the public internet, even while inside AWS. Pair the AWS KMS VPC endpoint with an endpoint policy that restricts which principals and AWS KMS keys can be called through the endpoint.

In-transit encryption for storage and databases

• Amazon S3 supports TLS 1.2+ for every client request; you can enforce HTTPS-only with a bucket policy that denies aws:SecureTransport = false.
• Amazon RDS / Aurora supports TLS with Amazon RDS-issued certificates; enforce it with rds.force_ssl = 1 (PostgreSQL) or require SSL in the database parameter group (MySQL).
• Amazon EFS supports TLS encryption in transit through the EFS mount helper with the -o tls mount option.
• Amazon Redshift supports TLS for JDBC/ODBC connections; enforce via the cluster parameter group.
• Amazon DynamoDB requires HTTPS for every API call — there is no way to disable TLS.

Key Numbers and Must-Memorize Facts for AWS Data Encryption and Key Management

Memorize this list. It covers the majority of AWS data encryption and key management numeric and categorical traps on SAA-C03.

Common Exam Traps — AWS Data Encryption and Key Management

Expect to see at least two of these on every SAA-C03 attempt. Learn the pattern before reading answer choices.

Trap 1: SSE-KMS vs SSE-S3 customer control

The scenario asks for "encryption where the customer can audit every access and disable the key if compromised". SSE-S3 cannot satisfy this because Amazon S3 hides the key from you. The right answer is SSE-KMS with a customer-managed AWS KMS key, whose use is logged in AWS CloudTrail and whose access is gated by an AWS KMS key policy you control.

Trap 2: CMK vs data key confusion

Answer choices that describe "encrypting a 100 MB Amazon S3 object directly with an AWS KMS key" are distractors. AWS KMS keys do not encrypt data directly at that scale — they encrypt data keys, and the data keys encrypt the payload. Remember envelope encryption: AWS KMS key → data key → customer data.

Trap 3: AWS KMS rotation limits

Automatic rotation works only for customer-managed symmetric AWS KMS keys with AWS-owned material. Asymmetric AWS KMS keys and keys with imported key material require manual rotation. Scenarios that mention "imported BYOK" or "asymmetric key" combined with "enable automatic rotation" are pointing to a wrong answer.

Trap 4: AWS KMS key policy must delegate to IAM

An AWS IAM policy that grants kms:Decrypt is useless if the AWS KMS key's key policy does not include the "Enable IAM policies" statement. Scenarios that present a call that "mysteriously fails despite having IAM permission" often hinge on this missing delegation in the key policy.

Trap 5: CloudHSM is almost always wrong

AWS CloudHSM is the correct answer only when the question explicitly says single-tenant HSM, FIPS 140-2 Level 3 for the HSM owner, or PKCS #11 / Microsoft CNG integration. Otherwise AWS KMS is cheaper, simpler, and more integrated with AWS services. "The company needs to encrypt data at rest with a managed key service" → AWS KMS, not AWS CloudHSM.

Trap 6: ACM certificates cannot be exported

"Download the ACM certificate and install it on the Amazon EC2 instance" is a wrong answer. ACM public certificates never expose their private key. For Amazon EC2 terminating TLS directly, either use AWS Private CA (which can export), install a third-party certificate, or put an ALB in front of the Amazon EC2 instance and use ACM on the ALB.

Trap 7: Cross-account AWS KMS needs both policies

For Account B to decrypt an object in Account A encrypted with Account A's AWS KMS key, both the AWS KMS key policy in Account A and the AWS IAM policy in Account B must allow the operation. Single-sided permission grants fail.

Trap 8: Amazon RDS encryption cannot be toggled in place

Any answer choice like "modify the Amazon RDS instance to enable encryption at rest" is wrong. Snapshots → copy-with-encryption → restore is the only path. The same trap applies to Amazon EBS volumes and Amazon Redshift clusters.

Encryption vs Access Control — Complementary, Not Interchangeable

On SAA-C03, candidates sometimes treat encryption and access control as substitutes. They are not.

Access control (AWS IAM, bucket policies, security groups, NACLs, AWS KMS key policies) decides who can call the API. Encryption (AWS KMS, SSE-*, TLS, AWS CloudHSM) protects the data bytes themselves even if the API boundary is bypassed — for example, a stolen disk, a compromised AWS operator, or a network eavesdropper.

A defense-in-depth architecture uses both:

• AWS IAM and bucket policies restrict s3:GetObject to authorized principals.
• SSE-KMS with a customer-managed AWS KMS key means that even a principal who somehow bypasses Amazon S3 cannot read the raw object bytes without also being authorized by the AWS KMS key policy.
• TLS in transit means a network attacker cannot read the bytes on the wire even if they somehow intercept them.

Many SAA-C03 questions award credit for recognizing that an architecture needs encryption in addition to access control, not instead of it.

Practice Question Links — Task 1.3 Mapped Scenarios

• "Which AWS KMS key type allows the customer to audit every use and disable the key if compromised?" → Customer-managed AWS KMS key (audit via AWS CloudTrail, full lifecycle control).
• "Regulator requires a single-tenant HSM with FIPS 140-2 Level 3 and PKCS #11 access." → AWS CloudHSM, minimum 2 HSMs across 2 AZs.
• "Amazon S3 bucket must be encrypted so that only a specific AWS IAM role can decrypt objects, and every access is logged." → SSE-KMS with a customer-managed AWS KMS key, key policy naming the IAM role, CloudTrail enabled.
• "Company needs to rotate an AWS KMS key's underlying material annually with no application changes." → Enable automatic rotation on the customer-managed symmetric AWS KMS key.
• "Application Load Balancer must terminate HTTPS with a certificate that renews automatically and costs nothing." → ACM public certificate with DNS validation.
• "Microservice mesh inside an Amazon VPC needs private TLS certificates for pod-to-pod traffic." → AWS Private CA + ACM-issued private certificates.
• "Existing unencrypted Amazon RDS database must become encrypted at rest." → Snapshot → copy snapshot with encryption enabled → restore → cut over.
• "Amazon EC2 instance in a private subnet must call AWS KMS without traversing the public internet." → AWS KMS Interface VPC endpoint plus restrictive endpoint policy.
• "Amazon S3 bucket must refuse any request that is not over HTTPS." → Bucket policy denying aws:SecureTransport = false.
• "Customer requires dual-layer server-side encryption for regulated Amazon S3 workloads." → DSSE-KMS.

FAQ — AWS Data Encryption and Key Management Top Questions

Q1: What is the difference between AWS KMS and AWS CloudHSM?

AWS KMS is a multi-tenant, fully managed AWS key management service that integrates with every major AWS service and costs USD 1.00/month per customer-managed key. AWS CloudHSM provisions single-tenant FIPS 140-2 Level 3 hardware security modules inside your Amazon VPC, giving you sole ownership of the HSM appliances and key material at a higher cost (roughly USD 1.45/hour per HSM with a 2-HSM minimum for HA). Default to AWS KMS unless the scenario explicitly requires single-tenant hardware, FIPS 140-2 Level 3 ownership, or PKCS #11 / Microsoft CNG integration.

Q2: What is envelope encryption and why does AWS KMS use it?

Envelope encryption is the pattern of encrypting customer data with a short-lived data key and then encrypting the data key with a long-lived AWS KMS key. The AWS KMS key never leaves AWS KMS hardware; only the tiny data key makes a round trip. This means AWS KMS does not have to process every byte of customer data, which keeps throughput high, and it means a compromised data key exposes only one piece of data, not the master key. Nearly every AWS service that integrates with AWS KMS (Amazon S3, Amazon EBS, Amazon RDS, Amazon DynamoDB, etc.) uses envelope encryption under the hood.

Q3: When should I choose SSE-KMS over SSE-S3 for Amazon S3?

Choose SSE-KMS when you need any of: customer control over the key lifecycle (rotation, disable, delete), AWS CloudTrail audit records of every encrypt and decrypt call, cross-account data-sharing patterns via an AWS KMS key policy, or compliance attestations that require explicit customer key ownership. Choose SSE-S3 when you just want encryption at rest with zero configuration and no AWS KMS request charges. For very high-throughput SSE-KMS workloads, enable Amazon S3 Bucket Keys to cut AWS KMS request volume by roughly 99% without losing the audit trail.

Q4: How does AWS KMS automatic rotation work, and what are the limits?

Automatic rotation is available for customer-managed symmetric AWS KMS keys with AWS-owned key material. When enabled, AWS KMS generates new underlying cryptographic material every 365 days by default (configurable between 90 and 2560 days). The AWS KMS key's ID and ARN do not change, and old key material is retained so that previously encrypted data is still decryptable. Asymmetric AWS KMS keys and keys with imported (BYOK) material must be rotated manually by creating a new AWS KMS key and updating the alias. AWS-managed keys rotate automatically every year and the rotation cannot be disabled or modified.

Q5: How do I encrypt an existing unencrypted Amazon RDS database or Amazon EBS volume?

You cannot toggle encryption on an existing Amazon RDS database or Amazon EBS volume. The canonical workflow is: take a snapshot of the existing unencrypted resource, copy the snapshot while specifying an AWS KMS key and enabling encryption on the copy, restore the encrypted snapshot into a new resource, cut application traffic over to the new encrypted resource, and finally retire the old unencrypted original. The same pattern works for Amazon Redshift clusters. Enable Amazon EBS Encryption by Default at the AWS Region level so that every new volume in the AWS Region is encrypted going forward — that way new resources never repeat the unencrypted state.

Q6: How does AWS Certificate Manager handle certificate renewal?

ACM issues public certificates that are free when deployed to supported AWS services (Application Load Balancer, Network Load Balancer, Amazon CloudFront, Amazon API Gateway, AWS App Runner, and a few others). Automatic renewal begins 60 days before expiration, and as long as the DNS validation CNAME records (or email validation) remain reachable, ACM rotates the certificate transparently — no application code changes, no manual uploads. The renewed certificate keeps the same ARN, so downstream configuration is untouched. For Amazon CloudFront, remember ACM certificates must be provisioned in us-east-1 regardless of where your origin lives.

Q7: Why does an AWS IAM policy granting kms:Decrypt sometimes still fail?

AWS KMS is one of the few AWS services where AWS IAM policies alone are not sufficient. The AWS KMS key policy is the primary authorization document attached directly to the key. Unless the key policy contains the standard "Enable IAM policies" statement that delegates authorization authority to AWS IAM in the same AWS account, AWS IAM policies have no effect on that AWS KMS key. For cross-account use, both the AWS KMS key policy in the owning account and the AWS IAM policy in the caller's account must grant the desired AWS KMS action, and the caller must reference the AWS KMS key by its full ARN.

Further Reading

• AWS Key Management Service Developer Guide
• AWS KMS Envelope Encryption
• AWS KMS Key Policies
• AWS KMS Rotating Keys
• AWS KMS Grants
• AWS CloudHSM User Guide
• AWS Certificate Manager User Guide
• Amazon S3 Server-Side Encryption
• Amazon S3 DSSE-KMS Dual-Layer Encryption
• Amazon EBS Encryption
• AWS PrivateLink and VPC Endpoints
• AWS SAA-C03 Exam Guide (PDF)