DynamoDB Security Best Practices: IAM, KMS, PITR & VPC Endpoints

DynamoDB security in plain English

The practical goals when securing a DynamoDB table are:

1. Restrict access to the minimum actions and tables each application needs
2. Choose the right encryption key model for your compliance requirements
3. Enable recovery mechanisms before you need them
4. Ensure you can detect unexpected access after the fact

What DynamoDB handles vs what you configure

Understanding the shared responsibility model for DynamoDB tells you what you can rely on and what you must configure yourself.

How access control works in DynamoDB

DynamoDB has no built-in user system. Every API call must be signed with AWS credentials, and IAM decides whether the call is permitted. There are two ways to apply access control to a DynamoDB table.

Identity-based policies

These are policies attached to IAM users, roles, or groups. They define what that identity can do across any DynamoDB table it interacts with. This is the most common pattern. A Lambda function or EC2 instance assumes an IAM role that grants exactly the actions it needs on exactly the tables it needs.

Common DynamoDB actions:

A read-only application role scoped to a specific table and its indexes:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:Query",
        "dynamodb:BatchGetItem"
      ],
      "Resource": [
        "arn:aws:dynamodb:eu-west-2:123456789012:table/Orders",
        "arn:aws:dynamodb:eu-west-2:123456789012:table/Orders/index/*"
      ]
    }
  ]
}

The resource must include both the table ARN and index/* if the application queries Global Secondary Indexes. A policy scoped to the table ARN alone will return AccessDenied on GSI queries. See Fixing IAM AccessDenied Errors for how to diagnose and fix this.

Resource-based policies

DynamoDB supports resource-based policies attached directly to a table. These let you grant access to principals from other AWS accounts without requiring changes on the caller’s side. They are useful for cross-account data sharing but less common than identity-based policies for single-account applications. See the comparison table further down the page.

Fine-grained access with LeadingKeys

dynamodb:LeadingKeys is a condition that restricts access to items where the partition key matches a specific value. Combined with the aws:userid policy variable, you can write a single policy that enforces per-user data isolation automatically.

In practice: imagine a UserData table where each item’s partition key is the user’s ID. You want each user to read and write only their own items. One policy handles this for every user:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:UpdateItem",
        "dynamodb:DeleteItem",
        "dynamodb:Query"
      ],
      "Resource": "arn:aws:dynamodb:eu-west-2:123456789012:table/UserData",
      "Condition": {
        "ForAllValues:StringEquals": {
          "dynamodb:LeadingKeys": ["${aws:userid}"]
        }
      }
    }
  ]
}

${aws:userid} resolves to the caller’s IAM user or role ID at evaluation time. Each principal can only touch items matching their own identity. No application-level filtering required.

See IAM Policy Conditions for a full reference on condition keys and operators including ForAllValues:StringEquals and other useful DynamoDB condition keys.

Encryption at rest

All DynamoDB data is encrypted at rest. You choose which key model to use. See Encryption in AWS for a broader overview of how encryption works across AWS services.

To create a table with a customer-managed KMS key:

# Create a table with customer-managed KMS encryption
aws dynamodb create-table \
  --table-name SensitiveData \
  --attribute-definitions AttributeName=userId,AttributeType=S \
  --key-schema AttributeName=userId,KeyType=HASH \
  --billing-mode PAY_PER_REQUEST \
  --sse-specification '{
    "Enabled": true,
    "SSEType": "KMS",
    "KMSMasterKeyId": "arn:aws:kms:eu-west-2:123456789012:key/your-key-id"
  }'

For key management details including rotation schedules, key policies, and how to share keys across accounts, see AWS KMS Overview and Customer-Managed Keys.

Network access and private connectivity

DynamoDB is API-based. There is no TCP port to open and no security group to configure on the database itself. All traffic uses HTTPS on port 443. By default, traffic from your VPC resources to DynamoDB routes through the public internet (always HTTPS-encrypted, but traversing public network paths).

A VPC endpoint for DynamoDB keeps all traffic inside the AWS network. It never crosses the public internet and does not require a NAT gateway or internet gateway to reach DynamoDB.

# Create a Gateway VPC endpoint for DynamoDB
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0abc12345 \
  --service-name com.amazonaws.eu-west-2.dynamodb \
  --route-table-ids rtb-0abc12345

After creating the endpoint, add an endpoint policy to restrict which DynamoDB tables the endpoint can reach. Use aws:sourceVpce as a condition key in IAM policies to ensure DynamoDB access only comes through the endpoint.

See VPC Endpoint Policies for how to write these restrictions and AWS PrivateLink Overview for when an interface endpoint is the right choice.

Backup, recovery, and data protection

Point-in-time recovery

PITR must be explicitly enabled per table. It is off by default. Once on, DynamoDB captures a continuous backup stream that lets you restore to any second within the last 35 days.

# Enable PITR on a table
aws dynamodb update-continuous-backups \
  --table-name Orders \
  --point-in-time-recovery-specification PointInTimeRecoveryEnabled=true

# Restore to a specific point in time (creates a new table)
aws dynamodb restore-table-to-point-in-time \
  --source-table-name Orders \
  --target-table-name Orders-restored-20260315 \
  --restore-date-time 2026-03-15T14:00:00Z

The restore creates a new table. The original is unaffected and continues serving traffic. You verify the restored data, then cut the application over when ready. This is the same pattern as RDS point-in-time recovery.

On-demand backups

On-demand backups are manual full-table snapshots retained until you delete them. They complement PITR for cases where you need to keep a snapshot beyond the 35-day PITR window, want a pre-deployment baseline before a risky migration, or need to archive a historical state of a table.

Monitoring, logging, and compliance

Preventative controls stop bad access. Detective controls tell you when something unexpected happened. Both matter in production. An over-privileged role that was never used for malicious activity today may be exploited tomorrow, and without logging you will not know it happened.

AWS CloudTrail

CloudTrail records every DynamoDB API call: who made it, from where, with what parameters, and whether it succeeded. This is your primary audit trail.

• Management events are logged by default and free. These cover table create and delete, backup and restore operations, PITR changes, capacity updates, and Streams configuration.
• Data events (individual item reads and writes: GetItem, PutItem, etc.) are not logged by default and have an additional cost. Enable them for sensitive tables where you need to know which items were accessed and by whom.

See AWS CloudTrail Overview and CloudTrail Log Types for configuration details and event format.

KMS key usage visibility

If you use AWS-managed or customer-managed KMS keys, every Decrypt call DynamoDB makes is logged in CloudTrail under kms.amazonaws.com events. This provides indirect visibility into data access; each item read corresponds to a KMS Decrypt event. This is one of the primary reasons to choose KMS over AWS-owned keys when a compliance audit trail is required.

AWS Security Hub

AWS Security Hub includes DynamoDB checks that assess whether PITR is enabled, whether tables are encrypted with customer-managed keys, and whether tables have at least one backup configured. These automated findings catch controls that were skipped during provisioning or silently disabled over time.

What to watch for

Useful signals to monitor in a production DynamoDB environment:

• Unexpected spikes in ConsumedWriteCapacityUnits from unfamiliar principals
• CloudTrail events from unexpected IAM roles, regions, or IP addresses
• KMS kms:Decrypt events from roles that should not be accessing a table
• ThrottledRequests that suggest unintended table scans
• PITR disabled events on production tables

For broader detection patterns and alert configuration, see Detecting Suspicious Activity in AWS.

DynamoDB Streams for audit and event-driven workflows

DynamoDB Streams capture every item-level change as an ordered sequence of records. Each record includes the item’s keys, the change type (INSERT, MODIFY, REMOVE), and optionally the item’s state before the change, after the change, or both.

Audit and compliance use cases:

• Retain a change history of every item modification for compliance records
• Build an immutable audit log by streaming changes to S3 or a data warehouse
• Detect and alert on unexpected item deletions by routing Stream records through Lambda

Application and event-driven use cases:

• Trigger a Lambda function when an order is placed to send a confirmation notification
• Keep a search index (OpenSearch, Elasticsearch) synchronised with table changes in near-real-time
• Invalidate downstream caches when underlying data is updated
• Fan out changes to multiple consumers without modifying the write path

# Enable Streams with both old and new item images
aws dynamodb update-table \
  --table-name Orders \
  --stream-specification StreamEnabled=true,StreamViewType=NEW_AND_OLD_IMAGES

# Get the Stream ARN to configure a Lambda trigger
aws dynamodb describe-table \
  --table-name Orders \
  --query 'Table.LatestStreamArn' \
  --output text

Minimum production hardening checklist

Apply these before a DynamoDB table receives production traffic:

1. Use least-privilege IAM roles. Grant only the actions each application actually needs. See Least-Privilege Access in AWS.
2. Scope permissions to specific tables and indexes. Never use Resource: "*". Always include table/TableName/index/* if GSIs are queried.
3. Use dynamodb:LeadingKeys conditions when multiple users share a table and should only see their own items.
4. Choose the right KMS key model. AWS-owned keys for most workloads. KMS when audit trails, key revocation, or compliance requirements apply.
5. Enable PITR on every production table. It is off by default and cannot recover data from before it was enabled.
6. Add a gateway VPC endpoint (free) to keep DynamoDB traffic within the AWS network. Attach an endpoint policy.
7. Enable CloudTrail monitoring. Management events are on by default. Enable data events for sensitive tables that require item-level access auditing.
8. Test the restore path. Run a PITR restore to a non-production table at least once before you need it under pressure.

When to use which controls

Not every table needs every control. Here is a practical decision guide.

When AWS-owned keys are enough: Internal application data with no external compliance requirement, where a key usage audit trail is not needed and key revocation is not part of your security posture. This is the right default for the majority of workloads.

When customer-managed KMS keys are justified: You need to demonstrate an audit trail of data access (HIPAA, PCI-DSS, ISO 27001), your policy requires customer-controlled key material, you need to revoke table access instantly by disabling the key, or the key must be shared across AWS accounts. Understand the consequence: disabling the key locks the table immediately.

When a VPC endpoint is worth adding: Any production workload running in a VPC where you want to keep DynamoDB traffic within the AWS network. Gateway endpoints are free and take minutes to set up. There is almost no reason to skip this for production tables.

When fine-grained IAM conditions are worth the complexity: A single DynamoDB table stores data belonging to multiple users or tenants and application-level row filtering is not sufficient for your threat model. dynamodb:LeadingKeys gives you database-level enforcement without separate tables per user.

When Streams should be enabled: Your application needs to react to data changes in near-real-time, you need an immutable change history, or you are replicating data to a downstream system. Do not enable Streams solely for security monitoring. Use CloudTrail for that.

Comparisons

Identity-based policies vs resource-based policies

Gateway endpoint vs interface endpoint for DynamoDB