AWS KMS and Encryption Basics: At Rest, In Transit, and Key Management

AWS Key Management Service (KMS) is the AWS service that creates, stores, and controls the cryptographic keys used to encrypt your data. Encryption at rest protects data sitting on disk (an S3 object, an EBS volume, a database), while encryption in transit protects data moving across a network, typically with Transport Layer Security (TLS). For the CLF-C02 exam you need to know what each term means, that KMS is the default answer for key management, and when the dedicated-hardware alternative, AWS CloudHSM, is the better fit.

The two states of data: at rest and in transit

Encryption scrambles data with a key so that anyone without the key sees only ciphertext. Where the data is when you encrypt it determines which of two categories applies.

Encryption at rest covers data stored on physical media. In AWS terms: objects in Amazon S3, Amazon EBS volumes and snapshots, Amazon RDS databases, Amazon DynamoDB tables, and so on. If someone somehow obtained the underlying storage, encrypted-at-rest data would be unreadable without the key. Most AWS storage and database services offer at-rest encryption as a checkbox (or enable it by default), with KMS supplying the keys behind the scenes.

Encryption in transit covers data moving between two points: a browser talking to your application, your application talking to a database, one AWS service talking to another. The standard mechanism is TLS, the protocol behind HTTPS. AWS Certificate Manager (ACM) provisions and renews the public TLS certificates that make HTTPS work on services like Elastic Load Balancing and Amazon CloudFront, and public certificates issued through ACM carry no charge.

A properly secured workload uses both. Encrypting a database at rest does nothing for credentials flying across the network in plaintext, and HTTPS does nothing for an unencrypted disk. Exam questions sometimes probe exactly this: which category a given control belongs to.

What AWS KMS does

Managing keys yourself is hard: you have to generate them securely, store them somewhere safer than the data they protect, control who can use them, rotate them, and log every use. KMS turns all of that into a managed service.

The core things to know:

• Centralized key management. You create and manage KMS keys in one place, and dozens of AWS services (S3, EBS, RDS, DynamoDB, Lambda, and many more) integrate with KMS directly. Ticking “encrypt” on a resource usually means “use a KMS key.”
• Keys never leave KMS unencrypted. Your applications ask KMS to encrypt, decrypt, or generate data keys. The key material itself stays inside validated hardware under AWS’s control, which is what makes the model safe.
• Access control through policies. Key policies and AWS Identity and Access Management (IAM) policies define exactly which users, roles, and services may use each key. Losing permission to a key means losing the ability to decrypt the data, so key access is a real security boundary, not a formality.
• Auditability. Every use of a KMS key is recorded in AWS CloudTrail, so you can answer “who decrypted this, and when?” This pairing of KMS and CloudTrail shows up in compliance conversations constantly.
• Rotation. KMS can automatically rotate customer managed keys on a schedule, replacing key material without you re-encrypting your data manually.

KMS keys come in three ownership flavors, and Cloud Practitioner questions occasionally touch the distinction. Customer managed keys are keys you create, whose policies and rotation you control. AWS managed keys are created and managed by AWS on your behalf for use with a specific service. AWS owned keys belong to AWS entirely and are used across many customer accounts; you never see or manage them. The rule of thumb: more control means more responsibility, and that trade is yours to make.

Under the hood, KMS uses envelope encryption: your data is encrypted with a data key, and that data key is itself encrypted with a KMS key. At Cloud Practitioner depth you only need the concept, not the mechanics: KMS protects the keys that protect your data.

KMS vs CloudHSM

AWS CloudHSM provides dedicated hardware security modules (HSMs): physical, tamper-resistant devices for storing keys and performing cryptographic operations. The distinction with KMS is the classic A-vs-B in this topic area.

	AWS KMS	AWS CloudHSM
Tenancy	Multi-tenant managed service (shared, validated hardware)	Single-tenant, dedicated hardware devices
Who controls the keys	Shared model: AWS operates the service, you control key use via policies	You exclusively; AWS has no access to your keys
AWS service integration	Deep, native integration with most AWS services	Minimal direct integration; you connect via your applications
Management burden	Lowest: fully managed	Higher: you manage the HSM cluster and its users
Typical driver	Standard encryption needs across AWS workloads	Strict compliance or contractual mandates requiring dedicated, customer-controlled hardware

The exam-relevant takeaway: KMS is the answer for almost everything, and CloudHSM is the answer when the scenario stresses dedicated hardware, single-tenant devices, or a regulatory requirement that the customer alone controls the key material.

Encryption responsibilities also map cleanly onto the AWS shared responsibility model: AWS secures the encryption infrastructure, but deciding what to encrypt, enabling it, and governing key access is customer-side work, “security in the cloud.” One neighboring service to keep separate: AWS Secrets Manager stores and rotates secrets such as database passwords and API keys. Secrets Manager holds credentials; KMS holds encryption keys. A question about rotating a database password wants Secrets Manager, not KMS.

How the CLF-C02 exam tests this

• A scenario asks which service creates and manages encryption keys used across AWS services. The answer is KMS. Distractors typically include CloudHSM, Secrets Manager, and ACM.
• A scenario emphasizes a compliance requirement for single-tenant, dedicated hardware where only the customer controls the keys. The answer is CloudHSM. The words “dedicated” and “hardware security module” are the tell.
• A scenario asks how to protect data moving between clients and an application, or mentions TLS/SSL certificates. That is encryption in transit, and the certificate service is AWS Certificate Manager.
• A scenario asks how to prove or review who used an encryption key. The answer combines KMS with CloudTrail logging.
• A scenario about storing and automatically rotating database credentials points to Secrets Manager. Do not reach for KMS just because the word “secure” appears.

Quick reference

• Encryption at rest protects stored data; encryption in transit (TLS/HTTPS) protects data crossing a network. Secure workloads need both.
• AWS KMS is the managed service for creating, controlling, and auditing encryption keys, integrated with most AWS services.
• Key types: customer managed (you control), AWS managed (service-specific, AWS-operated), AWS owned (invisible to you).
• Every KMS key use is logged in CloudTrail; key policies plus IAM control who can use each key.
• AWS CloudHSM offers single-tenant, dedicated hardware security modules when compliance demands exclusive customer control.
• AWS Certificate Manager provisions and renews TLS certificates; public ones are free.
• AWS Secrets Manager rotates credentials like database passwords; it is not a key-management service.