A company is using Amazon DynamoDB with on-demand capacity. The application performs many small writes that are throttled frequently. The company wants to minimize costs while reducing throttling. What should the company do?
Provisioned with auto scaling can handle predictable patterns and reduce cost vs. on-demand.
Why this answer
DynamoDB on-demand capacity can throttle small writes if the traffic pattern exceeds the table's previous peak traffic, as on-demand capacity scales based on traffic volume but has a per-second burst limit. Switching to provisioned capacity with auto scaling allows you to set a baseline capacity that matches the application's average write throughput, while auto scaling adjusts capacity based on actual usage, reducing throttling without the premium cost of on-demand capacity for predictable workloads.
Exam trap
The trap here is that candidates assume on-demand capacity automatically handles all traffic patterns without throttling, but on-demand throttles when traffic exceeds the table's previous peak, and they may overlook that switching to provisioned capacity with auto scaling provides a cost-effective solution for predictable workloads with frequent small writes.
How to eliminate wrong answers
Option A is wrong because DynamoDB on-demand capacity does not use manual write capacity units; you cannot increase them manually as on-demand scales automatically, and manually setting provisioned capacity would require switching away from on-demand. Option B is wrong because DynamoDB Accelerator (DAX) is an in-memory cache for reads, not writes; it does not reduce write throttling as writes still go directly to DynamoDB. Option D is wrong because batch writes combine multiple write operations into a single API call, which can improve throughput efficiency but does not address the root cause of throttling under on-demand capacity, and the question states the application performs many small writes that are throttled frequently, implying the issue is capacity limits, not write batching.