DynoTable

DynamoDB RequestLimitExceeded

TL;DR — You exceeded an account/table-level request-rate quota, not a table's own provisioned capacity. On-demand tables default to 40,000 read request units and 40,000 write request units per second. Keep the SDK's backoff retries, raise the quota in Service Quotas if the traffic is real, and spread load so a single table/partition isn't the bottleneck.

What it means

RequestLimitExceeded: Throughput exceeds the current throughput limit for your account.

RequestLimitExceeded is one of the three throttling exceptions DynamoDB returns on the data plane (alongside ProvisionedThroughputExceededException and ThrottlingException). It signals you've hit an account- or table-level default quota rather than a per-table provisioned RCU/WCU ceiling. It returns HTTP 400 and is retryable — the SDKs back off and retry automatically.

Why it happens

  • On-demand table default ceiling — each on-demand table has a soft default of 40,000 read request units/sec and 40,000 write request units/sec. Bursting past that returns RequestLimitExceeded until the quota is raised.
  • Account throughput quota — the sum of provisioned capacity across your tables/indexes exceeds the account-level table-throughput quota in a region.
  • A newly on-demand table warming up — a fresh on-demand table (or one just switched to on-demand) instantly serves up to double its previous peak; a much larger spike beyond that can throttle before it scales.
  • A single hot table absorbing a traffic spike far above its recent peak.

How to fix it

  1. Keep exponential-backoff retries on — the SDK default handles transient spikes. Use adaptive retry mode for bursty workloads. Don't disable retries.
  2. Raise the quota — request an increase to the per-table on-demand throughput (or the account table-count/throughput quota) in Service Quotas if the traffic is legitimate and sustained.
  3. Pre-warm before a known spike — ramp traffic up rather than jumping straight to peak, so on-demand scaling keeps ahead of demand.
  4. Spread load — shard hot keys and distribute writes so one table/partition isn't carrying the whole spike (hot-partition patterns).
  5. Cache hot reads (DAX or an app cache) to shed read pressure below the ceiling.

FAQ

How is RequestLimitExceeded different from ProvisionedThroughputExceededException? ProvisionedThroughputExceededException means a provisioned-capacity table exceeded its own configured RCU/WCU. RequestLimitExceeded means you hit an account- or table-level request-rate quota — most often the on-demand default of 40,000 read and 40,000 write request units per second — regardless of a single table's per-table setting.

Is RequestLimitExceeded retryable? Yes. It's a throttling error and the AWS SDKs retry it automatically with exponential backoff. Persistent occurrences mean you need a quota increase or to spread load, not more retries.

Console olmadan DynamoDB ile çalışın

DynoTable, DynamoDB için hızlı bir masaüstü istemcisidir — tablolara göz atın, SQL tarzı sorgular çalıştırın ve item'ları yerel olarak düzenleyin.

İndirFiyatlandırmayı görüntüle