This chapter covers data encryption on AWS, a critical component of the Security & Compliance domain for the CLF-C02 exam. Encryption is the process of converting readable data (plaintext) into an unreadable format (ciphertext) using a cryptographic key. This objective (2.3) represents approximately 12-15% of the exam. You will learn about encryption at rest and in transit, AWS Key Management Service (KMS), AWS CloudHSM, and how to protect data in Amazon S3, EBS, RDS, and other services. Understanding these concepts is essential for designing secure architectures and passing the exam.
Jump to a section
Imagine you run a business and keep sensitive documents in a safe deposit box at a bank. The bank's vault (AWS) protects the box with physical security, but you also want to protect the documents themselves in case the box is opened by someone else. So you put each document inside a locked briefcase (encryption) before placing it in the box. Only you have the key (encryption key) to the briefcase. Now, when you need to send a document to a partner, you take the briefcase out, lock it, and hand it to a courier (AWS Key Management Service). The courier delivers it securely, but you worry about the courier seeing the key. So you use a special service where the courier carries a sealed envelope containing the key, and only the partner has the other half of the key (envelope encryption). The courier never sees the document; they just transport the locked briefcase and the sealed key envelope. If someone intercepts the courier, they get a locked briefcase and an unreadable key envelope. This mirrors how AWS KMS uses envelope encryption: data is encrypted with a data key, which is itself encrypted by a master key. The encrypted data key is stored alongside the data, so only someone with permission to decrypt the master key can unwrap the data key and then decrypt the data. The courier (network) never handles the master key directly.
What is Data Encryption and Why Does It Matter?
Data encryption is a security mechanism that transforms data into a coded form that can only be read by someone with the correct decryption key. In AWS, encryption is used to protect data from unauthorized access, whether it's stored on disk (encryption at rest) or traveling over a network (encryption in transit). The CLF-C02 exam expects you to understand the difference and know which AWS services provide each type.
Encryption at Rest vs. Encryption in Transit
Encryption at Rest: Protects data when it is stored on physical media (e.g., hard drives, SSDs). AWS services like Amazon S3, Amazon EBS, Amazon RDS, and DynamoDB offer encryption at rest using server-side encryption (SSE) or client-side encryption. The exam tests your knowledge of SSE-S3, SSE-KMS, and SSE-C for S3.
Encryption in Transit: Protects data as it moves between your on-premises environment and AWS, or between AWS services. This is typically achieved using TLS/SSL certificates. AWS services like Elastic Load Balancer (ELB), Amazon CloudFront, and API Gateway enforce encryption in transit by default.
AWS Key Management Service (KMS)
KMS is a managed service that makes it easy to create and manage cryptographic keys. It is integrated with many AWS services to encrypt your data at rest. KMS uses Hardware Security Modules (HSMs) to protect key material. Key features include: - Customer Master Keys (CMKs): You can create symmetric or asymmetric CMKs. Symmetric keys are used for most AWS service integrations. - Envelope Encryption: When you encrypt data larger than 1 KB, KMS uses envelope encryption. It generates a data key, encrypts the data with that data key, then encrypts the data key with a CMK. The encrypted data key is stored with the data. This ensures that the CMK is never exposed to the data itself. - Automatic Key Rotation: You can enable automatic annual rotation for symmetric CMKs. AWS managed keys (e.g., aws/s3) rotate automatically every year. - Key Policies and Grants: Control who can use keys and under what conditions. Key policies are resource-based policies attached to the CMK. - Integration: KMS integrates with S3, EBS, RDS, DynamoDB, Lambda, and more.
AWS CloudHSM
CloudHSM is a dedicated hardware security module (HSM) that you manage yourself. It provides single-tenant, FIPS 140-2 Level 3 validated HSMs. Unlike KMS, you have full control over the HSM appliance, including key management and cryptographic operations. CloudHSM is used for scenarios requiring regulatory compliance (e.g., PCI DSS) or when you need to generate keys outside of AWS's control.
Encryption in Amazon S3
Amazon S3 offers several encryption options: - SSE-S3: Server-side encryption with Amazon S3-managed keys. Each object is encrypted with a unique key, and the key itself is encrypted with a master key that rotates regularly. No user configuration needed. - SSE-KMS: Server-side encryption with AWS KMS-managed keys. Provides separate permissions for the use of a CMK, and gives you an audit trail of when the key was used. You can also use a customer-managed CMK. - SSE-C: Server-side encryption with customer-provided keys. You provide your own encryption key, and S3 manages the encryption/decryption. AWS does not store the key; you must provide it for every request. - Client-Side Encryption: You encrypt data before uploading to S3. You manage the keys and encryption process.
Encryption in Amazon EBS
Amazon EBS volumes can be encrypted at rest using AWS KMS. When you create an encrypted EBS volume, data at rest, data in transit between the volume and the instance, snapshots of the volume, and any volumes created from those snapshots are all encrypted. You can specify a KMS key (CMK) or use the default aws/ebs key. Encryption is transparent to the application.
Encryption in Amazon RDS
Amazon RDS supports encryption at rest using AWS KMS. You can enable encryption when creating a new DB instance. Encrypted RDS instances use KMS to encrypt the underlying storage, automated backups, read replicas, and snapshots. Encryption cannot be enabled on an existing unencrypted DB instance; you must create a snapshot, copy it with encryption, and restore.
Encryption in Transit with TLS/SSL
AWS services use TLS certificates to encrypt data in transit. For example, Application Load Balancer (ALB) can terminate TLS connections. Amazon CloudFront uses SSL/TLS to serve content over HTTPS. You can use AWS Certificate Manager (ACM) to provision, manage, and deploy public and private SSL/TLS certificates.
Comparison to On-Premises
On-premises, you would need to purchase and manage HSMs, rotate keys manually, and ensure compliance. AWS KMS abstracts all this, providing automatic key rotation, integration with many services, and pay-as-you-go pricing. CloudHSM gives you more control but requires more management. The exam expects you to know when to use KMS vs. CloudHSM.
When to Use Each Option
Use SSE-S3 for basic encryption needs where you don't need to control the key or audit key usage.
Use SSE-KMS when you need separate permissions for key use, audit trails, or to encrypt across multiple AWS services.
Use SSE-C if you want to manage your own keys but want AWS to handle the encryption process.
Use client-side encryption if you need to encrypt data before it reaches AWS.
Use CloudHSM for regulatory compliance that requires dedicated HSM or when you need to generate keys outside of AWS's control.
Create a KMS Customer Master Key
In the AWS Management Console, navigate to KMS and choose 'Create a key'. Select 'Symmetric' (default) for most use cases. Provide an alias (e.g., 'my-app-key') and optional description. Define key administrative permissions (who can manage the key) and key usage permissions (who can encrypt/decrypt with the key). KMS generates the key material inside an FIPS 140-2 validated HSM. The key is never exported in plaintext. You can also choose to import your own key material (BYOK).
Enable automatic key rotation
After creating the key, you can enable automatic annual rotation. On the key details page, under 'Key rotation', select 'Rotate this key every year'. AWS KMS will automatically create new backing key material each year, but the key ID and alias remain the same. Old key material is retained for decryption of older data. This helps meet compliance requirements for periodic key rotation without manual intervention.
Encrypt an S3 object using SSE-KMS
When uploading an object to S3, specify the encryption setting. In the console, under 'Properties' during upload, select 'AWS-KMS' as the encryption type and choose your CMK from the dropdown. Behind the scenes, S3 calls KMS to generate a data key. S3 encrypts the object with the data key, then encrypts the data key with the CMK. The encrypted data key is stored as metadata of the object. When you download the object, S3 calls KMS to decrypt the data key, then uses it to decrypt the object.
Grant cross-account access to a KMS key
To allow a user in another AWS account to use your CMK, you must modify the key policy. Add a statement granting the root user of the external account permission to use the key (e.g., 'kms:Decrypt'). Then, the external account admin must create a grant or assign IAM policies to their users to allow them to call KMS operations. The key policy must explicitly allow the external account, because KMS key policies are resource-based and do not automatically trust other accounts.
Create an encrypted EBS volume
When launching an EC2 instance, under 'Configure storage', check 'Encrypt this volume'. Choose the KMS key (default aws/ebs or your own CMK). AWS encrypts the volume using envelope encryption. All data written to the volume is encrypted before being written to disk. Snapshots of the volume are also encrypted. When you attach the volume to an instance, the instance's hypervisor decrypts the data transparently. Encryption does not affect performance significantly.
Scenario 1: Healthcare Application with Compliance Requirements
A healthcare company stores patient records in Amazon S3. They must comply with HIPAA, which requires encryption at rest. They choose SSE-KMS with a customer-managed CMK. This allows them to control key rotation and audit every use of the key via AWS CloudTrail. They also enable automatic key rotation annually. The security team grants different IAM roles access to the key: the data science team can decrypt for analysis, while the backup team can only encrypt. This granular control prevents unauthorized decryption. Cost: KMS charges $1/month per CMK and $0.03 per 10,000 API calls. For millions of objects, the cost is manageable.
Scenario 2: Financial Services with Dedicated HSM
A financial institution needs to generate and store keys in a FIPS 140-2 Level 3 validated HSM for PCI DSS compliance. They use AWS CloudHSM instead of KMS. They manage their own HSM cluster, create keys, and integrate with their custom encryption application. They must handle key backups and HSM firmware updates themselves. This gives them full control but requires operational overhead. Misconfiguration, such as not backing up the HSM, could lead to permanent data loss. Cost: CloudHSM charges per hour per HSM, which is higher than KMS but necessary for compliance.
Scenario 3: E-commerce Platform with Encryption in Transit
An e-commerce platform uses an Application Load Balancer (ALB) to distribute traffic to EC2 instances. They use AWS Certificate Manager (ACM) to provision a public SSL/TLS certificate for their domain. The ALB terminates TLS, decrypts traffic, and forwards it to backend instances over HTTP. This reduces CPU load on instances. They also enable encryption at rest for RDS databases using SSE-KMS. A common mistake is forgetting to encrypt RDS snapshots, which can expose data. Cost: ACM public certificates are free; KMS costs apply for RDS encryption.
What CLF-C02 Tests
This objective (2.3) falls under the Security & Compliance domain, which makes up about 20-25% of the exam. Questions focus on differentiating encryption at rest vs. in transit, knowing which AWS services provide each, and understanding KMS, CloudHSM, and S3 encryption options.
Common Wrong Answers
"Encryption at rest only applies to S3" – Wrong. Many services offer encryption at rest, including EBS, RDS, DynamoDB, and S3. The exam tests this breadth.
"SSE-C keys are stored by AWS" – Wrong. With SSE-C, you provide the key with each request; AWS does not store it. Candidates confuse this with SSE-S3.
"CloudHSM is cheaper than KMS" – Wrong. CloudHSM is typically more expensive because it's dedicated hardware. KMS is pay-per-use.
"You can enable encryption on an existing unencrypted RDS instance" – Wrong. You must create a snapshot, copy it with encryption, and restore a new instance.
Specific Terms and Values
KMS key types: Symmetric (AES-256) and Asymmetric (RSA, ECC).
Default key rotation: Annual for AWS managed keys; optional for customer-managed.
Envelope encryption: Data key encrypted by CMK.
S3 encryption: SSE-S3, SSE-KMS, SSE-C, client-side.
CloudHSM: FIPS 140-2 Level 3, single-tenant.
Tricky Distinctions
KMS vs. CloudHSM: KMS is managed, multi-tenant, and integrated with AWS services. CloudHSM is dedicated, you manage, and it's not integrated with AWS services out-of-the-box.
SSE-S3 vs. SSE-KMS: SSE-S3 uses Amazon-managed keys; SSE-KMS uses KMS keys and provides separate permissions and audit.
Encryption at rest vs. in transit: At rest protects stored data; in transit protects data moving. Some services (like S3) offer both.
Decision Rule
If a question asks about "encryption at rest" for a specific AWS service, recall which encryption options that service supports. For S3, remember the four options. For EBS and RDS, it's KMS. If the question mentions "dedicated HSM" or "full control over keys", choose CloudHSM. If it's about "managed service" or "integration", choose KMS.
Encryption at rest protects data stored on disk; encryption in transit protects data moving over networks.
AWS KMS is a managed service for creating and controlling encryption keys, using envelope encryption.
S3 offers four encryption options: SSE-S3, SSE-KMS, SSE-C, and client-side encryption.
EBS and RDS encryption at rest uses AWS KMS; you must enable encryption at launch or via snapshot copy.
CloudHSM provides dedicated, FIPS 140-2 Level 3 validated HSMs for regulatory compliance.
KMS keys are regional; to use across regions, create multi-Region keys.
SSE-C requires you to provide your own encryption key; AWS does not store it.
These come up on the exam all the time. Here's how to tell them apart.
AWS KMS
Fully managed service
Multi-tenant HSM
Integrated with many AWS services
Pay per key per month and per API call
Automatic key rotation available
AWS CloudHSM
You manage the HSM
Single-tenant, dedicated HSM
Not integrated with AWS services directly
Pay per HSM per hour
Full control over key lifecycle
Mistake
KMS keys are stored in plaintext on disk.
Correct
KMS keys are stored encrypted by the HSM. The key material never leaves the HSM in plaintext. The HSM performs cryptographic operations internally.
Mistake
Enabling encryption on an S3 bucket encrypts all existing objects automatically.
Correct
Bucket-level encryption settings only apply to new objects. Existing objects are not automatically encrypted. You must copy or rewrite them with encryption.
Mistake
SSE-C means AWS manages the keys.
Correct
SSE-C means you provide the encryption key. AWS uses it to encrypt/decrypt but does not store the key. You must supply it for every request.
Mistake
CloudHSM is a managed service like KMS.
Correct
CloudHSM is a dedicated HSM that you manage. You are responsible for patching, backups, and high availability. KMS is fully managed.
Mistake
You can use the same KMS key across all AWS regions.
Correct
KMS keys are regional. To use the same key in multiple regions, you must create a multi-Region key or replicate the key manually.
Encryption at rest protects data when it is stored on physical media, such as SSDs or magnetic disks. AWS services like S3, EBS, and RDS offer server-side encryption to encrypt data before writing it to disk. Encryption in transit protects data as it travels across networks, typically using TLS/SSL. For example, HTTPS encrypts traffic between a client and a web server. Both are essential for a defense-in-depth strategy. On the exam, you may be asked to identify which type of encryption is missing in a scenario.
Envelope encryption is a method where you encrypt data with a data key, and then encrypt that data key with a master key (CMK). When you call KMS Encrypt, KMS generates a data key, encrypts your data locally (or you can use KMS to encrypt small amounts), and then encrypts the data key with the CMK. The encrypted data key is stored alongside the ciphertext. To decrypt, you first decrypt the data key using the CMK, then use the data key to decrypt the data. This allows you to encrypt large amounts of data without sending it all to KMS.
No, you cannot directly enable encryption on an existing unencrypted RDS instance. You must create a snapshot of the instance, copy the snapshot with encryption enabled, and then restore a new encrypted DB instance from that snapshot. The new instance will have encryption at rest. This is a common exam trap: candidates think they can modify the instance directly.
SSE-S3 uses Amazon S3-managed keys. Each object is encrypted with a unique key, and the key itself is encrypted with a master key that rotates regularly. You have no control over the key or audit trail. SSE-KMS uses AWS KMS to manage the encryption key. You can use a customer-managed CMK, which gives you control over key rotation, permissions, and auditing via CloudTrail. SSE-KMS also allows you to use the same key across multiple AWS services. The exam tests this distinction.
Use CloudHSM when you need a dedicated, single-tenant HSM for regulatory compliance (e.g., PCI DSS, FIPS 140-2 Level 3) or when you require full control over key generation and management. CloudHSM is also used when you need to generate keys outside of AWS's control or when you have legacy applications that require direct access to the HSM. For most use cases, KMS is simpler and more cost-effective.
Yes, AWS KMS supports automatic key rotation for symmetric customer-managed CMKs. You can enable automatic annual rotation, which creates new backing key material each year while retaining the old material for decryption of older data. AWS managed keys (e.g., aws/s3) rotate automatically every year. Asymmetric CMKs do not support automatic rotation.
By default, new S3 buckets and objects are not encrypted. However, you can enable default encryption on a bucket so that all new objects are automatically encrypted with SSE-S3, SSE-KMS, or SSE-C. Additionally, starting in 2023, AWS applies SSE-S3 to all new objects uploaded to S3 if you use the AWS Management Console, but programmatic uploads are not encrypted by default unless you explicitly request it.
You've just covered Data Encryption on AWS — now see how well it sticks with free CLF-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?