Why you should care about KMS and not pretend encryption is automatic

If you store data on EC2 or S3 and you are not using AWS KMS you are either a brave hero or someone who enjoys explaining to auditors what went wrong. This guide walks through creating and choosing keys, attaching policies, encrypting and decrypting with the AWS CLI, and testing rotation and audit logging. It keeps technical details intact and doles out sarcasm as needed.

Create or pick the right KMS key

Go to the AWS console or use the AWS CLI to create a key. Pick symmetric for standard file encryption where speed and simplicity matter. Pick asymmetric when you actually need public key operations like signing or encryption without sharing the private key.

# Symmetric example
aws kms create-key --description "Files for project X" --key-usage ENCRYPT_DECRYPT

# Asymmetric example for signing or public key ops
aws kms create-key --description "Signing key" --key-usage SIGN_VERIFY --customer-master-key-spec RSA_2048

Name the key with a clear alias so future you does not cry during incident response.

Set key policy and grant IAM permissions

Attach a key policy that lets the principals you trust use the key. Then ensure the EC2 instance role or IAM user has kms:Encrypt and kms:Decrypt plus any S3 permissions you will need. If you forget this step the CLI will politely fail and you will stare at the screen.

• Allow EC2 instance role to call KMS and S3 as appropriate
• Consider using grants for temporary, limited access
• Test with the least privilege you think might work then tighten it

Encrypt files on EC2 with the AWS CLI

You have two realistic options. Server side encryption with S3 if you trust Amazon to handle keys at rest. Or client side encryption when you want control over the ciphertext on disk.

Client side symmetric encryption example

# Encrypt a file and save the ciphertext
aws kms encrypt --key-id alias/YourKey --plaintext fileb://example.txt --query CiphertextBlob --output text | base64 --decode > example.txt.encrypted

Explanation in human speak. KMS returns a base64 encoded CiphertextBlob. The pipeline decodes it and saves a binary ciphertext file that you can safely store in S3 or locally.

Use SSE KMS for S3 or client side data keys if you are picky

If you want Amazon to do the heavy lifting use S3 server side encryption with KMS. Upload like this and the object will be stored encrypted with your KMS key.

# SSE KMS upload to S3
aws s3 cp example.txt s3://your-bucket/ --sse aws:kms --sse-kms-key-id alias/YourKey

If you need more control then use KMS to generate a data key and do local encryption. That looks like calling GenerateDataKey, using the returned plaintext to encrypt locally, and storing the encrypted data key with the ciphertext.

Decrypt files on EC2 or when retrieving from S3

If you used client side encryption call KMS decrypt and base64 decode to get the plaintext back. If you used SSE KMS just download the object with the role that has permissions and Amazon will decrypt it for you transparently.

# Client side decrypt
aws kms decrypt --ciphertext-blob fileb://example.txt.encrypted --query Plaintext --output text | base64 --decode > example.txt.recovered

# Download object encrypted with SSE KMS
aws s3 cp s3://your-bucket/example.txt ./example.txt

Yes it really is that simple when you have the right permissions. No you do not get a medal for copying files with the AWS CLI.

Test key rotation and audit logging

Enable automatic rotation for symmetric KMS keys to keep long lived keys from getting bored and obsolete. Manually rotate asymmetric keys only if your use case requires it. Then verify CloudTrail shows Encrypt and Decrypt calls so audits are less terrifying.

• Enable key rotation for symmetric keys in the console or via the API
• Use CloudTrail to search for kms Encrypt and kms Decrypt events
• Confirm the EC2 role can decrypt and S3 objects are served decrypted when expected

Quick checklist before you walk away

• Choose symmetric vs asymmetric correctly based on your workload
• Set key policies and IAM roles so services can actually use the key
• Decide between SSE KMS and client side encryption for control tradeoffs
• Test decrypt and verify CloudTrail logs show activity
• Enable rotation and monitor audit logs so your future self is smug

There you go. You now have a practical and slightly snarky guide to KMS on EC2 and S3 that will keep your secrets secure and your auditors calmer. If anything fails consult the CLI error messages they are blunt but honest.