Capacity & Scalability Planning

Capacity & Scalability Planning ensures the underlying platform has enough headroom — through autoscaling, load balancing, and quota management — before demand arrives, not after.

At a glance

• What it is: infrastructure-level scaling mechanisms (autoscale rules, load balancers, quota/limit management) sized and tested ahead of expected demand.
• Why it matters: it’s the difference between proactive capacity planning and reactive firefighting during a traffic spike.
• For developers: this is about the platform’s ceiling (VM/node counts, quota limits, load balancer throughput), not your code’s efficiency — see Software & Application Architecture’s Performance & Scalability Engineering for the application-level half of this problem.
• When to use it: ahead of any known demand spike (seasonal sale, marketing launch) and as ongoing baseline capacity governance.
• When not to use it: doesn’t replace fixing an inefficient application — infra headroom can’t compensate for a poorly performing query forever.
• Prerequisites: Compute & Container Platforms.

Mental model

graph LR
    LB["Load balancer"] --> Pool["Autoscaled compute pool"]
    Pool -- scale out on demand --> Pool
    Quota["Subscription/region quota"] -.caps.-> Pool

Step-by-step walkthrough

1. Forecast expected demand (seasonal event, launch, organic growth trend).
2. Configure autoscaling rules with realistic thresholds and cool-down periods, not just “scale to max.”
3. Confirm load balancer/gateway throughput limits can handle the projected peak.
4. Check and pre-request quota increases (VM cores, IPs, etc.) well ahead of the event — quota increases are not instant.
5. Load-test at the projected peak before the real event, not during it.

Worked example

Northwind’s checkout platform expects roughly 20x normal traffic on Black Friday, based on prior years.

• Input: a forecasted 20x traffic multiplier, current autoscale and quota settings sized for normal load.
• Process: the platform team configures autoscaling rules for the checkout compute pool with headroom above the forecast peak, verifies the load balancer’s throughput limit is comfortably above the projected peak request rate, and — six weeks ahead of the sale — submits a quota increase request for additional VM cores in the primary region, since the default subscription quota is well below what 20x scale would require. A load test at 1.2x the forecast peak runs against staging two weeks before the sale.
• Output: on the day, the autoscaler adds capacity smoothly within the pre-approved quota, and the load balancer holds up without needing an emergency quota request mid-event. Concretely: Azure Monitor autoscale rules on the AKS node pool, traffic fronted by Azure Front Door, and a quota increase request filed through the Azure portal for the primary region’s VM core limit.

The same pattern applies to a web app’s App Service Plan, not just AKS node pools:

resource autoscale 'Microsoft.Insights/autoscalesettings@2022-10-01' = {
  name: 'checkout-plan-autoscale'
  location: location
  properties: {
    targetResourceUri: plan.id
    enabled: true
    profiles: [
      {
        name: 'CPU-based scale-out'
        capacity: { minimum: '2', maximum: '10', default: '2' }
        rules: [
          {
            metricTrigger: {
              metricName: 'CpuPercentage'
              metricResourceUri: plan.id
              timeGrain: 'PT1M'
              statistic: 'Average'
              timeWindow: 'PT5M'
              timeAggregation: 'Average'
              operator: 'GreaterThan'
              threshold: 70
            }
            scaleAction: { direction: 'Increase', type: 'ChangeCount', value: '2', cooldown: 'PT5M' }
          }
        ]
      }
    ]
  }
}

Common use cases

Use case	When to use	Notes
Known seasonal traffic spike	Pre-provision quota + autoscaling headroom	Quota increases can take days — request them ahead of time
Steady organic growth	Periodic capacity review against autoscale ceilings	Prevents silently hitting a scaling ceiling
Cost control during low-traffic periods	Scale-in rules with sensible minimums	Balance cost against startup latency from over-aggressive scale-in

Advanced details

• Autoscaling on CPU alone can miss capacity problems that show up first as network saturation or connection pool exhaustion — scale on the metric that actually predicts trouble for that workload.
• Quota is a subscription/region-level ceiling independent of autoscale configuration — an autoscaler correctly trying to add capacity can still fail if the underlying quota is exhausted.
• Load testing should target the load balancer and network path too, not just individual compute instances, since that’s often the first bottleneck at scale.
• This maps to two named Well-Architected pillars: sizing autoscaling and load balancers to forecasted demand is the Performance Efficiency pillar; pre-approving quota and setting sensible scale-in minimums so idle capacity isn’t paid for is the Cost Optimization pillar — the two pillars are frequently in tension, which is why the worked example above needed a deliberate quota request rather than just “scale to max.”
• Web app scaling has two distinct axes: scale-out (the autoscale rule above — more instances of the same App Service Plan tier) and scale-up (moving to a bigger tier, e.g. P1v3 → P2v3, for more CPU/memory per instance). Autoscale rules only ever scale out/in — hitting a scale-out ceiling with instances still individually maxed out on CPU is a signal to scale up the tier, not just raise the instance-count ceiling further.

Quick reference

Term	Meaning
Autoscaling	Automatically adding/removing capacity based on demand
Load balancer	Distributes incoming traffic across a pool of instances
Quota	A subscription/region-level cap on how many resources can be provisioned
Cool-down period	Minimum time between autoscale actions, to avoid thrashing
Load test	Simulated traffic run ahead of time to validate capacity assumptions

Troubleshooting

Symptom	Likely cause	Fix
Autoscaler tries to add instances but capacity never appears	Subscription/region quota exhausted	Request a quota increase well ahead of the next demand spike
Autoscaler rapidly adds and removes instances (“flapping”)	Cool-down period too short or scaling metric too noisy	Lengthen the cool-down and/or scale on a smoother aggregated metric
Load balancer becomes the bottleneck before compute does	Load testing only exercised compute, not the full network path	Include the load balancer/gateway in load tests at projected peak

Check your understanding

• Why can an autoscaler be “working correctly” and still fail to add capacity during a spike?
• What’s the risk of only load-testing individual compute instances instead of the whole request path?

Related pages

Part of Introduction to Cloud & Infrastructure Architecture. See also Compute & Container Platforms, Infrastructure Observability & Monitoring, Software & Application Architecture’s Performance & Scalability Engineering, and the Glossary.