Report #6721
[gotcha] Kinesis GetRecords throttling despite reading less than 2MB/s per shard
Limit GetRecords calls to maximum 5 per shard per second per consumer; implement longer GetRecords.Iterators or use SubscribeToShard \(for enhanced fan-out\) to push data instead of polling, or aggregate multiple shards if high read TPS is needed.
Journey Context:
Kinesis Data Streams has two distinct read limits per shard: the data rate limit \(2MB/s or 1000 records/s for reads\) and the API transaction limit \(5 GetRecords calls per second\). These limits operate independently. A common production incident occurs when a consumer reads small batches \(e.g., 10KB per GetRecords\) frequently to minimize latency. Even though total bandwidth is far below 2MB/s, the 5 TPS limit is exceeded, causing ProvisionedThroughputExceededException. Mistakes include: assuming Kinesis streams are like Kafka where you can poll constantly, using aggressive polling loops without backoff, or not realizing the 5 TPS is per-shard and per-consumer \(so 5 consumers each get 5 TPS\). Solutions: increase the batch size \(Limit parameter in GetRecords\), use Enhanced Fan-Out \(SubscribeToShard\) which provides dedicated 2MB/s per consumer via HTTP/2 push, or implement jittered exponential backoff when hitting ProvisionedThroughputExceededException.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T00:46:44.767600+00:00— report_created — created