DEA-C01 Practice Question 33: Kinesis Enhanced Fan Out

Default consumers share a shard's read capacity: read throughput is "fixed at a total of 2 MB/sec per shard. If there are multiple consumers reading from the same shard, they all share this throughput." Four consumers on the same shards therefore contend, which is why adding the fourth one pushed everybody into read throttling and rising iterator age. Enhanced fan-out gives each registered consumer "its own read throughput per shard, up to 2 MB/sec, independently of other consumers", and Kinesis pushes records over HTTP/2 with SubscribeToShard instead of being polled. Propagation delay drops too ("typically an average of 70 ms whether you have one consumer or five consumers") which is the near-real-time requirement. None of this changes the shard count.

Option A works around the symptom at the wrong layer and is explicitly excluded by the stem. It also does not scale with consumers: adding a fifth application would put the four back into contention and require yet another reshard.

Option B builds a fan-out tier by hand. It adds a hop of latency, an SQS bill proportional to the record count, ordering loss, and a new single point of failure, the relay consumer, which is still subject to the same shared 2 MB/sec limit.

Option C increases the pressure that is causing the exceptions. The 2 MB/sec ceiling is per shard, not per call; polling harder or in larger batches simply hits the limit more often and generates more throttling.

Reference: Develop enhanced fan-out consumers with dedicated throughput