DynamoDB Security

DynamoDB Security covers protecting your NoSQL data in AWS's fully managed key-value and document database. Because DynamoDB has no servers to patch, no network listeners to firewall, and no unencrypted mode, its security model collapses almost entirely into one discipline: IAM. That makes it simpler than a database on EC2, and it makes sloppy IAM policies proportionally more dangerous.

Encryption

• Encryption at Rest: always enabled (since 2018); choose AWS owned key (free), AWS managed key, or customer managed KMS key
• In Transit: all DynamoDB endpoints use HTTPS (TLS); no unencrypted option

Access Control

• IAM Policies: control who can access tables, indexes, and streams
• Fine-grained Access Control: use IAM condition keys (dynamodb:LeadingKeys) to restrict access to specific items based on partition key
• VPC Endpoints: gateway endpoint keeps DynamoDB traffic on the AWS network (no internet traversal)

Data Protection

• Point-in-Time Recovery (PITR): continuous backups with a configurable recovery window of 1 to 35 days
• On-Demand Backups: manual snapshots for long-term retention
• Deletion Protection: prevents accidental table deletion

Least Privilege on a NoSQL Table

DynamoDB's IAM vocabulary is rich enough to scope permissions tightly, and most teams use a fraction of it. Actions separate reads (dynamodb:GetItem, Query, Scan) from writes (PutItem, UpdateItem, DeleteItem), resources can name a specific table and its indexes rather than a wildcard, and condition keys go further: dynamodb:LeadingKeys pins access to items whose partition key matches the caller's identity, and dynamodb:Attributes restricts which attributes can be read or written. A multi-tenant application can use LeadingKeys with a variable like the Cognito identity ID so each end user can only ever touch their own items, enforced by IAM itself rather than by application code you have to get right on every query path.

How It Goes Wrong in Practice

The recurring failure is the wildcard data-plane policy: a Lambda function needs to read one table, and the quick fix during development is dynamodb:* on Resource: *. That policy ships to production, and from then on any compromise of that function, an injected dependency, an SSRF, a leaked deployment credential, hands the attacker every table in the account, including Scan, the perfect exfiltration primitive that reads a table end to end, and destructive actions like DeleteTable. The pattern shows up constantly in real incidents because DynamoDB access almost never crosses a network boundary you can firewall; the IAM policy is the entire perimeter. The second common gap is data protection theater: teams assume "managed" means "recoverable", but PITR is off by default. A bad deployment that overwrites items in place, or a scripted cleanup gone wrong, is unrecoverable without it, since encryption and IAM do nothing against your own code writing garbage.

A Practical Check: Is PITR Actually On?

For each production table, verify continuous backups and point-in-time recovery:

aws dynamodb describe-continuous-backups --table-name prod-orders

The response shows ContinuousBackupsStatus and, inside PointInTimeRecoveryDescription, a PointInTimeRecoveryStatus of ENABLED or DISABLED, the recovery window (RecoveryPeriodInDays, configurable from 1 to 35), and the earliest and latest restorable timestamps, the latest typically being about five minutes behind current time. DISABLED on a table you care about is a finding to fix the same day.

Frequently Asked Questions

Can a DynamoDB table be publicly exposed like an S3 bucket?

Not in the same way. There is no anonymous access mode: every request must be signed by a principal that IAM authorizes. The realistic exposure paths are overly broad IAM policies inside your account and credentials leaking out of it, which is why scoping actions and resources tightly matters more than network controls here.

Which KMS key option should I choose for encryption at rest?

All three encrypt with AES-256; the difference is control and auditability. The AWS owned key is free and invisible, with no key policy and no CloudTrail on key usage. The AWS managed key adds CloudTrail visibility. A customer managed key adds a key policy you control, rotation on your schedule, and the ability to revoke access, which is what regulated environments usually require.

Does PITR replace on-demand backups?

No, they answer different questions. PITR restores the table to any second within its 1-to-35-day window, which is ideal for oops-recovery after bad writes. On-demand backups persist until you delete them, covering long-term retention and compliance snapshots far beyond 35 days. Production tables generally deserve both, plus deletion protection so nobody drops the table itself.