DynamoDB Security and IAM
Securing a DynamoDB table means controlling who can access it, what they can do, how the data is encrypted, and how activity is monitored. AWS provides multiple security layers for DynamoDB, all of which work together to protect your data.
Layer 1: IAM — Access Control
AWS Identity and Access Management (IAM) is the gatekeeper for all AWS services, including DynamoDB. Every API call to DynamoDB must include AWS credentials. IAM checks those credentials against attached policies to decide whether the operation is allowed.
How IAM Works
Application → API Call: PutItem on Orders table
↓
IAM checks: Does this identity have permission?
↓
Yes → Operation proceeds
No → AccessDeniedException returned
IAM Policy Structure
An IAM policy is a JSON document with rules. Each rule has an Effect (Allow or Deny), Actions (what operations), and Resources (which tables or indexes).
Example Policy: Allow read-only access to the Orders table
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:GetItem",
"dynamodb:Query",
"dynamodb:Scan"
],
"Resource": "arn:aws:dynamodb:ap-south-1:123456789:table/Orders"
}
]
}
This policy allows reads but blocks all writes (PutItem, UpdateItem, DeleteItem) on the Orders table.
IAM Principle of Least Privilege
Grant only the minimum permissions required. An application that only reads product data should only have GetItem and Query permissions — not DeleteItem or CreateTable. This limits the blast radius if credentials are compromised.
Fine-Grained Access Control
DynamoDB supports attribute-level access control using IAM condition keys. You can restrict an IAM identity to reading only specific attributes within an item, or to accessing items where a specific attribute matches their own user ID.
Example: Users Can Only Read Their Own Data
IAM Condition:
"dynamodb:LeadingKeys": ["${aws:PrincipalTag/UserID}"]
Effect: A user with tag UserID="U001" can only access items
where the partition key = "U001". They cannot read U002's data.
This is called fine-grained access control — powerful for multi-tenant applications where users must only see their own records.
Layer 2: Encryption at Rest
All DynamoDB data is encrypted at rest by default. You do not need to configure anything — encryption happens automatically. The question is which key manages the encryption.
Three Encryption Options
| Option | Key Owner | Best For |
|---|---|---|
| AWS Owned Key (default) | AWS manages the key | Default; no cost; no control needed |
| AWS Managed Key | Stored in your AWS KMS; AWS rotates it | Audit key usage in CloudTrail |
| Customer Managed Key (CMK) | You create and manage the key in KMS | Compliance requiring key ownership |
For regulated industries (healthcare under HIPAA, finance under PCI-DSS), using a Customer Managed Key gives you proof of key ownership and the ability to revoke access instantly by disabling the key.
Layer 3: Encryption in Transit
All communication between your application and DynamoDB uses HTTPS (TLS encryption). Data traveling over the network between your servers and DynamoDB endpoints is always encrypted. You cannot disable this.
Layer 4: VPC Endpoints
By default, DynamoDB is a public AWS endpoint accessible over the internet. A VPC Endpoint for DynamoDB routes all traffic between your AWS resources (EC2, Lambda) and DynamoDB through the private AWS network — never over the public internet.
Without VPC Endpoint: EC2 (private VPC) → Internet Gateway → Public internet → DynamoDB endpoint With VPC Endpoint: EC2 (private VPC) → Private AWS network → DynamoDB endpoint (Traffic never leaves AWS infrastructure)
This eliminates exposure to internet-based attacks and often reduces data transfer costs.
Layer 5: CloudTrail Audit Logging
AWS CloudTrail records every API call made to DynamoDB — who called it, when, from which IP address, and what parameters were passed. This creates an immutable audit trail for compliance and security investigations.
CloudTrail log entry example:
{
"eventTime": "2024-06-01T14:22:31Z",
"eventName": "DeleteItem",
"userAgent": "aws-cli/2.0",
"sourceIPAddress": "203.0.113.22",
"requestParameters": {
"tableName": "Orders",
"key": { "OrderID": "ORD999" }
}
}
If an item is deleted unexpectedly, CloudTrail tells you exactly who deleted it and when.
Resource-Based Policies
In addition to IAM policies attached to users or roles, DynamoDB supports resource-based policies attached directly to a table. These are useful for cross-account access — allowing a Lambda function in another AWS account to access your DynamoDB table without sharing credentials.
Security Best Practices Summary
| Practice | Why It Matters |
|---|---|
| Least privilege IAM policies | Reduces damage from compromised credentials |
| Fine-grained access control | Users see only their own data |
| Use Customer Managed Keys for CMK | Full control and compliance for regulated data |
| Enable VPC Endpoints | Keeps traffic on the private AWS network |
| Enable CloudTrail logging | Full audit trail of all API calls |
| Enable PITR | Recovers from accidental data loss |
| Never use root account credentials | Root access is all-powerful and hard to restrict |
| Rotate access keys regularly | Limits the lifespan of compromised credentials |
