How to scale a Kinesis data stream for peak traffic most cost-effectively?

An application ingests data from an Amazon Kinesis data stream. The shards in the data stream are set for normal traffic. During tests for peak traffic, the application ingests data slowly. A developer needs to adjust the data stream to handle the peak traffic. What should the developer do to meet this requirement MOST cost-effectively?

Install the Kinesis Producer Library (KPL) to ingest data into the data stream.
Switch to on-demand capacity mode for the data stream. Specify a partition key when writing data to the data stream.
Decrease the amount of time that data is kept in the data stream by using the DecreaseStreamRetentionPeriod API operation.
Increase the shard count in the data stream by using the UpdateShardCount API operation. Source Reference Answer

Community Votes

75%

25%

75% of anonymous learners picked answer D. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

The question tests provisioned vs. on-demand capacity economics: the phrase 'MOST cost-effectively' combined with tested (predictable) peak traffic points to manually increasing shards, not switching to on-demand mode.

When a provisioned Kinesis data stream sized for normal traffic throttles during tested peak loads, the most cost-effective fix is to raise the shard count using the UpdateShardCount API while staying in provisioned capacity mode. Community consensus (75% of votes) favors manual shard scaling over on-demand mode because known, predictable peaks do not justify on-demand's price premium.

Many candidates pick B (on-demand capacity mode) because it automatically scales with no capacity planning, but on-demand pricing carries a significant premium per GB ingested and retrieved, making it more expensive than provisioned shards for predictable, testable peak traffic.

Community Discussion (3 comments)

YUICH 👍 1 Selected: D

Comparison of B and D: B (On-Demand Mode) is better when: Traffic patterns are highly variable or unpredictable. Automatic scaling is preferred to minimize manual intervention. The workload is intermittent, making On-Demand pricing more cost-efficient. D (Manually Adjusting Shard Count) is better when: The application has predictable traffic peaks and troughs. The goal is to manually control scaling and costs in provisioned mode. Immediate scaling is required to meet throughput needs, as On-Demand Mode may introduce a slight delay for shard scaling. Conclusion: The correct solution depends on the specific requirements mentioned in the question. If the question highlights unpredictable traffic, On-Demand Mode (B) is likely the better choice. However, if the traffic peaks are predictable and manual control is desired, increasing shards (D) is the optimal solution.

ShakthiGCP 👍 1 Selected: B

On-demand - data streams with an on-demand mode require no capacity planning and automatically scale to handle gigabytes of write and read throughput per minute. With the on-demand mode, Kinesis Data Streams automatically manages the shards in order to provide the necessary throughput.

albert_kuo 👍 2 Selected: D

aws kinesis update-shard-count \ --stream-name my-data-stream \ --target-shard-count 4 \ --scaling-type UNIFORM_SCALING

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Why the Answer Is Correct

The stream is provisioned and sized for normal traffic, and slow ingestion during peak tests indicates shard-level write capacity exhaustion. Using the UpdateShardCount API operation to increase the shard count (for example with UNIFORM_SCALING) adds exactly the throughput needed for the tested peak. Staying in provisioned mode and paying only for the shards required at peak is cheaper than on-demand's premium pricing, which satisfies the 'MOST cost-effectively' requirement. Comment [1] even shows the exact aws kinesis update-shard-count CLI call, confirming this is the intended operational solution.

Why the Other Options Are Wrong

A: The Kinesis Producer Library improves producer efficiency through aggregation and batching, but it does not add stream capacity, so it cannot fix throttling when shards are the bottleneck. B: On-demand mode removes capacity planning but costs more per GB, and it is designed for unpredictable or highly variable traffic rather than peaks you can test and size for, as comment [2] explains. C: Decreasing the retention period with DecreaseStreamRetentionPeriod only reduces storage costs and risks data loss; it does nothing to increase ingestion throughput.

Community Comment Notes

Comment [2] delivers the decisive comparison: on-demand mode suits highly variable or unpredictable traffic, while manually adjusting shard count suits predictable peaks and cost control, which matches the question's wording. Comment [1] contributes the update-shard-count CLI example with UNIFORM_SCALING, reinforcing answer D. Comment [3] advocates on-demand mode and represents the 25% minority vote, but it overlooks the 'most cost-effectively' qualifier that disqualifies on-demand's higher unit price for known peaks.

Official Reference

Exam Strategy

When a Kinesis question says 'most cost-effectively,' default to provisioned capacity mode with UpdateShardCount unless the scenario explicitly describes unpredictable or intermittent traffic. On-demand mode trades a pricing premium for zero capacity planning, so reserve it for volatile workloads. Always match the scaling mechanism to the predictability of the traffic described in the scenario.

Related Analysis

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide