SAA-C03 - Design Cost-Optimized Architectures - Section 4.5

Design cost-optimised database solutions by right-sizing instances, selecting serverless options and managing storage cost.

Compare Aurora Serverless v2, which scales compute automatically in fine-grained increments and charges per ACU-hour, with provisioned Aurora where you commit to an instance size and can apply Reserved Instance pricing. Choose DynamoDB on-demand capacity for unpredictable traffic to avoid over-provisioning, and use RDS storage auto scaling to grow allocated storage without manual resizing.

Aurora ServerlessRDS Reserved InstancesDynamoDB on-demand capacityStorage auto scaling

Practice question for this objective

Free sampleDesign Cost-Optimized Architecturesmedium

A team runs an Amazon DynamoDB table in provisioned capacity mode with read and write units fixed at the historical peak. Traffic is highly unpredictable, with long quiet stretches and sudden large spikes during flash sales, so the table is over-provisioned most of the month yet still throttles during the biggest surges. The same team also allocates a large fixed storage volume up front for an Amazon RDS database whose data grows slowly and unevenly, leaving costly empty capacity for months while risking an out-of-space failure if a spike fills it. Which two changes together reduce cost while removing the manual capacity guesswork? Select TWO.

  • ASwitch the DynamoDB table to on-demand capacity mode so it bills per request served and absorbs flash-sale spikes without capacity forecasting. Correct
  • BEnable RDS storage auto scaling so the allocated volume grows automatically as data accumulates, starting from a smaller initial size. Correct
  • CKeep DynamoDB in provisioned mode but raise the fixed read and write units further to stop the flash-sale throttling.
  • DContinue pre-allocating a large fixed RDS volume and add Provisioned IOPS io2 to guarantee headroom for growth.
  • EAdd DynamoDB Accelerator in front of the table to cache reads and reduce the provisioned capacity needed during spikes.
Use DynamoDB on-demand capacity for unpredictable spiky traffic and RDS storage auto scaling so database cost tracks real demand without manual capacity planning. DynamoDB on-demand mode removes capacity forecasting by charging per request and scaling instantly, so it serves quiet periods and flash-sale surges without over-provisioning or throttling. RDS storage auto scaling starts the volume small and grows it as data accumulates, so storage spend follows actual usage while protecting against a sudden out-of-space failure.

Why A is correct: On-demand mode charges only for actual reads and writes and scales instantly, ending both the over-provisioning in quiet periods and the throttling during spikes.

Why B is correct: Storage auto scaling lets the volume start small and expand on demand, so cost tracks real usage and a sudden growth spike will not trigger an out-of-space failure.

Why C is wrong: Higher fixed units would cut throttling but lock in even more wasted capacity during the long quiet stretches, making the over-provisioning problem worse, not cheaper.

Why D is wrong: Provisioned IOPS raises performance for I/O-bound databases, but it does nothing to stop paying for empty storage and actually increases cost on a workload bound by capacity, not IOPS.

Why E is wrong: DAX is a caching layer that lowers read latency, which is tempting for spikes, but it does not address write-heavy flash-sale surges or the over-provisioning paid for in quiet periods.

See more SAA-C03 practice questions, answers explained.

More in this domain

Back to all Design Cost-Optimized Architectures objectives, or the SAA-C03 cert hub.

Examworthy is not affiliated with or endorsed by Amazon Web Services. Original, blueprint-aligned practice material only.