Encryption on AWS: KMS keys, envelope encryption and key policies
In short: AWS Key Management Service (KMS) creates and guards keys in hardware security modules and uses them to protect data keys through envelope encryption. Customer managed keys let you control key policies, rotation and auditing, while TLS protects data in transit.
Encryption at rest and in transit
Encryption at rest protects stored data if disks, backups or snapshots are copied. Encryption in transit protects data moving over networks. On AWS most services encrypt at rest by default, and almost every API endpoint uses TLS. The security question is really about who controls the keys and who can use them. If you need a refresher on algorithms, see cryptography basics.
How KMS works
AWS Key Management Service (KMS) stores keys inside hardware security modules (HSMs) validated under FIPS 140-3. The key material never leaves KMS in plaintext. Because KMS can only encrypt small amounts of data directly (up to 4 KB), services use envelope encryption.
To read the data later, the service sends the wrapped data key to KMS, KMS checks permissions and returns the plaintext data key, and the service decrypts locally. Every one of those KMS calls is logged in CloudTrail, which gives you an audit trail of who used which key.
Customer managed keys are the ones to use for sensitive data, because you write the key policy, can disable the key in an emergency, and see every use.
Key policies, grants and rotation
- Every KMS key has a key policy. Unlike most AWS resources, IAM policies alone cannot grant access unless the key policy allows the account to delegate to IAM.
- Separate duties: key administrators manage the key but cannot use it to decrypt; key users can encrypt and decrypt but cannot change the policy.
- Grants give temporary, narrow permissions, often used by services such as EBS on your behalf.
- Enable automatic rotation for customer managed symmetric keys. Rotation creates new key material, while old material is kept to decrypt older data, so nothing needs re-encrypting.
- Key deletion has a mandatory waiting period of 7 to 30 days. Deleting a key makes all data encrypted with it unrecoverable, so prefer disabling first.
aws kms create-key --description "App data key" --key-usage ENCRYPT_DECRYPT
aws kms enable-key-rotation --key-id <key-id>
aws kms create-alias --alias-name alias/app-data --target-key-id <key-id>
Related services and common mistakes
| Service | Purpose |
|---|---|
| AWS CloudHSM | Dedicated single-tenant HSMs when you need full control of the hardware |
| AWS Certificate Manager (ACM) | Free public TLS certificates for load balancers and CloudFront, with automatic renewal |
| AWS Secrets Manager | Stores and rotates passwords and API keys, encrypted with KMS |
Common mistakes:
- Key policies that let
"Principal": "*"use the key without conditions. - Using one key for everything, so a single policy mistake exposes all data.
- Forgetting that sharing an encrypted snapshot also needs the key to be shared.
- Scheduling a key for deletion without checking what still uses it.
Practice
Why does KMS use envelope encryption instead of encrypting all data directly?
What happens to old data when automatic key rotation runs?
Why separate key administrators from key users?
Key takeaways
- KMS keys live in FIPS-validated HSMs and never leave in plaintext.
- Envelope encryption: data keys protect data, KMS keys protect data keys.
- Customer managed keys give you policy, rotation and audit control.
- Key policies are the primary control; separate admins from users.
- Deleting a key destroys access to its data; disable first.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.