DynamoDB Monitoring
Monitoring shows how a DynamoDB table behaves in production. Metrics reveal traffic levels, slow responses, throttled requests, and rising errors. A team that watches these signals fixes problems before users notice them.
The Car Dashboard Picture
A car dashboard shows speed, fuel level, and engine warnings. A driver who ignores the dashboard discovers trouble only after the engine stops. DynamoDB monitoring offers the same view for your database. Amazon CloudWatch acts as the dashboard, and alarms act as the warning lights.
Amazon CloudWatch Metrics
DynamoDB publishes metrics to CloudWatch automatically. No setup is required. The service reports most metrics at one-minute intervals.
| Metric | What It Tells You |
|---|---|
| ConsumedReadCapacityUnits | Read capacity your table uses |
| ConsumedWriteCapacityUnits | Write capacity your table uses |
| ProvisionedReadCapacityUnits | Read capacity you reserved (provisioned mode) |
| ThrottledRequests | Requests rejected for exceeding capacity |
| ReadThrottleEvents and WriteThrottleEvents | Individual throttled read and write events |
| SuccessfulRequestLatency | Time DynamoDB needs to answer a request |
| SystemErrors | Server-side failures (HTTP 500 range) |
| UserErrors | Client-side failures (HTTP 400 range) |
| ConditionalCheckFailedRequests | Writes blocked by a failed condition |
| TimeToLiveDeletedItemCount | Items removed by TTL |
| ReplicationLatency | Delay between replicas in a global table |
Reading the Key Signals
Capacity Usage
Compare consumed capacity with provisioned capacity. Consumption near 80 percent of the reserved amount signals the need for more capacity or auto scaling.
Throttling
A throttled request means DynamoDB refused work because capacity ran out. Rising throttle metrics with low overall consumption point to a hot partition.
Latency
Single-item operations normally finish in single-digit milliseconds. Queries over large result sets take longer. A sudden jump in latency deserves investigation.
Errors
UserErrors increase when applications send invalid requests. SystemErrors point to a service-side problem, and the SDK retries those automatically in most cases.
Diagram: From Metric to Action
DynamoDB table
│ publishes metrics every minute
▼
CloudWatch
│ evaluates alarm rule
▼
Alarm: WriteThrottleEvents > 0 for 5 minutes
│
▼
Amazon SNS notification
│
▼
Team receives email or chat message and investigates
Creating Useful Alarms
Alarms turn raw numbers into alerts. A small set of alarms covers most needs:
- ThrottledRequests above zero for several minutes
- ConsumedWriteCapacityUnits above 80 percent of the provisioned amount
- SystemErrors above zero
- SuccessfulRequestLatency above your application's limit
- ReplicationLatency above your acceptable delay (global tables only)
CloudWatch Contributor Insights
Contributor Insights identifies the keys that generate the most traffic. The report lists the most accessed partition keys and the most throttled keys. A single dominant key confirms a hot partition and shows exactly which key to redesign.
AWS CloudTrail
CloudTrail records who called which DynamoDB operation and when. Control-plane actions such as CreateTable and DeleteTable appear in CloudTrail by default. Data-plane actions such as GetItem and PutItem need data event logging, which you enable separately. Security teams rely on these records during audits.
Metrics for Different Table Modes
Provisioned tables and on-demand tables need slightly different attention. A provisioned table needs a close watch on consumed capacity against the reserved amount, because crossing that line causes throttling. An on-demand table scales automatically, so the focus shifts to latency, errors, and the monthly cost that grows with request volume. Both modes benefit from throttle alarms, since sudden traffic spikes can briefly exceed what DynamoDB has prepared for.
Building a Simple Dashboard
A CloudWatch dashboard gathers the most useful graphs on one screen. Place read and write consumption side by side, add a latency graph, and show a counter for throttled requests and errors. Keep the layout the same for every table so any team member can scan it in seconds. A consistent dashboard turns monitoring into a quick habit instead of a deep investigation.
Monitoring Routine
- Check the CloudWatch dashboard for each production table weekly.
- Review alarms after every traffic spike or release.
- Enable Contributor Insights on tables with uneven traffic.
- Store CloudTrail logs in a protected S3 bucket.
- Record normal metric ranges so unusual values stand out.
Summary
- DynamoDB sends metrics to CloudWatch automatically.
- Capacity, throttling, latency, and errors form the core signals.
- Alarms deliver warnings through SNS before users feel the problem.
- Contributor Insights finds hot keys, and CloudTrail records API activity.