Chykalophia Docs

What AWS Key Management Service does, how key policies control access, why rotation matters, and why deleting a key is irreversible.

AWS Key Management Service (KMS) creates and controls the encryption keys that protect data at rest — files in S3, database volumes, and application-level fields such as personal or health information. Its real value is not the encryption itself but the auditable control over who can decrypt.

Quick summary

A KMS key is created and used inside AWS KMS, and never leaves it unencrypted. Applications ask KMS to encrypt or decrypt on their behalf, and every request is logged. Access is governed by the key policy attached to the key, which is separate from ordinary IAM permissions. Deleting a key permanently destroys everything encrypted with it — treat deletion as a last resort.

Why use KMS rather than just encrypting things yourself

The key material stays inside AWS KMS and never leaves it unencrypted, so it can't be copied off a compromised server.
Every use is logged in CloudTrail — you can answer "who decrypted this, and when".
Access can be revoked centrally. Removing decrypt permission renders the data unreadable to that identity immediately.
It satisfies auditors. Managed key control is a common requirement in regulated work — see HIPAA basics.

Key policies

This is the part that surprises people: every KMS key has exactly one policy document of its own, and it comes first. Unless the key policy allows it, an IAM policy granting access to that key has no effect. The default key policy hands control to the AWS account, which is what lets ordinary IAM policies work as usual — edit that out, and IAM permissions alone won't get anyone in.

Never leave a key without an administrator

AWS gives the default key policy a statement granting the account itself control, precisely so the key can't be orphaned. If you replace that with a policy naming a single person and then delete that person, the key becomes unmanageable and you have to contact AWS Support to regain access. Always keep at least one durable administrative principal in the policy, and change key policies deliberately.

Envelope encryption

KMS keys are not used to encrypt large files directly. Instead:

A data key is requested. The application asks KMS for a data key.

KMS returns it twice — once in plaintext, once encrypted under the KMS key.

The file is encrypted. The application encrypts the file with the plaintext data key, then discards it from memory.

The encrypted data key is stored alongside the file.

Decryption unwraps the key. To decrypt, the application asks KMS to unwrap the data key — which is the moment access control and logging apply.

This is why access to the KMS key is equivalent to access to the data.

Rotation

KMS can rotate a customer-managed key's material automatically. The default rotation period is 365 days, you can set your own, and you can also rotate on demand. AWS keeps every earlier version of the material and picks the right one when decrypting, so previously encrypted data stays readable and nothing needs re-encrypting.

Rotation limits how much data is protected by any single piece of key material. AWS is explicit that it has no effect on the data the key protects: it does not help if an identity's permission to use the key has leaked, and it won't undo a compromised data key. Both of those need the policy changed instead.

Deletion is the real danger

Scheduling key deletion destroys data

Deleting a KMS key makes every object encrypted under it permanently unreadable — including your backups. AWS enforces a waiting period of 7 to 30 days, 30 by default, precisely because this is unrecoverable, and you can cancel the deletion at any point before it ends. Before scheduling deletion, confirm nothing still references the key. Disabling a key is the reversible alternative, and is almost always the right first step.

Common questions

Do we need KMS, or is default encryption enough?

Default S3 encryption is fine for most content. Reach for a customer-managed KMS key when you need to prove who can decrypt, need to revoke access independently of storage permissions, or are handling regulated data such as health or financial records.

What does KMS cost?

A monthly charge per customer-managed key, plus a charge per request once you pass the monthly request allowance. Rotating a key adds to the monthly charge for the first couple of rotations. Requests dominate at scale — an application that calls KMS on every read rather than caching data keys appropriately can generate surprising volume. Check AWS's KMS pricing page for current rates.

Can you decrypt our data?

Only if the key policy grants it, and every such request is recorded in CloudTrail. If you'd rather no external party can decrypt production data, the key policy can exclude us entirely while still letting us deploy and operate the application.

What happens to encrypted data if we leave AWS?

Decrypt it first. Data encrypted with a KMS key cannot be read outside AWS, because the key material never leaves AWS KMS unencrypted. Any migration plan must include decrypting and re-encrypting under the new system while the key still exists.

Need a hand?

If you're stuck, email support@chykalophia.com and we'll help. Include your website address and a screenshot if you can.

AWS KMS & encryption keys