RDS Encryption with KMS: What Really Happens Behind the Scenes

When you enable encryption for an Amazon RDS database using AWS KMS, AWS says your data is "encrypted at risk".

But what does that actually mean internally?

• Is the data always encrypted?

• How does RDS read encrypted data?

• Does the application decrypt it?

• Where are encryption keys stored?

• What happens if the KMS key is disabled?

In this article, we’ll go deep into how Amazon RDS encryption works under the hood using AWS KMS Customer Managed Keys (CMKs).

What is RDS Encryption?

Amazon RDS encryption protects our database data at rest.

This includes:

• Database storage

• Automated backups

• Read replicas

• Snapshots

• Transaction logs

RDS uses:

• AWS KMS for key management

• AES-256 for storage encryption internally

The encryption process is transparent to applications.

Encryption at Rest vs Encryption in Transit

Encryption at Rest

Protects data stored on disk.

Examples:

• Database files

• Snapshots

• Backups

This is what RDS + KMS handles.

Encryption in Transit

Protects data moving over the network.

Example:

• App to RDS communication

This uses:

• SSL/TLS certificates

Even if your RDS storage is encrypted, network traffic can still be plaintext unless TLS is enabled.

Best Practice:

• Enable both at-rest and in-transit encryption.

Creating an Encrypted RDS Database

Suppose we create a PostgreSQL RDS instance with:

aws rds create-db-instance \ --db-instance-identifier mydb \ --engine postgres \ --storage-encrypted \ --kms-key-id arn:aws:kms:...

At this point:

• AWS KMS becomes responsible for encryption key management.

• RDS becomes responsible for encrypting database storage.

But here’s the important part:

Your KMS key does NOT directly encrypt database data.

AWS uses something called Envelope Encryption.

What is Envelope Encryption?

Envelope encryption is a layered encryption approach.

Instead of using the KMS key directly for encrypting huge amounts of data, AWS uses:

1. A KMS Customer Managed Key (CMK)

2. A temporary Data Encryption Key (DEK)

The DEK encrypts the actual database storage.

The CMK encrypts the DEK.

The Internal Encryption Flow

Here’s what happens internally when RDS is created.

Step 1: RDS Requests a Data Key from KMS

RDS sends a request to AWS KMS:

Generate a data encryption key for this database.

KMS generates:

• A plaintext DEK

• An encrypted DEK

The encrypted DEK is encrypted using your CMK.

Step 2: KMS Returns Both Keys

KMS returns:

• Plaintext DEK

• Encrypted DEK

The plaintext DEK is temporarily used in memory.

The encrypted DEK is stored persistently.

Step 3: RDS Encrypts Storage using the DEK

The plaintext DEK is now used to encrypt:

• Databases pages

• Logs

• Backups

• Snapshots

Typically using AES-256 encryption internally.

What is Actually Stored on Disk?

• Encrypted database blocks

• Encrypted backups

• Encrypted backups

• Encrypted snapshots

• Encrypted logs

• Encrypted DEK

What is NOT stored permanently:

• Plaintext DEK

• Plaintext database files

So even if someone steals the physical storage, they cannot read the data.

What happens during a Write operation?

Suppose your application runs:

INSERT INTO users VALUES ('Alice');

Internally:

What happens during a Read operation?

Suppose your application executes:

SELECT * FROM users;

Internally:

This means:

Yes, RDS automatically decrypts the data before returning query results.

Your application does NOT manually decrypt anything.

This process is completely transparent.

Where does Decryption happen?

Decryption happens:

• Inside AWS-managed RDS infrastructure

• At the storage layer

Not inside:

• Your application

• Your SQL Queries

Applications simply see normal database behavior.

What happens during an RDS Restart?

When RDS restarts:

What happens if the KMS Key is disabled?

If you disable or revoke access to the CMK:

Connect with me on LinkedIn: https://www.linkedin.com/in/scoder17/

Follow me on GitHub: https://github.com/scoder17