Skip to main content

Amazon S3 Encryption

Big Idea First: What Are We Protecting?​

When you put a file into Amazon S3, you are storing data such as photos, backups, logs, documents, and application files. You want to ensure that strangers cannot read it, hackers cannot access it, and even AWS employees cannot see it. Only the right people or services should be able to read your data. Encryption is what makes this possible.

What Does “Encryption” Really Mean?​

Encryption means turning readable data (called plaintext) into unreadable data (called ciphertext). To encrypt data, you always need two things: the data itself and an encryption key. Without the key, the data cannot be read.

Important Rule in S3​

Buckets themselves are not encrypted. Objects are encrypted.
An S3 bucket is just a container, but each object (file) inside the bucket is encrypted individually. This means one file can use one encryption method, while another file in the same bucket can use a different method.

Two Big Ways to Encrypt S3 Data​

There are two main approaches to encryption in S3:

  1. Client-side encryption (CSE) — you encrypt the data before uploading
  2. Server-side encryption (SSE) — S3 encrypts the data for you

Client-Side Encryption (CSE) — “You Lock It Before Shipping”​

With client-side encryption, you encrypt the file on your laptop or server before sending it to S3. The encrypted file is then uploaded over HTTPS, and S3 stores only encrypted data. AWS never sees the original plaintext file.

In this model, AWS only sees encrypted data. It does not see your keys or your plaintext. You control the encryption process, the encryption keys, and who can decrypt the data.

The trade-offs are important. You get maximum control, but also maximum responsibility. Your own CPU is used for encryption, and if you lose the encryption key, the data is gone forever.

Use client-side encryption when you need zero trust in the cloud provider.

Server-Side Encryption (SSE) — “You Send It, S3 Locks It”​

With server-side encryption, you upload the file normally. HTTPS protects the data while it is in transit. When the file reaches S3, S3 automatically encrypts it. Encryption is handled by AWS instead of by you.

Three Types of Server-Side Encryption​

This is where many beginners get confused, so each option is broken down clearly below.

SSE-S3 — “AWS Fully Handles Everything” (Default)​

With SSE-S3, Amazon S3 creates and manages the encryption keys for you. Each object gets its own key, keys are rotated automatically, and AES-256 encryption is used.

You cannot see or control the keys, and you cannot audit who decrypted what. If someone has full S3 access, they can both read and decrypt objects.

Use SSE-S3 when you want encryption with zero effort and minimal control.

SSE-C — “You Bring the Key Every Time”​

With SSE-C, you upload the file and provide your encryption key with each request. S3 encrypts the object and then throws away the key. Only a hash of the key is kept for validation. When you want to decrypt the object, you must send the same key again.

This approach is risky. If you lose the key, the data is lost forever. It is hard to manage at scale and is rarely used in real-world systems.

Use SSE-C only if you want S3 to encrypt data but never store your keys.

SSE-KMS — “Best Balance of Control and Safety” ⭐​

SSE-KMS is the most important option to understand. It uses envelope encryption.

Instead of encrypting data directly with a master key, S3 asks AWS KMS for a Data Encryption Key (DEK). KMS returns a temporary plaintext DEK and an encrypted DEK. S3 encrypts the file using the plaintext DEK, stores the encrypted file and the encrypted DEK, and then discards the plaintext DEK.

This approach gives you strong benefits such as key control, logging, auditing, and role separation.

Role Separation (Very Important)​

With SSE-KMS, someone can have permission to manage the S3 bucket but still be unable to decrypt the data unless they also have permission to use the KMS key. This level of separation is not possible with SSE-S3.

CloudTrail Integration​

Every time a KMS key is used to encrypt, decrypt, or re-encrypt data, the action is logged in AWS CloudTrail. This is critical for security monitoring, compliance, and forensic investigations.

Combining Encryption Layers​

You can encrypt data on the client side and then allow S3 to encrypt it again using server-side encryption. This provides defense in depth and multiple layers of protection.

Simple Mental Model (Remember This)​

  • Client-side encryption: You lock it first
  • SSE-S3: AWS locks it for you
  • SSE-C: You hand AWS the key each time
  • SSE-KMS: AWS locks it, but you control the keys

Amazon S3 Bucket Keys — Clear, Structured Notes

First: Why Do S3 Bucket Keys Even Exist?​

Before S3 Bucket Keys existed, the workflow looked like this:

  • Every S3 object encrypted with SSE-KMS
  • Every object required its own Data Encryption Key (DEK)
  • To get each DEK, S3 had to call AWS KMS

This resulted in:

  • Many KMS API calls
  • Higher costs
  • Risk of hitting KMS rate limits

AWS asked a simple question:
“How can we reduce how often S3 talks to KMS without reducing security?”

👉 That question led to S3 Bucket Keys.

Core Rule (Still True)​

  • Each S3 object is encrypted with a unique DEK
  • This does not change when Bucket Keys are enabled

3️⃣ What Happens Without Bucket Keys (Baseline)​

When using SSE-KMS without Bucket Keys:

  1. You upload an object
  2. S3 makes an API call to KMS
  3. KMS generates a DEK
  4. S3 encrypts the object using that DEK

Result:

  • One KMS call per object
  • High cost at scale
  • Possible throttling

4️⃣ KMS Limits (Why This Matters)​

KMS has per-second API limits, depending on:

  • Region
  • Key type

Roughly:

  • ~5,500
  • ~10,000
  • ~50,000 requests per second

If S3 uploads spike:

  • KMS throttling can occur
  • Encryption and uploads can slow down

5️⃣ What S3 Bucket Keys Change (Big Idea)​

Bucket Keys reduce how often S3 must call KMS.

They do NOT:

  • Remove KMS
  • Remove encryption
  • Remove unique DEKs per object

They DO:

  • Cache encryption material inside S3 for a short time

6️⃣ How S3 Bucket Keys Work (Clean Flow)​

When Bucket Keys are enabled:

Step-by-step

  1. S3 calls KMS once
  2. KMS provides a bucket-level key
  3. This key is:
    • Time-limited
    • Stored and used internally by S3

For a short period of time:

  • S3 uses the bucket key
  • Generates unique DEKs for new objects

Each object:

  • Still gets its own DEK
  • Is encrypted individually

📌 Important

  • Bucket keys are not permanent
  • They are rotated automatically
  • Fully managed by S3

7️⃣ What This Gives You (Benefits)​

✅ Massive cost reduction

  • Far fewer KMS API calls
  • Much cheaper at scale

✅ Avoid KMS throttling

  • Ideal for:
    • High-throughput uploads
    • Logging buckets
    • Replication targets

✅ Same security model

  • Still uses KMS
  • Still uses envelope encryption
  • Still uses IAM + KMS key policies

8️⃣ Activation Requirement​

  • ❌ Not enabled by default
  • ✅ Must be explicitly enabled per bucket
  • ❗ Works only with SSE-KMS

9️⃣ CloudTrail Behavior Changes (Important)​

Without Bucket Keys

  • CloudTrail logs:
    • KMS calls per object
    • Encryption context includes object ARN

With Bucket Keys enabled

  • Fewer KMS events
  • Encryption context shows:
    • Bucket ARN, not object ARN

Result

  • Fewer CloudTrail logs
  • Less granular, but still auditable
  • This is expected and by design

🔟 Logging Summary​

With Bucket Keys enabled:

  • ✅ Bucket-level KMS activity is logged
  • ❌ Per-object KMS events are not logged

Object-level access is still visible via:

  • S3 access logs
  • CloudTrail data events (if enabled)

1️⃣1️⃣ Replication Behavior (Real-World Gotcha)​

Bucket Keys:

  • ✅ Work with S3 replication
  • ✅ Maintain encryption from source to destination

Important detail If:

  • Source object is unencrypted
  • Destination bucket uses:
    • SSE-KMS
    • Bucket Keys enabled

Then:

  • Replica object will be encrypted
  • ETag will change

📌 Applications relying on ETags must account for this

1️⃣2️⃣ Same KMS Key Requirement​

Amazon S3 will only share a Bucket Key for objects encrypted with the same KMS key.

Meaning:

  • One bucket key per:
    • Bucket
    • KMS key

If you change the KMS key:

  • A new bucket key is created

1️⃣3️⃣ Policy Change Requirement (Subtle but Critical)​

Before enabling Bucket Keys, you must:

  • Update IAM policies
  • Update KMS key policies

To allow:

  • Bucket ARN as the encryption context
  • Not individual object ARNs

Otherwise:

  • Encryption may fail
  • Access may be denied

1️⃣4️⃣ Amazon S3 ETag (Entity Tag)​

The Amazon S3 ETag (Entity Tag) is a unique identifier assigned to every object stored in S3. It is primarily used for data integrity checks, caching, and conditional operations. The ETag reflects changes to the object’s contents only, not its metadata. This is why operations such as encryption, replication, or re-encryption can cause the ETag to change even when the file itself appears the same to the application.

1️⃣5️⃣ Beginner Mental Model (Read Twice)​

Without Bucket Keys