Operations & Cost
Modelling gets your data in. Operating it — keeping writes consistent, reacting to changes, expiring old rows, paying the right capacity bill, surviving a region outage, and recovering from a bad deploy — is the half that decides whether a DynamoDB table is something you trust in production.
This section is one running scenario, not six disconnected reference pages. You are building the audit log for a multi-tenant SaaS — the immutable record of "who did what, when" that every B2B product eventually has to ship for its enterprise customers. One table, partitioned per tenant:
| PK | SK | actor | action | ip |
|---|---|---|---|---|
| TENANT#acme | EVENT#2026-06-24T09:14Z#a1 | USER#88 | login.success | 203.0.113.7 |
| TENANT#acme | EVENT#2026-06-24T09:15Z#a2 | USER#88 | invoice.export | 203.0.113.7 |
| TENANT#globex | EVENT#2026-06-24T09:15Z#b9 | USER#12 | role.granted | 198.51.100.4 |
Every guide below adds one operational concern to this same table:
Read them in order — each assumes the table from the one before. Start with transactions; the rest build on the events it writes.
Download DynoTable to inspect, query, and edit the audit-log table as you work through the scenario.