A retail company runs an e-commerce platform on AWS. They have a Data Engineering team that processes clickstream data using Amazon Kinesis Data Streams (KDS) with a shard count of 5. The data is consumed by an AWS Lambda function that transforms and loads the data into an Amazon S3 bucket partitioned by year/month/day/hour. Recently, the team has noticed that the Lambda function is experiencing throttling errors, and the KDS shard iterator age is increasing, indicating that the consumer cannot keep up with the incoming data rate. The team has already increased the Lambda reserved concurrency to 1000 and enabled batch window of 60 seconds. The metrics show that the Lambda function duration is well under the 5-minute timeout, and there are no errors in the transformation logic. The S3 write operations are not failing. Which course of action would MOST effectively resolve the issue without unnecessary cost or complexity?
More shards allow more concurrent Lambda invocations, improving throughput and reducing iterator age.
Why this answer
The core issue is that the Lambda consumer cannot keep up with the incoming data rate, as evidenced by the increasing shard iterator age. Increasing the shard count from 5 to 20 directly increases the number of Kinesis Data Streams shards, which in turn increases the number of concurrent Lambda invocations (one per shard) and the overall throughput of the stream. This addresses the bottleneck at the source without adding unnecessary complexity or cost, as KDS pricing is based on shard hours and Lambda concurrency is already set to 1000.
Exam trap
The trap here is that candidates often assume increasing Lambda concurrency or batch window will solve throughput issues, but they fail to recognize that Kinesis shard count is the fundamental limiter of parallelism in the Lambda-Kinesis integration.
How to eliminate wrong answers
Option B is wrong because increasing Lambda reserved concurrency to 5000 does not help when the bottleneck is the number of Kinesis shards; Lambda can only process one shard per concurrent invocation, and with only 5 shards, the maximum parallelism is 5, so additional concurrency is unused. Option C is wrong because increasing the batch window to 300 seconds would increase latency and could cause the shard iterator age to grow further, as records would accumulate longer before being processed, worsening the backlog. Option D is wrong because switching to Kinesis Data Analytics introduces a different service (meant for real-time analytics with SQL or Flink) that adds complexity and cost, and does not directly address the consumer throughput limitation caused by insufficient shard parallelism.