S3 Encryption

Overview

You can encrypt objects in S3 buckets using one of four methods. Three are server-side encryption (SSE) — where AWS performs the encryption after receiving the object — and one is client-side encryption — where you encrypt before uploading. At the exam, it's critical to understand which method fits which situation, because the exam will present you with a scenario and expect you to pick the right one.

Here's the big picture before we dive deep:

SSE-S3 (Amazon S3-Managed Keys)

This is the simplest and default encryption method. The encryption key is handled, managed, and owned by AWS. You never have access to this key, and you don't need to worry about key rotation or management — AWS does it all behind the scenes.

Key characteristics:

• Encryption type: AES-256
• Enabled by default for all new buckets and new objects (since January 5, 2023)
• To explicitly request it, set the header: "x-amz-server-side-encryption": "AES256"
• No additional cost — included with S3 storage pricing
• No audit trail on key usage (unlike SSE-KMS)

How SSE-S3 Works

┌──────────────────────────────────────────────────────────────┐
│                      SSE-S3 ENCRYPTION FLOW                   │
│                                                               │
│  ┌──────────┐                          ┌──────────────────┐  │
│  │          │   1. Upload object        │                  │  │
│  │   User   │ ──────────────────────▶   │   Amazon S3      │  │
│  │          │   + Header: AES256        │                  │  │
│  └──────────┘                          └────────┬─────────┘  │
│                                                  │            │
│                                          2. S3 pairs object  │
│                                             with S3-Owned    │
│                                             Key (you never   │
│                                             see this key)    │
│                                                  │            │
│                                                  ▼            │
│                                         ┌────────────────┐   │
│                                         │   Encrypted    │   │
│                                         │    Object      │   │
│                                         │  stored in S3  │   │
│                                         └────────────────┘   │
│                                                               │
│  To read: just have S3 GetObject permission — S3 handles     │
│  decryption automatically using the same S3-owned key        │
└──────────────────────────────────────────────────────────────┘

SSE-KMS (AWS KMS-Managed Keys)

Instead of relying on the S3-owned key that you never see, SSE-KMS lets you manage your own keys using the AWS Key Management Service (KMS). This gives you significantly more control and visibility.

Advantages over SSE-S3:

• User control over the encryption key — you can create keys, define who can use them, rotate them, and even disable or delete them
• Full audit trail — every single use of a KMS key is logged in CloudTrail, so you know exactly who encrypted or decrypted what and when
• You specify which KMS key to use in the request header
• You can use the default aws/s3 KMS key (free) or create your own Customer Managed Key (CMK) (costs ~$1/month per key)

The critical security difference: To read an SSE-KMS encrypted object, a user needs two things:

1. S3 permissions to access the object (e.g., s3:GetObject)
2. KMS permissions to use the underlying KMS key (e.g., kms:Decrypt)

This dual-access requirement is an extra layer of security that SSE-S3 doesn't provide. It's a common exam topic.

How SSE-KMS Works

┌──────────────────────────────────────────────────────────────┐
│                     SSE-KMS ENCRYPTION FLOW                   │
│                                                               │
│  ┌──────────┐                          ┌──────────────────┐  │
│  │          │   1. Upload object        │                  │  │
│  │   User   │ ──────────────────────▶   │   Amazon S3      │  │
│  │          │   + Header: aws:kms       │                  │  │
│  │          │   + KMS Key ID            │                  │  │
│  └──────────┘                          └────────┬─────────┘  │
│                                                  │            │
│                                          2. S3 calls KMS     │
│                                             GenerateDataKey  │
│                                             API              │
│                                                  │            │
│                              ┌───────────────────┘            │
│                              ▼                                │
│                    ┌──────────────────┐                       │
│                    │    AWS KMS       │                       │
│                    │  (your KMS key)  │                       │
│                    └────────┬─────────┘                       │
│                             │                                 │
│                     3. KMS returns a                          │
│                        data encryption key                    │
│                             │                                 │
│                             ▼                                 │
│                    ┌──────────────────┐                       │
│                    │   Encrypted      │                       │
│                    │    Object        │                       │
│                    │  stored in S3    │                       │
│                    └──────────────────┘                       │
│                                                               │
│  To read: need S3 GetObject permission AND KMS Decrypt       │
│  permission — both must be granted or access is denied       │
└──────────────────────────────────────────────────────────────┘

DSSE-KMS (Dual-Layer Server-Side Encryption)

DSSE-KMS was released in June 2023 and applies two independent layers of encryption using KMS keys. Think of it as "double encryption based on KMS" — a stronger variant for workloads that require it.

• Appears as an option in the console alongside SSE-S3 and SSE-KMS
• Not commonly tested on the SAA-C03 exam as of now
• If you see it at the exam, it's just "stronger KMS encryption"

SSE-C (Customer-Provided Keys)

With SSE-C, the encryption key is managed entirely outside of AWS. You generate and store the key yourself. When you upload or download an object, you send the key along with the request. Amazon S3 uses the key to encrypt/decrypt, then immediately discards it — S3 never stores your key.

Key characteristics:

• HTTPS is mandatory — you're transmitting a secret key, so the connection must be encrypted
• The key must be provided in HTTP headers for every single request (upload, download, copy, etc.)
• Not available in the AWS Console — you can only use SSE-C via the CLI or SDK
• If you lose the key, the data is permanently unrecoverable — AWS cannot help you
• AWS stores a salted HMAC hash of the key for validation purposes, but not the key itself

How SSE-C Works

┌──────────────────────────────────────────────────────────────┐
│                      SSE-C ENCRYPTION FLOW                    │
│                                                               │
│  ┌──────────┐                          ┌──────────────────┐  │
│  │          │   1. Upload object        │                  │  │
│  │   User   │ ──────────────────────▶   │   Amazon S3      │  │
│  │ (manages │   + File data             │                  │  │
│  │  own key)│   + Encryption key        │                  │  │
│  │          │   (in HTTP headers)       │                  │  │
│  │          │   ⚠️ HTTPS REQUIRED       │                  │  │
│  └──────────┘                          └────────┬─────────┘  │
│                                                  │            │
│                                          2. S3 uses your key │
│                                             to encrypt the   │
│                                             object            │
│                                                  │            │
│                                          3. S3 DISCARDS      │
│                                             your key          │
│                                             immediately       │
│                                                  │            │
│                                                  ▼            │
│                                         ┌────────────────┐   │
│                                         │   Encrypted    │   │
│                                         │    Object      │   │
│                                         │  (key NOT      │   │
│                                         │   stored)      │   │
│                                         └────────────────┘   │
│                                                               │
│  To read: must provide the EXACT SAME KEY in the request     │
│  Lost key = lost data forever — AWS cannot recover it        │
└──────────────────────────────────────────────────────────────┘

Client-Side Encryption

With client-side encryption, everything happens outside of AWS. The client encrypts the data before sending it to S3 and decrypts it after retrieving it. Amazon S3 is just a storage service — it has no knowledge that the data is encrypted, what algorithm was used, or what key was used.

Key characteristics:

• Use a client library like the Amazon S3 Client-Side Encryption Library to simplify implementation
• The client fully manages the keys and the entire encryption/decryption cycle
• AWS has zero visibility into the encryption — no headers, no configuration, no audit trail on the AWS side
• You don't need to tell AWS anything about the encryption when uploading

How Client-Side Encryption Works

┌──────────────────────────────────────────────────────────────┐
│                 CLIENT-SIDE ENCRYPTION FLOW                    │
│                                                               │
│  ┌──────────┐   ┌──────────┐   ┌──────────────┐             │
│  │          │   │ Client's │   │              │             │
│  │  File    │ + │   Key    │ = │  Encrypted   │             │
│  │ (plain)  │   │ (yours)  │   │    File      │             │
│  └──────────┘   └──────────┘   └──────┬───────┘             │
│                                        │                      │
│                  Encryption happens     │                      │
│                  on YOUR machine        │                      │
│                  BEFORE upload          │                      │
│                                        │                      │
│                                        ▼                      │
│                               ┌────────────────┐             │
│                               │   Amazon S3    │             │
│                               │                │             │
│                               │  Stores the    │             │
│                               │  encrypted     │             │
│                               │  blob as-is    │             │
│                               │                │             │
│                               │  Has NO idea   │             │
│                               │  it's encrypted│             │
│                               └────────────────┘             │
│                                                               │
│  To read: download the encrypted blob, decrypt on YOUR       │
│  machine using YOUR key. AWS is never involved in crypto.    │
└──────────────────────────────────────────────────────────────┘

Encryption in Transit (SSL/TLS)

Everything we've discussed so far is encryption at rest — protecting data stored on disk. But data also needs protection while it's moving between your application and S3. This is called encryption in transit (also known as encryption in flight, SSL, or TLS).

Amazon S3 exposes two endpoints:

Key points:

• HTTPS is mandatory for SSE-C — you're transmitting a secret key in the headers
• Most AWS clients, SDKs, and the console use HTTPS by default, so in practice you rarely need to worry about this
• The green lock icon 🔒 in your browser means the connection is using TLS

Forcing Encryption in Transit with a Bucket Policy

You can create a bucket policy that denies any request not using HTTPS:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ForceHTTPS",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "Bool": {
          "aws:SecureTransport": "false"
        }
      }
    }
  ]
}

Default Encryption

Since January 5, 2023, all S3 buckets have SSE-S3 default encryption enabled automatically. This means every new object uploaded to any bucket is encrypted at rest, even if the uploader doesn't specify any encryption headers.

You can customize the default:

• Change the default encryption to SSE-KMS or DSSE-KMS in the bucket settings
• You cannot set SSE-C as the default (it requires per-request key transmission)

You can also enforce encryption via bucket policy — by denying PutObject requests that don't include the correct encryption headers. This is stricter than default encryption because it rejects non-compliant uploads rather than silently applying a fallback.

Example: Forcing SSE-KMS via Bucket Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonKMSEncryption",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption-aws-kms-key-id": "true"
        }
      }
    }
  ]
}

This policy says: "If the s3:x-amz-server-side-encryption-aws-kms-key-id header is null (missing), deny the upload." This forces every upload to specify a KMS key.

Example: Forcing SSE-C via Bucket Policy

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonSSEC",
      "Effect": "Deny",
      "Principal": "*",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "Null": {
          "s3:x-amz-server-side-encryption-customer-algorithm": "true"
        }
      }
    }
  ]
}

This denies uploads that don't include the SSE-C customer algorithm header.

{ "Effect": "Deny", "Principal": "*", "Action": "s3:GetObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": { "Bool": { "aws:SecureTransport": "false" } } }

{ "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": { "Null": { "s3:x-amz-server-side-encryption-aws-kms-key-id": "true" } } }

{ "Effect": "Deny", "Principal": "*", "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::my-bucket/*",
  "Condition": { "Null": { "s3:x-amz-server-side-encryption-customer-algorithm": "true" } } }

Hands-On Walkthrough

Console Encryption Options

When creating a bucket or uploading objects in the AWS Console, you see three encryption options:

Step-by-Step: Creating an Encrypted Bucket

1. Go to S3 Console → Create Bucket
2. Name your bucket and select a region
3. Enable Bucket Versioning (recommended — changing encryption creates new versions)
4. Under Default Encryption, choose your encryption type:
   • SSE-S3 (default) — no further configuration needed
   • SSE-KMS — select a KMS key (default aws/s3 key is free)
   • DSSE-KMS — select a KMS key (double encryption)
5. If using SSE-KMS, the Bucket Key option is enabled by default (reduces KMS API calls)
6. Click Create Bucket

Step-by-Step: Changing Encryption on an Existing Object

1. Navigate to the object in S3
2. Click on the object → scroll to Server-side encryption settings
3. Click Edit
4. Choose a new encryption type (e.g., switch from SSE-S3 to SSE-KMS)
5. If SSE-KMS: select the KMS key — the default aws/s3 key is free, custom keys cost money
6. Click Save Changes

KMS Key Options in the Console

When selecting SSE-KMS, you have two choices:

Bucket Default Encryption Settings

You can change the default encryption for the entire bucket:

1. Go to the bucket → Properties → scroll to Default Encryption
2. Click Edit
3. Choose SSE-S3, SSE-KMS, or DSSE-KMS
4. If SSE-KMS: the Bucket Key toggle is available (enabled by default)
5. Save changes

All new objects uploaded without explicit encryption headers will use this default.

Encryption Decision Flowchart

┌─────────────────────────────────────────────────────────────────┐
│              WHICH ENCRYPTION METHOD SHOULD I USE?               │
│                                                                  │
│  Do you need to audit key usage in CloudTrail?                  │
│  ├── YES ──▶ Do you need to control the key yourself?           │
│  │           ├── YES ──▶ ==SSE-KMS with Customer Managed Key==  │
│  │           └── NO ───▶ ==SSE-KMS with aws/s3 default key==   │
│  │                                                               │
│  └── NO ──▶ Must the key never touch AWS?                       │
│             ├── YES ──▶ Must AWS handle encryption?              │
│             │           ├── YES ──▶ ==SSE-C==                   │
│             │           └── NO ───▶ ==Client-Side Encryption==  │
│             │                                                    │
│             └── NO ───▶ ==SSE-S3== (default, simplest)          │
└─────────────────────────────────────────────────────────────────┘

Questions & Answers