A retailer's Aurora database experiences heavy load only during periodic flash sales and is otherwise nearly idle, and the team wants compute capacity to scale up and down automatically in fine-grained increments within seconds, without manually resizing the DB instance class before and after each sale. Which approach fits, and how does capacity scale?
- Aurora Serverless v2, which measures capacity in Aurora Capacity Units and scales a writer or reader up or down in increments as small as 0.5 ACUs, without dropping existing connections during most scaling events
- A provisioned Aurora DB cluster with auto scaling enabled on the writer instance class, which swaps to a larger instance class within seconds of a load spike
- Aurora Serverless v2 configured with a single fixed ACU value equal to the peak flash-sale capacity, so no further scaling logic is needed
- RDS Proxy placed in front of the writer instance, which absorbs traffic spikes by pooling connections so the underlying instance class never needs to change
Why A? And why not the others?
Correct answer: A. Aurora Serverless v2, which measures capacity in Aurora Capacity Units and scales a writer or reader up or down in increments as small as 0.5 ACUs, without dropping existing connections during most scaling events
Aurora Serverless v2 measures capacity in Aurora Capacity Units and scales a writer or reader within its configured minimum and maximum range in increments as small as 0.5 ACUs, with scaling designed to happen without dropping database connections during most scaling operations, which fits an idle-then-spiky flash-sale workload without any manual resizing. The option describing a provisioned cluster with auto scaling on the instance class is wrong because changing a DB instance class is a modification that is not instantaneous and typically involves the instance restarting to apply the new class, which is not the seconds-level, connection-preserving scaling the team needs. The option describing a fixed ACU value pinned to peak capacity is wrong because it removes the actual benefit of serverless scaling, leaving the cluster paying for peak-level capacity even during the long idle periods between sales. The option describing RDS Proxy is wrong because a proxy pools and manages client connections to reduce connection overhead; it does not add or change the underlying compute capacity, so it cannot absorb a genuinely compute-bound load spike.
Source: AWS Aurora documentation: How Aurora serverless works (Aurora Serverless v2 capacity and scaling)