DynamoDB Security: IAM Fine-Grained Access, KMS and VPC Endpoints

By Ravindra Bagale, trainer · LinkedIn · Last updated: 31 October 2026

1. Everyday example: hotel key cards

A master key opens every room — that is a wild IAM * on DynamoDB. A guest card opens one room — that is LeadingKeys on TENANT#acme. The lock cylinder is KMS. The private lift that never goes through the lobby is a VPC endpoint. Meera Joshi (Pune clinic) gives each ward app a card for PATIENT#wardA only.

2. Vertical steps

3. Why do we need this?

Why do we need this?

Stolen access keys, over-broad roles, and public network paths turn a good table into a data leak. Fine-grained IAM stops cross-tenant reads. KMS controls who can decrypt. VPC endpoints keep traffic off the public internet. Without these, modeling and transactions still leak.

4. What is it?

What is it?

IAM: identity policies on roles/users for dynamodb:GetItem, Query, PutItem, and index ARNs. Fine-grained access: condition keys like dynamodb:LeadingKeys so PK must start with a tenant prefix. KMS: SSE-DynamoDB (AWS owned) or SSE-KMS with your CMK. VPC gateway endpoint: private route from VPC to DynamoDB without NAT/IGW.

5. How to do it (step by step)

How to do it (step by step)

1. List who reads/writes which table and GSI — no * unless break-glass.
2. Scope Resource to table ARN and /index/* you need.
3. For multi-tenant: add StringLike dynamodb:LeadingKeys TENANT#id.
4. Enable encryption: default AWS owned, or CMK when you need key policy + rotation proof.
5. Create vpc endpoint dynamodb gateway; update route tables.
6. Deny dynamodb: via public path in SCPs if your org requires private only.
7. Test with a second role that should fail cross-tenant GetItem.

6. IAM policy sketch (LeadingKeys)

{
  "Effect": "Allow",
  "Action": ["dynamodb:GetItem","dynamodb:Query","dynamodb:PutItem","dynamodb:UpdateItem"],
  "Resource": [
    "arn:aws:dynamodb:ap-south-1:111122223333:table/lab-ddr-secure",
    "arn:aws:dynamodb:ap-south-1:111122223333:table/lab-ddr-secure/index/*"
  ],
  "Condition": {
    "ForAllValues:StringLike": {"dynamodb:LeadingKeys": ["TENANT#acme"]}
  }
}
# Meaning: role may only touch items whose PK begins with TENANT#acme.

Pair with app code that always prefixes PK. UI filters are not security — IAM is.

7. KMS and encryption at rest

• SSE-DynamoDB (default): AWS owns the key; simplest.
• SSE-KMS CMK: you own key policy, rotation, CloudTrail on Decrypt.
• Encrypts table, LSI, GSI, streams, backups at rest.
• In-transit: HTTPS/TLS to the DynamoDB API (and PrivateLink/endpoint path).

8. VPC gateway endpoint

Gateway endpoint for com.amazonaws.region.dynamodb adds a prefix list route. No security group on gateway endpoints — use endpoint policy to limit which principals/tables. Apps in private subnets reach DynamoDB without a NAT gateway for that traffic.

9. Commands with output and meaning

aws dynamodb create-table --table-name lab-ddr-secure   --attribute-definitions AttributeName=PK,AttributeType=S AttributeName=SK,AttributeType=S   --key-schema AttributeName=PK,KeyType=HASH AttributeName=SK,KeyType=RANGE   --billing-mode PAY_PER_REQUEST   --sse-specification Enabled=true,SSEType=KMS
# Output: TableStatus CREATING; SSEDescription present when active
aws dynamodb describe-table --table-name lab-ddr-secure   --query 'Table.SSEDescription'
# Output: Status ENABLED, SSEType KMS — meaning encryption at rest on
aws ec2 create-vpc-endpoint --vpc-id vpc-0abc --service-name com.amazonaws.ap-south-1.dynamodb   --route-table-ids rtb-0xyz --vpc-endpoint-type Gateway
# Output: VpcEndpointId vpce-… State available — private path ready

create-table with SSE KMS turns encryption on. describe proves it. create-vpc-endpoint makes the private route. Always delete lab tables and endpoints after practice.

10. Industry stories

• SaaS (Layla Hassan, Dubai): LeadingKeys per tenant role; stolen token cannot read other tenants.
• Bank (Arjun Mehta, Pune): CMK + key policy only payment role Decrypt; CloudTrail on misuse.
• Health (Meera Joshi): ward roles LeadingKeys PATIENT#wardX; VPC endpoint only.
• Retail (Diego Alvarez): separate IAM for batch export role vs online API role.
• IoT (Mei Lin): device writer role PutItem only; no Scan.
• Gaming (Carlos Rivera): score writer vs admin reader different policies.

11. Lab

How to do it (step by step)

1. Create lab-ddr-secure on-demand with SSE KMS (AWS managed key ok for lab).
2. Put TENANT#acme / ITEM#1 and TENANT#beta / ITEM#1.
3. Attach a role with LeadingKeys TENANT#acme; confirm beta GetItem fails.
4. Optional: create DynamoDB gateway endpoint in a lab VPC.
5. Delete table (and endpoint if created).

Cleanup (stop billing)

1. Delete lab-ddr-secure.
2. Delete lab VPC endpoint if you made one.
3. Confirm describe-table fails (ResourceNotFound).

12. Ops checklist before you ship

1. Confirm TTL attribute name and units (epoch seconds).
2. Decide soft-delete vs hard-delete vs archive-to-S3.
3. Enable PITR on any table you cannot rebuild from source.
4. Document RPO/RTO and who runs restore drills.
5. If multi-region: pick write stickiness and conflict rules.
6. If DAX: prove cache-miss path and warm-up plan.
7. Tag Owner + Expiry on every lab resource.
8. Budget alert in the account before load tests.

13. Copy-paste DynamoDB CLI starters (batch 2)

export AWS_DEFAULT_REGION=ap-south-1

# TTL status
aws dynamodb describe-time-to-live --table-name ShopApp

# PITR / continuous backups
aws dynamodb describe-continuous-backups --table-name ShopApp

# On-demand backup
aws dynamodb create-backup --table-name ShopApp --backup-name lab-shop-$(date +%Y%m%d)

# List backups
aws dynamodb list-backups --table-name ShopApp

# Global table description (v2)
aws dynamodb describe-table --table-name ShopApp --query 'Table.Replicas'

14. More industry stories

• Retail (Aisha Khan, Dubai): TTL clears abandoned carts; soft-delete keeps 30-day undo.
• Bank (Lucas Meyer, Berlin): PITR on ledger table; restore drill every quarter.
• Travel (Omar Haddad, Amman): Global Tables for catalog reads; inventory writes sticky.
• Gaming (Carlos Rivera, Mexico City): DAX for hot profile Gets; never cache money ledgers.
• Social (Priya Nair, Kochi): adjacency edges for follows; sparse GSI for unread inbox.
• IoT (Mei Lin, Shenzhen): device#day PK + TTL 14 days; rollups to S3.

15. Glossary (batch 2)

16. Practice: explain out loud

1. 60s: TTL vs soft-delete vs S3 archive.
2. 60s: PITR vs on-demand backup.
3. 60s: when Global Tables help and hurt.
4. 60s: DAX consistency trade-off.
5. 60s: CartLite checkout keys in one breath.
6. 60s: follow edge vs feed item.
7. Record once; cut filler; record again.

17. Safe lab hygiene

• Use ap-south-1 labs with a budget alert.
• Prefix lab tables with lab- and your initials.
• Delete replicas, DAX clusters, and backups you created for labs.
• Never enable Global Tables on production without a write plan.
• Tag every resource Owner + Expiry.
• Export/import labs can create large S3 bills — delete prefixes.

18. How this set links other chapters

• Data modeling — keys we reuse in projects.
• Transactions — checkout and seat patterns.
• Streams + Lambda — fan-out and CDC.
• CRUD survey — short TTL note we deepen.
• What Is DynamoDB? — intro.

19. Delete / archive decision pad

20. Ten oral drill questions

1. What units does DynamoDB TTL use?
2. Does TTL delete instantly?
3. PITR window typical length?
4. Global Tables conflict default?
5. When sticky writes matter?
6. DAX vs API Gateway cache?
7. Cart PK for a shopper?
8. Order lines under which PK?
9. Follow edge SK example?
10. Unread inbox sparse GSI idea?

21. RPO / RTO mini workshop

1. Write the worst data loss you can accept (RPO) in minutes.
2. Write how long restore may take (RTO) before business pain.
3. Map: on-demand backup vs PITR vs multi-region replica.
4. Schedule a restore drill on a lab table this month.
5. Name the person who runs the drill.

22. Cost watch list (batch 2)

• PITR storage and on-demand backup storage.
• Global Tables: replicated WCUs in every region.
• DAX node hours even at idle.
• Export to S3 + S3 storage + Athena later.
• Streams + Lambda still bill during TTL deletes.

23. Project Definition of Done

1. Access patterns written and peer-reviewed.
2. Sample items drawn for happy path + one failure.
3. Lab table created, exercised, deleted (or tagged Expiry).
4. At least one conditional write or transaction exercised.
5. Cleanup commands pasted in your notes.
6. One interview answer recorded out loud.

24. Cross-links inside this batch

• TTL hygiene → Backup/PITR for “oops” recovery.
• Global Tables → sticky writes from capacity/hot lessons.
• DAX → only after Query shapes are correct.
• P1 CartLite reuses modeling + transactions.
• P2 Social reuses adjacency + Streams ideas.

25. Quick self-check (yes/no)

1. I can explain TTL delay vs instant DeleteItem.
2. I know when soft-delete beats hard delete.
3. I can start PITR and say what restore costs in time.
4. I can name one reason NOT to use Global Tables.
5. I know DAX does not fix a bad partition key.
6. I can sketch CartLite USER# and ORD# keys.
7. I can sketch a follow edge item.
8. I delete lab replicas/DAX/backups the same day.

26. Common errors and fixes

Each row is a real mistake students and juniors hit. Read the fix before you panic.

27. Troubleshooting checklist

1. AccessDeniedException: check action, ARN, LeadingKeys.
2. ValidationException on condition: PK must be single value string for LeadingKeys.
3. SSE not showing: wait CREATING; re-describe.
4. Endpoint created but still public: route table not associated.
5. CMK AccessDenied on backup/export: grant key to that role too.

28. FAQ

Revision, interview and comparison cards

Revise this lesson in a few minutes. Save the cards on your phone or download them as PNG files. The QR code on each card opens this lesson.

More cards: Ravi Sir's Cards.