← Now We Know archive

Security

AWS KMS: matching key control to your audit story

Week of June 29, 2026Topic: AWS Key Management Service (KMS)

This issue covers AWS Key Management Service (KMS), the service behind "the data is encrypted at rest" on nearly every AWS architecture diagram.

Why this matters

Almost every AWS service that stores data (S3, EBS, RDS, DynamoDB, and the rest) can encrypt it with KMS, and most do by default. So for regulated Commonwealth data (CJIS, IRS 1075, tax and court records), the question a security review asks is rarely "is it encrypted?" It is "who controls the key, can you prove it rotates, and is every use of it logged?" Those are key-type questions, not encryption questions, and the answer changes both your cost and your audit story.

The common trap is to assume that "regulated" means "we need CloudHSM." It almost never does. The real fork for audited data is AWS managed keys versus customer managed keys, both of which live in KMS. CloudHSM and external key stores are a further step that only a few specific mandates actually require.

Quick context

• KMS keys come in three levels of control: AWS owned, AWS managed, and customer managed. Control and visibility increase across that line, and so does the work you own.
• KMS uses envelope encryption. It protects a small data key, and that data key protects your data. The KMS key itself never leaves the KMS hardware security module (HSM).
• The KMS HSMs are validated to FIPS 140-3 Level 3, so the "is the module certified" box is checked before you ever pick a key type.
• Every use of an AWS managed or customer managed key is recorded in AWS CloudTrail. That log is what gives you the audit trail.

AWS owned keys

• Controlled entirely by AWS, shared across many accounts, and not visible in your account.
• No log of individual key use, and no charge.
• Use when a service encrypts with them by default and you have no control or audit requirement.

AWS managed keys

• Controlled by AWS but used by you, and they appear in your account named for the service (aws/s3, aws/ebs, aws/rds).
• AWS rotates them automatically once a year, which you cannot adjust.
• Free, and every use shows in CloudTrail.
• Use when you want encryption with zero key administration.

Customer managed keys (CMK)

• Controlled by you. The key policy lets you separate who manages the key from who can use it, which is the separation of duties reviewers look for.
• Rotation on your schedule (90 days to 7 years) or on demand.
• $1 per month per key, and every use is in CloudTrail.
• Use when the data is regulated or audited. For most COPA workloads, this is the right answer.

How envelope encryption works

This is the part that explains both the cost and the performance. KMS does not encrypt your gigabytes directly. Instead:

• Your app or the AWS service asks KMS for a data key (the GenerateDataKey call). KMS returns two copies: one in plaintext, and the same key encrypted under your KMS key.
• The service encrypts your data locally with the plaintext data key, discards the plaintext key from memory, and stores the encrypted data key next to the ciphertext.
• To read the data back, the service sends the encrypted data key to KMS, gets the plaintext key, and decrypts locally.

The point: KMS only ever encrypts the small data key, not your bulk data. That is why a single KMS key can protect petabytes without becoming a bottleneck, and why "every use in CloudTrail" means every data-key request, not every byte.

Key control tiers: who holds the key material

If a requirement does push you past a standard customer managed key, the next question is who physically holds the key material. There are four tiers, and cost and operational burden climb at each step.

• Tier 1, KMS key with AWS key material. AWS generates and stores the key material in the multi-tenant KMS HSM (FIPS 140-3 Level 3). Lowest cost, easiest, and it fits most workloads, including most regulated ones.
• Tier 2, imported key material (BYOK). You generate the key material yourself and import it, so you control its origin and can delete it on demand. In exchange, you own its durability.
• Tier 3, CloudHSM custom key store. Single-tenant HSMs that you run, still FIPS 140-3 Level 3. Use only when a dedicated HSM is explicitly mandated.
• Tier 4, external key store (XKS). The key material stays in your own HSM outside AWS, and KMS reaches it through a proxy. You own its availability, so an outage there stops decryption. Use only when keys may never reside in AWS.

Most customers, including regulated ones, are well served by tier 1 with a customer managed key.

What changed recently (worth knowing)

• Flexible automatic rotation (April 2024). Customer managed key rotation used to be a fixed once-a-year setting. You can now set the period anywhere from 90 days to 7 years, rotate on demand, and view the full rotation history of a key. This is what lets you match a key to a specific compliance rotation mandate instead of the default.
• On-demand rotation for imported keys (June 2025). BYOK (Tier 2) keys could not be rotated in place before. You can now rotate the cryptographic material of an imported key without changing its key ARN, so nothing that references the key has to change. This closes a real gap for teams that must control key origin and still rotate on a schedule.

When not to use it / tradeoffs

• Do not reach for CloudHSM or XKS by default. They add real cost and operational ownership (you run the cluster, or you own the external key manager's availability), and an XKS outage means you cannot decrypt. Use them only when a specific mandate requires it.
• Customer managed keys are not free. At $1 per month per key, a key-per-resource sprawl adds up. Group keys by blast radius and data classification rather than minting one for everything.
• A KMS key is regional. If you need the same key in another Region for DR or failover, plan a multi-Region key up front, because you cannot convert a single-Region key later.

AWS references

• AWS KMS concepts (key types, envelope encryption, data keys) - docs.aws.amazon.com/kms/latest/developerguide/concepts.html
• Rotating AWS KMS keys (configurable period, on demand, history) - docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html
• AWS KMS more flexible automatic key rotation (What's New, April 2024) - aws.amazon.com/about-aws/whats-new/2024/04/aws-kms-automatic-key-rotation/
• On-demand key rotation for imported keys (What's New, June 2025) - aws.amazon.com/about-aws/whats-new/2025/06/aws-kms-on-demand-key-rotation-imported-keys/
• Custom key stores (CloudHSM and external key stores) - docs.aws.amazon.com/kms/latest/developerguide/custom-key-store-overview.html
• AWS KMS pricing - aws.amazon.com/kms/pricing/
• Well-Architected, Security Pillar (protecting data at rest) - docs.aws.amazon.com/wellarchitected/latest/security-pillar/protecting-data-at-rest.html

Want to go hands-on with AWS? See our upcoming workshops.