/$0.50 per rule per month. $0.03 per million events. Enabling Contributor Insights on a single DynamoDB table auto-creates four rules so your floor is $2.00/month before a single event is counted.

At 500 million events/month, that's $17.00/month. At 5 billion, it's $152.00/month.

Whether that's justified depends on your traffic volume, whether you have hot key patterns, and what throttling is already costing you in wasted provisioned throughput.

What Is DynamoDB Contributor Insights?

Contributor Insights for DynamoDB is a CloudWatch monitoring feature that identifies the top partition keys driving read and write traffic on a table without any code-level instrumentation or custom application logging.

It analyzes request traffic in near real-time and publishes results as CloudWatch graphs. For tables with partition key skew, it answers the specific question a FinOps engineer needs: "Which partition key is causing throttling?"

The Two Pricing Components

Contributor Insights billing has exactly two line items on your CloudWatch invoice:

• Rule fee: $0.50 per rule per month, flat regardless of traffic
• Event fee: $0.03 per 1 million DynamoDB read/write events matched

How many rules does one table create?

Enabling on a single table auto-creates four rules:

• Most-accessed partition keys on the base table
• Most-accessed partition keys causing errors on the base table
• Most-accessed partition keys on each GSI
• Most-accessed partition keys causing errors on each GSI

Rule count formula: 2 + (2 × number of GSIs)

A table with no GSIs = $2.00/month in rule fees. A table with 3 GSIs = $4.00/month in rule fees, before any events.

What counts as an "event"?

Every read and write operation: GetItem, PutItem, UpdateItem, DeleteItem, BatchGetItem, BatchWriteItem (each item individually), Query and Scan (each item returned or examined), and transactional reads/writes. GSI operations are counted separately when rules are active on both.

Worked Cost Examples

10M events/month: $2.00 rule fee + $0.30 event fee = $2.30/month

500M events/month: $2.00 rule fee + $15.00 event fee = $17.00/month

2B events/month: $2.00 rule fee + $60.00 event fee = $62.00/month

2B events/month + 3 GSIs: $4.00 rule fee + $60.00 event fee = $64.00/month

For most workloads, the event fee is the variable that matters. The rule fee is fixed overhead.

Throttle-Only Mode

As of August 2025, AWS added a throttle-only mode. Rules only activate for events that result in throttling requests that exceed provisioned capacity or on-demand burst limits.

You still pay the $0.50/rule/month rule fee. But the event fee drops dramatically. On a well-provisioned table with a 0.1% throttle rate processing 2 billion events/month, you'd match roughly 2 million throttled events, an event cost of $0.06/month instead of $60.00/month.

Use throttle-only mode when:

• You only need to diagnose which keys are causing throttling, not which are most popular
• Your table is currently healthy and you want passive monitoring with near-zero cost
• You have a high-volume table (1B+ events/month) where full mode runs $30+/month

Use full mode when:

• You're actively investigating a hot key pattern
• You want continuous visibility into traffic distribution
• You're evaluating whether to restructure your partition key schema

If you're deciding between 1-year and 3-year AWS commitment terms before locking in Reserved Capacity, the tradeoffs are covered in detail here How to Choose Between 1-Year and 3-Year AWS Commitments

The Real Cost Question: What Does Hot Key Blindness Cost?

Contributor Insights costs $2 to $62/month. The cost of not having it shows up in your provisioned capacity bill every month.

DynamoDB provisioned capacity is distributed across partitions. If your table is configured for 10,000 RCUs/second and 90% of reads go to three partition keys, the capacity on your other partitions sits idle while those three keys throttle.

Common patterns where this happens:

• Low-cardinality partition keys (e.g., user_type, region, status)
• Popular cached items that expire simultaneously, causing a read surge on one key
• Time-based queries where all traffic clusters around "today" or "current"

A concrete scenario: a table provisioned at 5,000 WCUs/second costs approximately $2,847/month in write capacity (verify current rates at aws.amazon.com/dynamodb/pricing). If hot key throttling means 30% of that capacity is sitting idle on underutilized partitions, you're paying ~$854/month for throughput you can't use.

Contributor Insights at $17/month to identify which keys to redesign around: that's a 50:1 return in the month you act on it.

*Hot Keys and Reserved Capacity Commitments
*
This is where hot key detection connects directly to cost optimization strategy.

DynamoDB Reserved Capacity delivers 30–40% savings on provisioned throughput. But those savings assume your capacity is being utilized effectively. A table with undetected hot key patterns has two compounding problems:

• It's over-provisioned because teams add capacity to compensate for throttling instead of fixing the partition key design
• When you commit to Reserved Capacity on an over-provisioned table, you lock in the waste

The right sequence: identify hot keys via Contributor Insights → fix the partition key schema → right-size provisioned capacity → apply Reserved Capacity on that right-sized number. The result is a smaller commitment with higher utilization and 30–40% off the correct baseline.

Contributor Insights vs Standard CloudWatch Metrics

CloudWatch already provides DynamoDB metrics by default, at no charge. The key difference is specificity.

Standard CloudWatch metrics tell you "you have 50,000 throttled requests this hour." Contributor Insights tells you "partition key user#12345 accounts for 48,000 of those throttled requests."

For active troubleshooting or capacity planning, that distinction is the difference between guessing and acting.

When to Enable It

Enable Contributor Insights when:

• Your table experiences recurring throttling that standard metrics can't explain
• You're planning a table migration or partition key schema redesign
• Your table processes 100M+ events/month and you have no visibility into traffic distribution
• You're considering a Reserved Capacity commitment and want to validate utilization first

Use throttle-only mode when:

• You want passive monitoring with near-zero event costs
• Your table is healthy but you want early warning if hot keys develop

Skip it entirely when:

• You have very high cardinality partition keys (e.g., UUID-based) with no known skew
• You're on on-demand capacity mode with confirmed even traffic distribution
• The table is non-production with no Reserved Capacity commitment

How to Enable It

Prerequisites: IAM permissions for cloudwatch:EnableInsightRules and dynamodb:DescribeTable. Understand the event cost for your traffic volume before enabling full mode.

• Open the DynamoDB console and select your target table
• Go to the Monitor tab
• Click Manage Contributor Insights; select "All Requests" (full mode) or "Throttled Requests Only" (throttle-only mode)
• Navigate to CloudWatch > Contributor Insights and confirm the rules are in "Enabled" state
• Allow 15–30 minutes for data to appear; CloudWatch will show the top 10 partition keys by request volume

If rules show an "Error" state, the most common cause is insufficient IAM permissions. Verify the execution role includes cloudwatch:EnableInsightRules, cloudwatch:PutInsightRule, and dynamodb:DescribeTable.

How This Fits With Reserved Capacity

Identifying hot keys is a prerequisite to maximizing Reserved Capacity ROI. A table with hot key throttling shows a deceptive utilization signal: total consumed capacity may look high, but actual table-level efficiency is low because hot partitions throttle while cold partitions sit idle.

Usage.ai's Flex Reserved Instances handle DynamoDB Reserved Capacity commitments with no upfront payment, no multi-year lock-in, and a cashback guarantee if utilization falls short see how it works at usage.ai

Usage.ai refreshes DynamoDB recommendations every 24 hours, vs. the 72+ hour refresh cycle on AWS native tools. At DynamoDB pricing, that 3-day gap in detecting newly-emerged hot key patterns can represent meaningful daily waste before any action is taken.

Have you run into hot key issues on DynamoDB? Did you catch it via Contributor Insights or some other way and what did the fix end up looking like?

Explore the full operational breakdown here → DynamoDB Contributor Insights Pricing: Monitoring Hot Keys at a Cost