RDS Encryption at Rest: Enable KMS and Manage Keys (2026)

Enabling RDS encryption at rest means your database data is encrypted while it’s sitting on disk, making it unreadable to anyone who gains unauthorized physical access to the storage.

Let’s see this in action. Imagine you’re setting up a new RDS PostgreSQL instance. When you go through the creation wizard, you’ll see an option for "Encryption." You’ll select "Enable encryption" and then choose a KMS (Key Management Service) key. This key can be a service-managed key (aws/rds) or a customer-managed key (CMK) that you create and control in KMS.

{
  "DBClusterIdentifier": "my-encrypted-cluster",
  "Engine": "postgres",
  "MasterUsername": "admin",
  "MasterUserPassword": "supersecretpassword",
  "AllocatedStorage": 100,
  "DBSubnetGroupName": "my-db-subnet-group",
  "VpcSecurityGroupIds": [
    "sg-0123456789abcdef0"
  ],
  "StorageEncrypted": true,
  "KmsKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcdef01-2345-6789-abcd-ef0123456789",
  "Tags": [
    {
      "Key": "Name",
      "Value": "MyEncryptedDB"
    }
  ]
}

This configuration tells RDS to use the specified KMS key to encrypt the data files for my-encrypted-cluster. When data is written to disk, RDS calls KMS to encrypt it. When data is read, RDS calls KMS to decrypt it. The beauty is that the application connecting to your RDS instance doesn’t need to know about this; it just reads and writes data as usual. RDS handles the encryption and decryption transparently.

The core problem this solves is data breach mitigation. If your database server’s physical storage is stolen or accessed without authorization, the data remains encrypted and useless without the KMS key. It’s a crucial layer of defense for sensitive information.

Here’s how it works internally: RDS uses the industry-standard AES-256 encryption algorithm. When you enable encryption, RDS creates a new storage volume and encrypts it using the specified KMS key. All data written to this volume, including snapshots, logs, and temporary files, is encrypted. When you create a snapshot of an encrypted database instance, the snapshot is also encrypted with the same KMS key. You can then restore from this encrypted snapshot to create a new encrypted instance.

The exact levers you control are primarily the KMS key itself. You can choose to use the AWS-managed key for RDS (aws/rds), which is the simplest option. AWS manages its lifecycle. Or, you can create a Customer-Managed Key (CMK) in KMS. This gives you more control: you can define access policies for the key, set rotation schedules, and even disable or delete the key to revoke access to your encrypted data.

When you use a customer-managed KMS key, you need to ensure the RDS service principal (rds.amazonaws.com) has permission to use the key. This is done via the KMS key policy. A typical policy for an RDS CMK would look something like this:

{
  "Version": "2012-10-17",
  "Id": "key-policy-rds",
  "Statement": [
    {
      "Sid": "Enable IAM User Permissions",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "Allow RDS to use the key",
      "Effect": "Allow",
      "Principal": {
        "Service": "rds.amazonaws.com"
      },
      "Action": [
        "kms:Encrypt",
        "kms:Decrypt",
        "kms:ReEncrypt*",
        "kms:GenerateDataKey*",
        "kms:DescribeKey"
      ],
      "Resource": "*"
    }
  ]
}

This policy grants the rds.amazonaws.com service principal the necessary permissions to perform encryption, decryption, and key description operations on the KMS key. Without these permissions, RDS wouldn’t be able to encrypt data on write or decrypt it on read.

Most people don’t realize that if you disable or schedule a customer-managed KMS key for deletion, any RDS instances using that key will become inaccessible. The database itself won’t fail immediately, but any attempt to read or write data will result in an error because RDS can’t call KMS to perform the necessary decryption or encryption operations. This is a critical point for disaster recovery planning; ensure your KMS keys have appropriate availability and are not inadvertently deleted.

The next step is understanding how to manage encryption for existing unencrypted RDS instances.