Modern cloud applications handle vast amounts of sensitive data: user credentials, financial records, health information, and more. Encrypting that data is no longer optional, but managing encryption keys at scale is notoriously difficult to get right. AWS Key Management Service (KMS) exists to solve exactly that problem.
What Is AWS KMS?
AWS Key Management Service (KMS) is a fully managed service that makes it easy to create, control, and rotate the cryptographic keys used to encrypt your data. Rather than building and maintaining your own key management infrastructure (which requires deep cryptographic expertise, hardware security modules, and strict access controls), you delegate that responsibility to AWS, while retaining full authority over who can use which keys and for what purpose.
KMS is deeply integrated into the AWS ecosystem. Services like S3, RDS, DynamoDB, EBS, Lambda, and Secrets Manager can all encrypt data using KMS keys with just a few clicks or lines of configuration. At the same time, KMS exposes APIs that allow you to use the same key infrastructure in your own application code.
What Does AWS KMS Provide?
At its core, KMS gives you a secure, auditable, and scalable foundation for encryption. Here is what that looks like in practice:
Centralized key management. All your cryptographic keys live in one place, with fine-grained IAM policies and key policies controlling who can use, manage, or delete them.
Automatic key rotation. KMS can automatically rotate symmetric keys every year, generating new key material while retaining the ability to decrypt data encrypted with older versions.
Audit trail via CloudTrail. Every API call is logged in AWS CloudTrail, including every encrypt, decrypt, generate, and describe operation. This gives you a complete, tamper-resistant record of key usage, which is invaluable for compliance and incident response.
Hardware-backed security. KMS keys never leave AWS’s FIPS 140–2 validated hardware security modules (HSMs) in plaintext. All cryptographic operations happen inside those HSMs.
Multi-Region keys. For disaster recovery or low-latency use cases, KMS supports replicating keys across AWS regions while maintaining the same key ID and policy semantics.
The Cryptographic Algorithms Behind KMS
KMS supports several industry-standard algorithms, each suited to different use cases. Let’s break each one down with a concrete example so the difference sticks.
AES-256: The Lock-and-Key Model
AES (Advanced Encryption Standard) with a 256-bit key is the workhorse of bulk data encryption. The key insight: the same key locks and unlocks the data. This is called symmetric encryption.
How to think about it: Imagine a safe with a combination lock. You spin the combination to lock it (encrypt), and the exact same combination opens it (decrypt). Anyone who knows the combination can do both, so you must keep that combination private.
A concrete example: You’re building a healthcare application storing patient records in DynamoDB. When a record comes in:
Nobody reading your database table sees anything meaningful. The only way to reverse it is with the identical key. AES-256 is extremely fast. A modern CPU can encrypt gigabytes per second, which is why it’s the default choice for data at rest.
When you create a standard KMS key and use it to encrypt data via the GenerateDataKey API, you're using AES-256 under the hood.
RSA: The Padlock Without a Key
RSA uses two mathematically linked keys: a public key and a private key. Anything encrypted with the public key can only be decrypted with the private key. This is called asymmetric encryption.
How to think about it: Picture an open padlock that you hand out freely. Anyone can snap it shut over a message (encrypt with the public key). But only you can open it, because only you hold the private key. You can distribute thousands of padlocks without ever giving anyone the ability to peek inside.
A concrete example: You have a partner company that needs to send you sensitive API credentials securely over email:
RSA is also the foundation of digital signatures, where you reverse the flow. You sign a document with your private key, and anyone with your public key can verify it was really you. KMS supports RSA key pairs at 2048, 3072, and 4096 bits.
RSA’s slowness is not a bug or a poor implementation. It is a direct consequence of the mathematics that make it secure. Every RSA operation involves modular exponentiation on enormous numbers: your message is raised to a power (often 65537) and divided by a number that is typically 2048 or 4096 bits long. That arithmetic is inherently expensive. On a modern CPU, RSA-2048 can encrypt only a few hundred kilobytes per second. AES-256, by contrast, uses simple bitwise operations (substitutions, shifts, XORs) that modern CPUs execute in dedicated silicon. AES can encrypt several gigabytes per second on the same hardware. The gap is not marginal; it is roughly four to five orders of magnitude.
There is also a hard size ceiling. RSA cannot encrypt a payload larger than its key size minus some padding overhead. With a 2048-bit key, the maximum plaintext you can encrypt in one operation is around 214 bytes — just enough for a short password or a small token, nowhere near a database row, a file, or an API response body.
So RSA alone falls apart at scale. But the question cuts the other way too: why not just use AES everywhere and skip RSA entirely?
The answer is the key distribution problem. AES requires that both sides, the sender and the receiver, already possess the same secret key. If you want to send encrypted data to someone you have never securely communicated with before, how do you get the AES key to them without it being intercepted? You cannot encrypt the key with itself. You cannot send it in plaintext. In a closed system where you control both ends, AES is fine. But the moment a second party, a partner service, or a future version of your own infrastructure needs to read the data, you have a problem that AES cannot solve alone.
Envelope encryption exists precisely to resolve this tension. It is the architectural answer to the question: how do you get the speed of AES and the key-management power of asymmetric cryptography at the same time?
AES handles the data because it is fast, it scales to any payload size, and it is the right tool for the job. The master key (whether RSA-based or an AES key locked inside a KMS HSM) handles the key, protecting the small, fixed-size DEK rather than the data itself. The DEK is the bridge between the two worlds: generated fresh for each record, used once, then either discarded or stored in encrypted form.
What envelope encryption solves, concretely, is this: you never have to choose between security and performance. You never have to expose your master key to application servers. You never have to call a remote HSM for every database row you read. And if a DEK is ever compromised, only the data encrypted under that one key is at risk. Your master key and every other record remain safe. Re-encryption is scoped, not catastrophic.
Envelope Encryption: The Pattern That Ties It Together
Envelope encryption is the architectural pattern that ties AES and the master key together. It solves a real problem: your master key lives inside an HSM and is slow to invoke for bulk operations. You also don’t want to call KMS on every single database read.
How to think about it: You have an important letter. You put it in an inner envelope, seal it, then lock that inner envelope inside a safe. To read the letter, you first open the safe (decrypt the key), then open the inner envelope. The letter itself is protected by the envelope; the envelope’s integrity is guaranteed by the safe.
KMS is called exactly once. You ask it to GenerateDataKey, and it hands back two things at the same time: a plaintext DEK (raw AES-256 key material, alive only in memory) and an encrypted DEK (that same key material wrapped by the master key, safe to persist anywhere). Your application uses the plaintext DEK to encrypt the data locally with AES-256, with no round-trip to KMS for every byte. The moment encryption finishes, the plaintext DEK is zeroed out of memory. It is never written to disk, never logged, never cached.
What lands in the database are two artifacts: the encrypted data blob and the encrypted DEK sitting next to it. The master key never touched your data directly, and the plaintext DEK no longer exists anywhere. The only path back to readable data is through KMS, and that means through your IAM policies, your key policy, and your CloudTrail log.
The Master Key: The Root of Trust
In KMS terminology, the master key is called a KMS Key (previously called a Customer Master Key, or CMK). It sits at the top of the key hierarchy, and everything else gets encrypted under it.
Master keys never leave the KMS HSM infrastructure in plaintext. You cannot download them, export them, or use them directly in your application code to encrypt raw bytes of arbitrary size. Instead, you interact with a master key indirectly: you call KMS APIs, and the cryptographic operations happen inside the HSM on your behalf.
A master key is used:
- To generate data keys via the GenerateDataKey API, which returns both a plaintext data key and a copy of that data key encrypted under the master key.
- To decrypt data keys via the Decrypt API, so your application can recover the plaintext data key when it needs to decrypt data.
- To directly encrypt small payloads (up to 4 KB) via the Encrypt API, useful for things like configuration secrets or short tokens.
- For digital signing and verification when using asymmetric RSA or ECC keys.
Access to a master key is governed by a combination of IAM policies and the key’s own resource-based policy. This dual-layer control means that even an AWS account root user cannot use a key if the key policy explicitly denies it.
Data Encryption Keys (DEKs): The Working Keys
A Data Encryption Key (DEK) is the key that actually encrypts your data. It is a symmetric AES-256 key generated by KMS on demand through the GenerateDataKey API call. This call returns two things simultaneously:
- The plaintext DEK: the raw key material, held in memory only for as long as it takes to perform the encryption operation. It is never written to disk.
- The encrypted DEK: the same key material, but encrypted under your master key. This ciphertext is safe to store anywhere because, without access to the master key, it is computationally useless.
The plaintext DEK is ephemeral. Use it, encrypt your data, then discard it immediately from memory. The encrypted DEK is a durable artifact that you keep alongside your encrypted data.
What Gets Stored, and How Decryption Works
This is where the design comes together elegantly.
What you store in the database:
You store two things: the ciphertext of your data (encrypted with the plaintext DEK) and the encrypted DEK itself. The plaintext DEK is never persisted anywhere: not in the database, not in logs, not in object storage.
A typical record looks like this:
{
"user_id": "u_12345",
"encrypted_payload": "<base64-encoded ciphertext>",
"encrypted_dek": "<base64-encoded KMS-encrypted data key>"
}How decryption works:
When your application needs to read that data, it follows these steps:
- Retrieve the record from the database, including the encrypted payload and the encrypted DEK.
- Call the KMS Decrypt API, passing the encrypted DEK. KMS uses the master key to decrypt it and returns the plaintext DEK, held only in memory.
- Use the plaintext DEK to decrypt the payload locally using AES-256.
- Discard the plaintext DEK from memory immediately after use.
The master key’s role in decryption is indirect but essential: it acts as the gatekeeper. KMS will only honor the Decrypt call if the caller has the appropriate IAM and key policy permissions, which means your encryption scheme inherits all the access controls, audit logging, and key rotation benefits of KMS without requiring KMS to be in the hot path of every single data read.
If the master key is deleted or disabled, the encrypted DEK becomes permanently unreadable, and the data is effectively unrecoverable. This makes key lifecycle management a serious operational concern. On the flip side, it also means that revoking access to data is as simple and immediate as disabling a key policy.
Final Overview
AWS KMS is not just a key store. It is a complete key governance system. By combining a hardware-backed master key with the envelope encryption pattern, you get a model where sensitive data can be encrypted efficiently at scale, access can be audited and revoked with precision, and the most sensitive material (the master key) never touches your application servers. Understanding the interplay between master keys, plaintext DEKs, and encrypted DEKs is the foundation for building any serious encryption strategy on AWS.
Securing Your Data with AWS Key Management Service (KMS) was originally published in Level Up Coding on Medium, where people are continuing the conversation by highlighting and responding to this story.
