How DynamoDB Burst Capacity Works and When It Runs Out (2026)

DynamoDB’s burst capacity is a hidden superpower that lets you handle sudden traffic spikes without a manual intervention, but it’s also the silent killer of performance if you don’t understand its limits.

Let’s see it in action. Imagine a simple GetItem operation on a table.

{
  "TableName": "MyExampleTable",
  "Key": {
    "UserID": {"S": "user123"}
  },
  "ProjectionExpression": "email, registrationDate"
}

When this request hits DynamoDB, it consumes Read Capacity Units (RCUs). If your provisioned throughput is 10 RCUs, you can sustain 10 reads per second. But what if suddenly 100 users hit your user123 record simultaneously? This is where burst capacity kicks in.

DynamoDB allocates a "burst bucket" for each table. This bucket can accumulate unused RCU capacity from previous seconds. The maximum capacity of this bucket is 3000 RCUs. So, if you’ve been provisioned for 10 RCUs and only used 5 in the last second, you’ve banked 5 RCUs in your burst bucket. The next second, you could theoretically burst up to your provisioned capacity (10 RCUs) plus your banked capacity (5 RCUs), totaling 15 RCUs. This continues, up to the 3000 RCU limit.

The problem arises when your traffic consistently exceeds your provisioned capacity for extended periods. Each second, DynamoDB checks your provisioned throughput and your consumed throughput.

• If Consumed < Provisioned: The difference is added to your burst bucket, up to 3000 RCUs.
• If Consumed > Provisioned: DynamoDB first uses your provisioned capacity. Then, it draws from your burst bucket. If your burst bucket is empty, you get a ProvisionedThroughputExceededException.

Consider this scenario: you’ve provisioned 100 RCUs for your table.

• Second 1: You use 50 RCUs. (100 - 50 = 50 banked. Bucket: 50/3000)
• Second 2: You use 70 RCUs. (100 - 70 = 30 banked. Bucket: 50 + 30 = 80/3000)
• Second 3: You use 150 RCUs.
  • DynamoDB uses your provisioned 100 RCUs.
  • It needs another 50 RCUs. It draws 50 from the bucket.
  • Bucket is now 80 - 50 = 30/3000. No exception.
• Second 4: You use 150 RCUs again.
  • DynamoDB uses your provisioned 100 RCUs.
  • It needs another 50 RCUs. It draws 30 from the bucket.
  • Bucket is now empty.
• Second 5: You use 150 RCUs again.
  • DynamoDB uses your provisioned 100 RCUs.
  • It needs another 50 RCUs.
  • The burst bucket is empty.
  • Exception: ProvisionedThroughputExceededException is thrown.

The most common mistake is assuming burst capacity will save you from sustained high traffic. It’s designed for spikes, not plateaus. If your application exhibits consistent traffic patterns that are higher than your provisioned throughput, you’re going to hit the ceiling.

The critical lever you control is ReadCapacityUnits (or WriteCapacityUnits). If you’re seeing ProvisionedThroughputExceededException frequently, especially for traffic that isn’t a sudden, brief spike, it’s time to increase this value. For example, if you’re seeing consistent 150 RCUs of usage and getting exceptions, you should provision at least 150 RCUs.

The next thing you’ll encounter is understanding how this applies to WriteCapacityUnits and the nuances of provisioned vs. on-demand modes.