A company uses Amazon Kinesis Data Streams to ingest clickstream data. The data is consumed by a custom consumer application that writes to Amazon S3 every 5 minutes. The consumer is falling behind and processing lag is increasing. Which action is MOST effective to reduce the lag?
More shards increase parallelism and throughput, allowing the consumer to keep up.
Why this answer
The consumer is falling behind because the stream's throughput capacity is insufficient for the incoming data volume. Increasing the number of shards in the Kinesis stream directly increases the total read capacity (each shard provides 2 MB/s read throughput and 5 transactions/second), allowing the consumer to process more data in parallel and reduce lag.
Exam trap
The trap here is that candidates often confuse throughput scaling with batch size or delivery destination changes, but the only way to increase read throughput from a Kinesis stream is to increase the number of shards or use enhanced fan-out.
How to eliminate wrong answers
Option A is wrong because switching to Kinesis Data Firehose does not change the underlying stream's throughput; Firehose is a delivery service that still reads from the same shards, so it would not resolve the consumer's processing lag. Option B is wrong because increasing the batch size written to S3 only affects the write operation to S3, not the consumer's ability to read from the stream faster; the bottleneck is the consumer's read throughput, not the S3 write batch size. Option D is wrong because reducing the retention period (default 24 hours to 1 hour) does not increase read throughput; it only causes data to expire sooner, which could lead to data loss but does not help the consumer catch up.