DynamoDB encryption: at rest, in transit and client-side

DynamoDB encrypts all table data at rest by default with an AWS owned key, and encryption cannot be disabled. HTTPS protects traffic between your application and DynamoDB. If sensitive attributes must remain encrypted inside the service, use client-side encryption as an additional layer; encryption at rest still returns plaintext to authorized readers.

Three kinds of encryption, three different boundaries

For example, a role with permission to read an order can read its address when the table uses server-side encryption. Changing the table from an AWS owned key to a customer managed key does not automatically hide that address from the role. Use DynamoDB access control to decide who can read it, and application encryption when readers must also hold separate decryption authority.

DynamoDB encryption at rest

DynamoDB uses AES-256 encryption for data on persistent storage. Table data, primary keys, local and global secondary indexes, streams and backups are covered. There is no application migration required to read an encrypted table: DynamoDB performs decryption as part of serving authorized requests.

The encryption key applies to the table as a whole. You cannot turn server-side encryption off for individual items or choose a different table-level key for a particular attribute. AWS notes that some sort-key range boundaries remain in plaintext in table metadata, so avoid treating a key name or key value as a place to hide secrets.

Which KMS key should you use?

Both AWS owned and AWS managed DynamoDB keys rotate annually. For customer managed keys, configure rotation according to the key's supported options; rotation is not the same as changing the key ARN assigned to a table. Key management and billing details are in the DynamoDB key comparison and AWS KMS pricing.

Choose a customer managed key for a concrete requirement: controlling its policy, auditing its use, managing its lifecycle, or using supported imported key material or a custom key store. It adds responsibilities as well as control. Restrict who can disable the key, schedule deletion or change grants, and include those events in operational monitoring.

Inspect the encryption configuration

Use AWS CLI v2 with an authenticated profile and the table's Region:

aws dynamodb describe-table \
  --region us-east-1 \
  --table-name Orders \
  --query 'Table.{TableName:TableName,TableStatus:TableStatus,SSEDescription:SSEDescription}' \
  --output json
aws dynamodb describe-table \
  --region us-east-1 \
  --table-name Orders \
  --query 'Table.{TableName:TableName,TableStatus:TableStatus,SSEDescription:SSEDescription}' \
  --output json

For KMS-backed configurations, SSEDescription identifies the key and encryption status. An absent encryption description does not mean an unencrypted table: the default AWS owned key does not require the same KMS description. Check the encryption option in the console if you need to distinguish the default from a named key.

The image is an example response shape, not a requirement that every encrypted table return the same fields.

Change the table's key without changing application code

To switch an existing table to a customer managed key, replace the example key ARN with a symmetric key in the table's Region:

aws dynamodb update-table \
  --region us-east-1 \
  --table-name Orders \
  --sse-specification 'Enabled=true,SSEType=KMS,KMSMasterKeyId=arn:aws:kms:us-east-1:123456789012:key/REPLACE-WITH-KEY-ID'
aws dynamodb update-table \
  --region us-east-1 \
  --table-name Orders \
  --sse-specification 'Enabled=true,SSEType=KMS,KMSMasterKeyId=arn:aws:kms:us-east-1:123456789012:key/REPLACE-WITH-KEY-ID'

The caller and DynamoDB must have the necessary KMS permissions. Keep the old key usable while the change completes, and inspect SSEDescription until the new ARN appears with status ENABLED. DynamoDB supports changing encryption keys without taking the table offline.

Do not immediately delete the old key after that check. Existing backups can still depend on it. Review the encryption usage notes before removing grants or retiring a key, especially on a global table. An inaccessible key can make data unavailable even when the DynamoDB permissions are correct.

Encryption in transit uses HTTPS

The AWS CLI and SDKs connect to DynamoDB using HTTPS by default. TLS protects the network connection; it does not require the DynamoDB Encryption Client or the Database Encryption SDK. Do not disable certificate validation to fix a connection error. Check the certificate trust configuration, proxy and endpoint instead.

TLS terminates at the service, so it does not prevent DynamoDB from processing plaintext values. This is the distinction between transport protection and client-side encryption. Private connectivity through a DynamoDB VPC endpoint changes the network path, not the need for TLS or IAM authorization.

Client-side encryption with the AWS Database Encryption SDK

The current library is the AWS Database Encryption SDK for DynamoDB, the successor to the DynamoDB Encryption Client. Its current official repository lists Java, .NET and Rust as supported application runtimes. The older Java and Python DynamoDB Encryption Client documentation describes legacy implementations; do not assume that a Python example uses the current library or that every library generation shares the same ciphertext format.

You configure which attributes to encrypt and which to sign. The SDK encrypts protected values before writing and verifies and decrypts them after reading. This lets the database store ciphertext while your authorized application presents readable values. The library is open source; KMS operations and the AWS services used by your application can still incur charges. The SDK overview explains keyrings and record protection.

Plan the data model before adding encryption to an existing application:

1. Identify the sensitive fields and the application components allowed to decrypt them.
2. Preserve the key and query behavior required by your access patterns. Encrypting a value does not make ordinary plaintext filtering work over ciphertext.
3. Choose signing and encryption actions consistently across every writer, including scripts and background jobs.
4. Test reads of existing plaintext records, newly encrypted records and backups before migrating production data.
5. Test how updates from an older application version interact with signed attributes.

Searchable encryption is a separate SDK design with its own security tradeoffs. It is not a switch that makes every existing DynamoDB expression work unchanged. Also, do not interchange ciphertext produced by the Database Encryption SDK, the general AWS Encryption SDK and the S3 encryption client without a documented migration path.

Backups and global tables retain key dependencies

On-demand backups retain the table key used when each backup was taken. Changing the active table key does not re-encrypt those existing backups. A restored table is encrypted too, but choosing a destination key does not remove the need to decrypt the source backup. Keep a record of retained backups before deleting keys; the backup and restore guide covers recovery checks.

For current-version global tables, plan the customer managed keys in each replica's Region and their permissions as part of replica provisioning. Do not assume a key policy in one Region grants access to another replica. Legacy global tables have different encryption limitations; review the configuration before treating an old replica set as equivalent to a newly created one.

DAX encryption is a separate cluster setting

DynamoDB Accelerator caches table data in a VPC. Its storage encryption uses an AWS managed key, and customer managed keys are not supported for the DAX cluster itself. Configure DAX encryption at rest when creating the cluster; it cannot be enabled or disabled afterward.

Also configure DAX encryption in transit and use a compatible DAX client. An existing cluster without transit encryption must be replaced and application traffic moved to the encrypted cluster. Table encryption does not prove that a separate cache connection is encrypted.