Aurora Serverless v2 for spiky traffic

WHAT THIS TESTS The interviewer checks whether you can match a capacity model to a traffic shape and reason honestly about cost, not just repeat marketing.

A GOOD ANSWER COVERS Aurora Serverless v2 measures capacity in Aurora Capacity Units, each roughly two gigabytes of memory plus associated CPU and networking. It scales up and down in fine increments, often half an ACU at a time, and reacts within seconds, so a sudden spike is absorbed without a manual instance resize or downtime. You set a minimum and maximum ACU range. Billing is per ACU-second, so during quiet periods you pay close to the floor. A provisioned RDS or Aurora instance is a fixed size you must pick for the expected peak; you pay that hourly rate whether traffic is high or near zero, and if you undersize it you saturate during spikes.

PERFORMANCE AND COST IMPLICATIONS For spiky or unpredictable load, serverless trades a small per-unit premium for elasticity and no over-provisioning. For steady, high, predictable load, provisioned with reserved instances is usually cheaper because you commit to capacity you will fully use. Serverless still has a configured floor, so a true cold start to zero is not instant capacity from nothing.

COMMON WRONG ANSWERS Saying serverless is always cheaper, ignoring the per-ACU premium under sustained load. Claiming it scales from literally zero instantly, or forgetting to set a sensible max that caps runaway cost.

LIKELY FOLLOW-UPS How do you set min and max ACU. What happens during scaling to in-flight connections. When would provisioned reserved instances win on cost.

ONE CONCRETE EXAMPLE A ticketing app is idle most of the week but spikes 50x when sales open. Serverless v2 sits near its floor between sales, then ramps to the configured maximum within seconds at on-sale time, so you avoid paying peak rates around the clock the way a fixed provisioned instance would.