Nightly Batch vs. Black Friday Storefront
Northwind Retail runs a nightly reconciliation batch that starts at 22:00 and uses exactly 8 vCPUs for 6 hours, every night, for four years - the workload never varies. Its public storefront is the opposite: 40x normal traffic during a 72-hour Black Friday window, near-idle the rest of the year, and marketing cannot predict the peak to within a factor of two. The datacenter lease expires in 14 months. The CFO will approve only one-year commitments, wants compute spend down 30%, and asks whether buying two more servers would be cheaper. Finance staff in three time zones read the batch output the next morning, and the batch can be re-run from the beginning at no extra cost if it fails.
1. Should the nightly batch be bought with a one-year reservation, and should the storefront? Show the reasoning with numbers.
Read the worked answer
Batch - predictable but low duty cycle. 6 hours × 365 days = 2,190 running hours per year, about 25% of the 8,760-hour calendar. A one-year reserved instance is billed for the whole term, not just the hours the VM runs; if you deallocate the VM at 04:00, the reservation is simply not consumed that hour. So a ~40% discount applied to 8,760 billed hours equals roughly the cost of 5,250 full-price hours - more than double the 2,190 hours you actually need. The naive rule "reserve predictable workloads" breaks here.
A reservation is only right if it is scoped size-flexible and shared, so other VMs in the same family consume the other 18 hours each day.
Storefront - the opposite. The baseline is steady all year, so reserve the baseline instance count, and let autoscale add pay-as-you-go instances during the 72-hour peak. Never reserve capacity sized for a 40x peak you cannot predict.
Verdict: reserve the storefront baseline, not the batch, unless the batch's idle hours are genuinely absorbed by other workloads.
2. The CFO says 'we already own the servers, so staying put is cheaper.' What is wrong with that comparison?
Read the worked answer
The comparison is CapEx-plus-sunk-cost versus OpEx, and it omits three things:
- You sized for the peak, but pay for it every hour. The Black Friday requirement forces 40x capacity that sits idle for ~360 days. Owned hardware costs the same on a quiet Tuesday as on peak day; consumption-based pricing costs nothing when the resource is deallocated.
- Total cost of ownership is not the server price. The lease, power, cooling, rack space, network gear, refresh cycle, and the staff who patch and replace disks are all part of the owned figure. The lease expiring in 14 months is exactly when those costs would reset upward.
- Elasticity has option value. The owned fleet cannot grow during an unpredictable 72-hour window or shrink afterwards; the Azure footprint can, in minutes, via autoscale rules.
What the CFO is right about: the servers are sunk costs and should not influence the forward-looking decision at all. Only future, avoidable costs count.
3. The storefront team proposes doubling each VM's size instead of adding instances. Evaluate that against the 40x peak and the availability target.
Read the worked answer
That is scaling up (vertical) when the problem calls for scaling out (horizontal).
- Ceiling. There is a maximum VM size; a 40x spike can easily exceed what the largest single instance can absorb, and then there is no next move.
- Restart required. Resizing a VM usually needs a deallocate/restart, so the remedy for a traffic spike becomes an outage during the spike.
- No availability gain. One bigger VM is still one VM. The storefront remains a single point of failure; adding instances behind a load balancer and spreading them across availability zones addresses both capacity and failure.
- Granularity. Autoscale adds N instances to match demand and removes them after; a resized VM is a step change you must reverse by hand.
Answer: put the storefront behind a load balancer with autoscale rules and zone-spread instances. Reserve only the steady baseline for cost, and keep vertical scaling for genuinely single-threaded workloads (the batch) - not for unpredictable demand.