What is AWS KMS? A plain-English explainer

Why key management is the hard part of encryption

Our what-is-encryption-in-the-cloud explainer covers the basic idea of encryption: converting readable data into unreadable ciphertext using a key, so that only someone holding the right key can turn it back into something usable. The encryption algorithm itself is a solved, well-tested problem. What is genuinely difficult is everything around it — where the key lives, who can use it, how it is rotated, what happens if it needs to be revoked, and how you prove, after the fact, exactly who used it and when.

A key stored carelessly undermines the encryption built on top of it entirely — encrypted data protected by a poorly guarded key is not meaningfully protected at all. That is the gap KMS is built to close.

What AWS KMS actually does

KMS is a central place to create and manage encryption keys, and it integrates directly with most other AWS services so that encrypting data at rest becomes a configuration choice rather than something you build yourself. Storage, database and other services can encrypt what they hold using a key that lives in KMS, without that service ever needing to implement its own key storage.

Because KMS sits centrally, it also gives a single place to see how keys are being used — which is valuable for security review and for demonstrating compliance, since the audit trail of key usage is concentrated in one service rather than scattered across every service that happens to encrypt something.

Customer-managed vs AWS-managed keys

KMS distinguishes, conceptually, between keys AWS manages on your behalf and keys you manage yourself. AWS-managed keys are created and largely administered automatically by AWS for use with a particular service, requiring little to no hands-on configuration. Customer-managed keys are ones you create and control directly — you decide the access policy, the rotation approach, and who else can use them.

The trade-off is the usual one between convenience and control: AWS-managed keys are simpler and require no upkeep, while customer-managed keys give you finer-grained say over exactly who can use a key and how, which some compliance requirements or security postures call for. Neither is “better” in the abstract — the right choice depends on how much control a given workload genuinely needs.

Common uses

Typical reasons teams reach for KMS include encrypting data stored in managed databases and storage services, encrypting backups, protecting application secrets alongside other secrets tooling, and satisfying compliance requirements that call for demonstrable control over encryption keys rather than just “data is encrypted somewhere”.

The cross-cloud picture, and pricing model

AWS KMS is broadly the AWS counterpart to Azure Key Vault and Google Cloud KMS — all three are the managed key-management service each major cloud provider offers, playing the same central role of creating and controlling encryption keys used elsewhere on the platform. Azure Key Vault additionally bundles in secrets and certificate storage, but the core key-management job is the same across all three.

Like most managed AWS services, KMS follows a consumption-based pricing model — you pay for what you use rather than provisioning fixed capacity up front. Specific rates belong on AWS’s own pricing pages, not in a concept explainer.

Where KMS appears in certification study

Encryption and key management are foundational security topics across AWS certifications, and KMS is where that gets tested most directly on Security Specialty — knowing when to reach for a customer-managed key versus an AWS-managed one, and how KMS integrates with other services, is core content there. It also appears at a lighter, conceptual level in broader architecture-focused study.

This article stops at the concept level — the exam depth on key policies, grants and rotation belongs in the syllabus itself, which our /revision study library covers lesson by lesson.