Capacity planning sounds like a spreadsheet exercise: forecast next year’s traffic, buy the servers, repeat. For a team running production on AWS, Azure or GCP, most of that work has been handed to the cloud provider. What remains is mostly checking a short list of basics, so that when demand jumps your systems slow down in a way you chose. None of it needs a forecasting team, and most of it can be written down in an afternoon.
Start by asking whether you need capacity planning at all
Capacity planning means forecasting demand and providing enough supply to meet it, while balancing performance, cost and reliability. Provisioning for every unlikely edge case is the wrong target, for the same reason that aiming for 100% uptime is: the cost keeps climbing while the benefit shrinks. For most cloud services, we don’t think a rigorous process is needed.
Autoscaling (rules that add or remove servers automatically as load changes) does most of the job. A reasonable starting rule adds two instances when CPU stays above 70% for five minutes, removes one when it falls below 40%, and never drops below five instances. For small workloads, our default is to run more than you need, because compute is cheap compared with engineers’ time. Detailed forecasting earns its place only if you run your own hardware or hit budget or cloud scaling limits.
Three kinds of demand, three different responses
| Demand | Example | Response we recommend |
|---|---|---|
| Steady growth | More customers month on month | Watch the trend and extend it forward |
| Planned events | A launch, a promotion, Black Friday | Plan the event in advance with the teams involved |
| Unplanned surges | Something goes viral or makes the news | Spare capacity, autoscaling and ways to reduce or shape demand |
For a startup, autoscaling usually handles steady growth. Unplanned surges are the hard case, and most of the checks below exist for them.
Zones and regions: the checks that matter most
Cloud providers divide each region into zones (separate data centres with their own power and networking). For production, we advise: don’t run it in a single zone except for testing, spread services across a region with enough spare capacity to absorb the loss of a zone, and go multi-region only for workloads that must survive a whole region failing.
If you run in two zones and lose one, the remaining zone instantly receives double its normal load. With two regions of two zones each, a single zone failure removes 25% of capacity, compared with 50% when each region has only one zone. Also check where the control plane (the management system you would use to move traffic or start new servers) runs, because it may be in the zone that failed.
Single-zone cloud building blocks typically carry an SLA (service-level agreement: the availability the provider commits to) of around 99.5%, and multi-region ones around 99.99%. Your own reliability depends on every layer you build on as well as your code.
Your provider can be short of capacity too
Autoscaling assumes the cloud has spare servers to give you. The event behind your spike may also be straining your provider, so scaling can fail during the spike. Cloud quotas (account limits on how many instances, addresses or other resources you can use) and the maximums set in your own autoscaling rules can stop growth in the same way. Know both numbers, and raise quotas before a planned event.
Track usage per user as well as in total
We recommend tracking infrastructure use against a product measure, for example cores (or cost) per 1,000 active users, and alerting when that ratio shifts. A sudden change usually means a release made the service less efficient. If your service copes well with overload, this alert can open a ticket for working hours; if it doesn’t, the shift may need to page someone.
Decide what breaks first
Every system has a point where demand exceeds supply. A useful idea here is the crumple zone: map exactly what happens at that point (slowdown, outage or lost data) and design a controlled version instead. Load shedding (deliberately rejecting low-priority requests so important ones still succeed) works when you tag traffic by priority, so background jobs give way before checkout does. Graceful degradation (switching off expensive features to keep the core working) is the other tool. Whichever you use, always measure when shedding happens.
Automate the routine response
We recommend listing likely capacity failures in advance, writing a playbook (a written plan of what to do) for each, and automating the routine steps so that nobody needs to approve a capacity increase at 3am. A small emergency buffer gives you room to cool a system down while you work out what happened. Responses like draining traffic from a zone, rolling back or adding capacity must be practised beforehand, because a rollback nobody has tested may turn out not to work in the middle of an outage.
Plan for a surge that lasts weeks
A large unplanned surge can last far longer than one night. Google has published an account of Google Meet during COVID-19, when usage grew up to 30 times over the pandemic and up to 400 times in some regions by mid-May 2020. The first pages looked like routine under-provisioning, and the response became a long incident with clear roles and separate workstreams: estimating capacity, mapping dependencies, removing bottlenecks and adding knobs to lower video and audio quality. Because the service had been stable, it had little deployment automation, which made manual scaling slow and tiring.
We take four lessons from it that apply at any size: prepare for unplanned surges, build control knobs before you need them, expect a response that can run for weeks, and watch the people responding for burnout.
A brief word on cost
We treat cloud cost as a trade-off with reliability. FinOps (bringing finance, engineering and the business together on cloud spending) is the same thinking applied to cost versus availability. The trap is assuming idle capacity is waste: spare headroom to lose a zone looks idle until the day it is needed. Cut cost where headroom is genuinely spare, and keep the buffer that covers a zone failure.
How we apply this
Our gap review in the first weeks of cover includes what runs in only one zone, and you get the gaps as a written list. By day 30, our runbook starter pack offers standard fixes such as adding capacity or moving traffic away from a failing zone for your approval, and each one is tried before it can run in a real incident. As part of our reliability work, we test how production copes with heavy traffic and rehearse failures, including the runbooks themselves.