For a DynamoDB table, how do you choose between on-demand capacity and provisioned capacity with auto scaling, and what does each mode do when traffic spikes suddenly?

## The two billing modes Every DynamoDB table runs in exactly one *capacity mode*, also called the billing mode: **on-demand** or **provisioned**. The mode decides how throughput is bought, not how the data is stored or queried — the API surface is identical either way. In **provisioned** mode you declare a number of read capacity units (RCU) and write capacity units (WCU) per second. You pay for that reservation whether or not you use it, and requests beyond it are throttled. In **on-demand** mode you declare nothing; DynamoDB meters read request units and write request units actually consumed and bills per unit. The sizing rules are the same in both modes (a write unit covers an item up to 1 KB, a strongly consistent read unit covers up to 4 KB), so the arithmetic you learn for one transfers to the other. ## Cost: the crossover is utilisation On-demand's per-request price is several times the price of the equivalent provisioned unit. That means provisioned wins when you can keep utilisation high, and loses when you cannot. A table provisioned at 1,000 WCU that averages 100 WCU is paying for ten times what it uses, and will usually be more expensive than on-demand despite the lower unit price. The practical crossover sits somewhere around the point where sustained utilisation of the provisioned capacity is high — roughly the middle of the range and upward — but the honest interview answer is that you compute it from your own consumed-capacity metrics rather than quoting a rule of thumb. Provisioned capacity can also be bought as **reserved capacity** on a one- or three-year commitment, which lowers the price further for genuinely permanent baseline load; on-demand has no equivalent commitment discount, though you can now cap an on-demand table's maximum read and write rate to bound spend and blast radius. ## The spike behaviour, which is what interviews are really testing Provisioned mode is normally paired with **DynamoDB auto scaling**, which is Application Auto Scaling with a target-tracking policy: you set a target utilisation (commonly 70%) plus minimum and maximum capacity, and it raises or lowers provisioned throughput to hold consumed capacity near the target. ```bash aws application-autoscaling put-scaling-policy \ --service-namespace dynamodb \ --resource-id "table/Orders" \ --scalable-dimension "dynamodb:table:WriteCapacityUnits" \ --policy-name OrdersWriteTarget \ --policy-type TargetTrackingScaling \ --target-tracking-scaling-policy-configuration file://policy.json ``` The loop runs on CloudWatch metrics, which are published at one-minute granularity and evaluated over several data points, so the reaction time is **minutes**. That is fine for a diurnal curve and useless for a step function: a marketing push, a batch job, or a retry storm arriving in seconds will throttle while auto scaling is still deciding. DynamoDB does keep a small amount of unused capacity as burst credit — on the order of a few minutes' worth, and explicitly not guaranteed — which softens brief overshoots but is not a spike strategy. On-demand mode does not have that lag; the service tracks the table's traffic and scales the underlying partitions itself. It still is not literally unbounded: a table can serve a large multiple of its previous peak immediately, and traffic that leaps far past anything the table has ever seen can still throttle briefly before the service catches up. Pre-warming by driving a controlled load ramp before a known event, or temporarily switching to provisioned with a high floor, is the standard mitigation for a planned launch spike. ## Switching modes The mode is changed on a live table with `UpdateTable` and `BillingMode`, with no downtime and no data migration. AWS limits how often you can switch back to on-demand, so treat it as an occasional decision rather than a knob to toggle daily. ```bash aws dynamodb update-table --table-name Orders --billing-mode PAY_PER_REQUEST ``` ## How to answer in an interview Start on-demand when the traffic shape is unknown — a new service, an internal tool, anything bursty or with long idle stretches — because it removes an entire class of throttling incident and costs nothing while idle. Move to provisioned with auto scaling once the consumed-capacity graph is boring and utilisation would be high, and set the auto scaling minimum high enough to cover the spikes auto scaling cannot react to, not just the trough. Say explicitly that the decision is per table: a busy events table and a small configuration table in the same application often belong in different modes.