CloudWatch metrics help you see how your DynamoDB tables are working. They show if your database is healthy and fast.
CloudWatch metrics for DynamoDB
aws cloudwatch get-metric-statistics \ --namespace AWS/DynamoDB \ --metric-name <MetricName> \ --dimensions Name=TableName,Value=<YourTableName> \ --start-time <StartTime> \ --end-time <EndTime> \ --period <PeriodInSeconds> \ --statistics <StatisticType>
Replace <MetricName> with the metric you want, like ConsumedReadCapacityUnits.
Use the TableName dimension to specify which table you want metrics for.
aws cloudwatch get-metric-statistics \ --namespace AWS/DynamoDB \ --metric-name ConsumedReadCapacityUnits \ --dimensions Name=TableName,Value=MyTable \ --start-time 2024-04-01T00:00:00Z \ --end-time 2024-04-01T01:00:00Z \ --period 300 \ --statistics Average
aws cloudwatch get-metric-statistics \ --namespace AWS/DynamoDB \ --metric-name ThrottledRequests \ --dimensions Name=TableName,Value=MyTable \ --start-time 2024-04-01T00:00:00Z \ --end-time 2024-04-01T01:00:00Z \ --period 60 \ --statistics Sum
This command fetches the average write capacity units consumed by the DynamoDB table named 'ExampleTable' in 5-minute intervals over 15 minutes.
aws cloudwatch get-metric-statistics \ --namespace AWS/DynamoDB \ --metric-name ConsumedWriteCapacityUnits \ --dimensions Name=TableName,Value=ExampleTable \ --start-time 2024-06-01T00:00:00Z \ --end-time 2024-06-01T00:15:00Z \ --period 300 \ --statistics Average
CloudWatch metrics update every minute, so recent data might not be available immediately.
You can use these metrics to create alarms that notify you if your table is overused or underused.
Common metrics include ConsumedReadCapacityUnits, ConsumedWriteCapacityUnits, ThrottledRequests, and SuccessfulRequestLatency.
CloudWatch metrics show how your DynamoDB tables perform over time.
You use AWS CLI or SDKs to get these metrics by specifying the metric name and table.
Monitoring these helps keep your database fast and reliable.
Practice
ConsumedReadCapacityUnits for a DynamoDB table represent?Solution
Step 1: Understand the metric name
ConsumedReadCapacityUnitsclearly indicates it measures read capacity units consumed.Step 2: Relate to DynamoDB usage
Read capacity units measure how many read operations the table performs, so this metric tracks usage over time.Final Answer:
The number of read capacity units consumed by the table over a period -> Option AQuick Check:
ConsumedReadCapacityUnits = Read usage [OK]
- Confusing read capacity with write capacity
- Thinking it measures item count or storage size
- Assuming it shows total capacity, not consumed
ThrottledRequests metric for a DynamoDB table named Orders?Solution
Step 1: Identify correct AWS CLI service and command
CloudWatch metrics useaws cloudwatch get-metric-statisticsto retrieve metric data.Step 2: Check parameters for metric retrieval
aws cloudwatch get-metric-statistics --metric-name ThrottledRequests --namespace AWS/DynamoDB --dimensions Name=TableName,Value=Orders --start-time 2024-01-01T00:00:00Z --end-time 2024-01-01T01:00:00Z --period 60 --statistics Sum correctly specifies metric name, namespace, dimensions (table name), time range, period, and statistics.Final Answer:
aws cloudwatch get-metric-statistics with correct parameters -> Option BQuick Check:
Useaws cloudwatch get-metric-statisticsfor metrics [OK]
- Using 'aws dynamodb' instead of 'aws cloudwatch'
- Missing required parameters like dimensions or time range
- Using commands that only list or describe metrics, not retrieve data
ConsumedWriteCapacityUnits metric of a DynamoDB table:{"Datapoints": [{"Timestamp": "2024-06-01T12:00:00Z", "Sum": 150}], "Label": "ConsumedWriteCapacityUnits"}What does the value 150 represent?
Solution
Step 1: Understand the metric and statistic
The metric isConsumedWriteCapacityUnitsand the statistic isSum, meaning total units consumed.Step 2: Interpret the value 150
150 is the sum of write capacity units consumed during the time period ending at the timestamp.Final Answer:
The total number of write capacity units consumed during the specified period -> Option DQuick Check:
Sum of consumed write units = 150 [OK]
- Confusing sum with average or max
- Thinking it shows capacity limits instead of usage
- Mixing write capacity with throttled requests
ReadThrottleEvents metric for your DynamoDB table Users but got an error:aws cloudwatch get-metric-statistics --metric-name ReadThrottleEvents --namespace AWS/DynamoDB --dimensions TableName=Users --start-time 2024-06-01T00:00:00Z --end-time 2024-06-01T01:00:00Z --period 60 --statistics Sum
What is the error and how do you fix it?
Solution
Step 1: Check dimension syntax in AWS CLI
The correct syntax for dimensions is--dimensions Name=TableName,Value=Users, not justTableName=Users.Step 2: Fix the command by correcting dimensions
Replace--dimensions TableName=Userswith--dimensions Name=TableName,Value=Usersto fix the error.Final Answer:
The dimension syntax is incorrect; use --dimensions Name=TableName,Value=Users -> Option CQuick Check:
Dimensions need Name and Value keys [OK]
- Using incorrect dimension syntax without Name= and Value=
- Confusing metric names that don't exist
- Incorrect date/time format for start-time
ThrottledRequests metric exceeds 5 in any 5-minute period. Which combination of CloudWatch metric and alarm configuration is correct?Solution
Step 1: Identify correct metric for throttled requests
The metricThrottledRequeststracks throttling events, so it is the right choice.Step 2: Choose appropriate statistic and period
Sum over 300 seconds (5 minutes) aggregates total throttled requests in that period, matching the alarm condition.Step 3: Set alarm threshold correctly
Alarm triggers if sum exceeds 5, matching the requirement.Final Answer:
Use metric ThrottledRequests with statistic Sum over 300 seconds period, alarm threshold > 5 -> Option AQuick Check:
Sum over 5 minutes > 5 throttled requests triggers alarm [OK]
- Using wrong metric like ConsumedReadCapacityUnits
- Choosing Average or Maximum instead of Sum for count
- Setting period too short to capture throttling spikes
Ready to prove it?
Pass the test and this pattern moves unknown
