Kinesis Shards Have Two Independent Ceilings
A Kinesis shard caps out at 1 MB/s or 1,000 records/second for writes, whichever you hit first — the two limits are independent, not combined. This calculator computes both and takes the larger: shardsByData = ceil(ingestMBps / 1) and shardsByRecords = ceil(recordsPerSec / 1000), where recordsPerSec = (ingestMBps × 1024) / recordSizeKB. Small, chatty records blow the 1,000/s ceiling long before they saturate the 1 MB/s throughput ceiling: 5,000 records/sec of 200-byte payloads is under 1 MB/s of raw data, yet still needs 5 shards on the record-count limit alone.
Standard Consumers Share a 2 MB/s Read Ceiling Per Shard
Each shard offers 2 MB/s of aggregate read throughput to Standard consumers polling via GetRecords. Once more than about two consumer applications read the same shard, they compete for that 2 MB/s and start throwing ReadProvisionedThroughputExceeded exceptions — which is exactly the condition this tool's warning banner checks for (consumers > 2 with EFO disabled).
Enhanced Fan-Out Trades Read Contention for Multiplicative Billing
- Per-consumer shard-hours: EFO bills
consumers × shards × $0.015/hour, so adding a fifth analytics consumer to a 20-shard stream adds a fifth full copy of your shard-hour cost, not a fraction of it. - Data retrieved: on top of that, EFO charges $0.013/GB for every GB each registered consumer pulls, calculated here as ingest rate × time × consumer count.
- Net effect: EFO removes the 2 MB/s read contention problem entirely (each consumer gets its own 2 MB/s pipe via HTTP/2 push) but the bill scales with consumer count, not just shard count — worth checking before enabling it for more than a couple of high-volume readers.