DynamoDB Encryption

Encryption scrambles data so that only authorized parties can read it. DynamoDB encrypts every table at rest, and every connection travels over secure channels. The protection runs automatically and needs no code changes.

The Safe Deposit Box Picture

A bank stores valuables in a locked box inside a vault. A key opens the box, and the bank controls who receives the key. DynamoDB works the same way. Your data sits in a locked box (encrypted storage), and AWS Key Management Service (KMS) holds the key.

Encryption at Rest

Encryption at rest protects data stored on disk. DynamoDB turns it on for every table, and you cannot switch it off. The protection covers the table, local and global secondary indexes, streams, global tables, and backups.

Three Key Options

Choosing a Key

• Pick the AWS owned key for general workloads that need no key audit.
• Pick the AWS managed key when you need to see key usage in CloudTrail.
• Pick a customer managed key when rules demand control over key policies, rotation, or disabling.

You can change the key type of an existing table at any time. DynamoDB applies the change without downtime.

Diagram: How Encryption at Rest Works

Application writes item
        │
        ▼
DynamoDB service
        │ asks for a data key
        ▼
AWS KMS (holds the key)
        │
        ▼
Item is encrypted ──► stored on disk as scrambled data

Authorized reads reverse the process. DynamoDB decrypts the item before it reaches your application, and the application sees normal data.

Customer Managed Key Cautions

• A disabled or deleted key makes the table unreadable.
• The key policy must allow DynamoDB to use the key.
• Every user and role needs KMS permissions in addition to DynamoDB permissions in IAM.
• Schedule key deletion with care, because a deleted key cannot be restored after the waiting period.

Encryption in Transit

DynamoDB exposes HTTPS endpoints that use TLS. Data moving between your application and DynamoDB travels in encrypted form. The AWS SDKs use HTTPS by default. Never point an application at an unencrypted endpoint on a production system.

Client-Side Encryption

Server-side encryption protects data from anyone who reaches the storage. Client-side encryption protects specific attributes even from people with read access to the table. The AWS Database Encryption SDK encrypts chosen attributes inside your application before the data leaves it.

Plain item:
  { "UserID": "U001", "Email": "asha@example.com", "CardNote": "4111..." }

Stored item (CardNote encrypted by the application):
  { "UserID": "U001", "Email": "asha@example.com", "CardNote": "x7Qe9...scrambled" }

Encrypted attributes cannot serve in key conditions or filters, so protect only the attributes that truly need the extra layer.

Auditing Key Use

AWS CloudTrail logs every KMS call made for customer managed and AWS managed keys. Security teams review these records to confirm that only expected roles touch the data.

Encryption Checklist

• Confirm the key type for each production table.
• Grant KMS permissions to the roles that read or write data.
• Use HTTPS endpoints only.
• Consider client-side encryption for highly sensitive fields.
• Protect backups and exports in S3 with their own encryption.

Summary

• DynamoDB encrypts all tables at rest, and the setting stays on.
• Three key types give increasing control: AWS owned, AWS managed, and customer managed.
• Connections use TLS for encryption in transit.
• Client-side encryption protects selected attributes inside the application.
• Losing access to a customer managed key means losing access to the data.