Free tech learning for everyone, from basics to pro

AWS SecurityCloud SecurityIntermediate

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.

Envelope encryptionKMS keynever leavesKMSData keygenerated perobjectEncrypt datawith plaintextkeyStoredata pluswrapped keyDiscardplaintext key
Figure 1. Envelope encryption: a KMS key protects data keys, and data keys protect the data.

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.

Types of KMS keyKMS keyswho controls themAWS ownedinvisible, nocontrolAWS managedaws/service, viewonlyCustomer managedyour policy,rotationImported / externalyour key material
Figure 2. The key types range from fully managed by AWS to fully controlled by you.

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

ServicePurpose
AWS CloudHSMDedicated 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 ManagerStores 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?
KMS only encrypts small payloads and every call has latency; data keys encrypt bulk data locally while the KMS key protects the data keys.
What happens to old data when automatic key rotation runs?
Nothing needs to change; KMS keeps the old key material to decrypt it and uses the new material for new encryption.
Why separate key administrators from key users?
So no single person can both change who has access and decrypt the data, reducing insider risk.

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.
Tracks your learning on this device only. See your progress on the learning paths.

About the author

Mohamed Fayas

Founder of FM TecHub. CCNA certified, with a BTEC HND in Network Engineering, and BEng (Hons) in Computer Networking and Cloud Security. He writes practical, plain-English guides on networking, security and cloud.

More about the author

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.

Stay up to date by email

New notes, tools and security news from FM TecHub, explained simply. Free.

We only use your email to send these updates. See our privacy policy.