Cloud capacity planning is one of those disciplines that sounds straightforward until the bill arrives. Australian IT teams routinely overprovision compute, storage, and networking capacity because the instinct to leave headroom feels safer than the embarrassment of a performance event. But that instinct is expensive. AWS, Azure, and GCP all make it frictionless to spin up resources and much harder to justify retiring them, which means wasted capacity compounds quietly month after month.
This guide covers how to build a capacity planning practice that reflects actual demand, not anxiety about demand.
Why overprovisioning is the default
Cloud procurement inherited its habits from on-premises data centres, where capacity decisions were irreversible for years. If you ordered too little server hardware, you waited months for more. That scar tissue is still visible in cloud architectures: teams size for peak-of-peak traffic rather than average load, then leave those resources running continuously. On a physical server, idle capacity costs nothing extra. In the cloud, you pay for what you provision, not what you use.
Three specific behaviours drive this pattern. First, teams set instance sizes during a project's initial build, when nobody has real traffic data, and never revisit them. Second, capacity decisions get buried inside infrastructure-as-code templates that developers are reluctant to change for fear of breaking something. Third, cloud cost ownership is diffuse: the team running the workload rarely sees the invoice directly, so there's no feedback loop.
The rightsizing process, step by step
Rightsizing is the practice of matching your provisioned resources to your actual utilisation over time. It's not a one-off audit. It's a repeating cycle, and it needs to start with observation before it touches anything.
Start by pulling at least 30 days of CPU, memory, and network utilisation data for every running instance or service. All three major cloud providers offer this natively: AWS provides it through CloudWatch, Azure through Azure Monitor, and GCP through Cloud Monitoring. Look for instances where peak CPU sits consistently below 40% and average CPU is below 20%. Those are candidates for downsizing, not proof of safety.
Memory tells a different story. CPU throttles gracefully; running out of memory crashes processes. Use the 30-day peak as your floor, not your ceiling, when sizing for memory. A workload that peaks at 6 GB of RAM once a week needs at least 8 GB in headroom, not 6 GB exactly.
Network I/O is the easiest to over-provision and the most expensive to get wrong. Check whether high-bandwidth instances are being used for workloads that move very little data. Network-optimised instance families command a price premium that's only worth paying when you actually saturate those links. If you're uncertain how cloud egress costs are contributing to your bill, that analysis sits alongside rightsizing, not separate from it.
Forecasting demand without guessing
Good capacity planning distinguishes between predictable demand and unpredictable demand. They need different responses.
Predictable demand includes scheduled batch jobs, end-of-month financial processing, regular reporting runs, and business-hours traffic patterns. These workloads are ideal candidates for scheduled scaling: spin up capacity at 7am, scale it back at 7pm. AWS Auto Scaling, Azure Virtual Machine Scale Sets, and GCP Managed Instance Groups all support time-based rules. Set them up and validate them against two or three weeks of actual logs before trusting them in production.
Unpredictable demand needs event-driven scaling policies tied to real metrics, not time. CPU utilisation, queue depth, request latency, and custom application metrics are all valid triggers. The mistake teams make is setting scaling thresholds too conservatively. A scale-out trigger at 90% CPU means your instance is already struggling by the time new capacity arrives. Trigger at 60–70% and scale down at 30–40%, with a cooldown period of at least 5 minutes to prevent thrashing.
For longer-horizon forecasting (12 months out), the most reliable approach is a bottoms-up model: take each workload's current resource consumption, apply your expected growth rate for that specific service (not a blanket percentage across everything), and sum it. Business units generally have better visibility into their growth plans than IT does. A quarterly conversation with product owners about upcoming feature launches, user growth targets, and data volume projections is more useful than any algorithmic projection.
Commitment discounts: when to buy reserved capacity
Reserved Instances and Savings Plans (AWS), Reserved VM Instances (Azure), and Committed Use Discounts (GCP) can reduce compute costs by 30–70% compared to on-demand pricing. But they're only valuable if you're confident the underlying workload persists. Committing to a one-year reserved instance for a workload you retire in six months turns a discount into a sunk cost.
A practical rule: apply commitment discounts only to baseline capacity, the floor of what you know you'll consume regardless of seasonal variation. Cover variable and peak demand with on-demand or spot capacity. AWS Compute Savings Plans are more flexible than traditional Reserved Instances and worth evaluating first, since they apply across instance families and regions rather than to a specific instance type. If your organisation is managing workloads across AWS, Azure, and GCP simultaneously, the practical complexity of multicloud cost control adds another layer to this calculation.
Governance: making capacity decisions stick
The biggest failure mode in cloud capacity planning isn't technical. It's organisational. Teams do a rightsizing exercise, reduce costs by 20%, and then revert within six months because nobody owns the ongoing process.
Build a quarterly capacity review into your cloud governance calendar. Three things belong on that agenda: a utilisation report for all major workloads, a comparison of actual versus budgeted spend by team, and a list of instances older than 90 days that have never been rightsized. The last one matters more than it sounds. Long-running instances accumulate technical debt in exactly the same way long-running software does.
Tag everything. Every cloud resource should carry tags for the owning team, the workload name, and the environment (production, staging, development). Without tags, cost allocation is guesswork. Most Australian enterprises that struggle with cloud cost visibility have a tagging problem before they have a capacity problem. Enforce tagging policy at the provisioning stage through policy-as-code rather than asking teams to retrofit it later.
Set budget alerts, not just cost reports. A budget alert at 80% of monthly allocation gives a team time to investigate and respond. A cost report at the end of the month tells you what happened but not in time to change it. AWS Budgets, Azure Cost Management, and GCP Billing budgets all support this natively. Use them.
Development and staging environments deserve attention too
Production workloads get scrutiny. Development and staging environments usually don't. That's a mistake. In most Australian enterprise cloud accounts, non-production environments consume 20–35% of total spend, and they frequently run 24 hours a day even when developers work business hours only.
Apply automated shutdown schedules to all non-production environments. An EC2 instance or Azure VM that runs only during business hours (roughly 55 hours per week instead of 168) costs about one-third as much. Implement this once through a Lambda function, an Azure Automation runbook, or a GCP Cloud Scheduler job, and the savings recur every month without further effort.
Size non-production environments at one step below production, not equal to it. A staging environment that mirrors production exactly is only necessary in the final pre-release phase. For routine development work, smaller instances are adequate and cost a fraction of the equivalent production tier.
Capacity planning as a risk conversation
Cloud capacity planning should connect directly to your resilience and recovery objectives. An organisation running at 95% utilisation has no headroom to absorb a traffic spike, a failover event, or an unexpected batch job. That's not a cost problem; it's a risk problem. When presenting capacity planning to leadership, frame spare capacity as insurance, not waste, and quantify the cost of being caught short. A performance event that affects customers or causes a missed SLA typically costs more than the reserved capacity that would have prevented it. For teams thinking through how cloud architecture supports business continuity, cloud disaster recovery planning is a closely related discipline worth reviewing alongside capacity work.
Cloud capacity planning isn't glamorous. It doesn't generate a product launch or a press release. But done well, it turns cloud from a source of budget anxiety into a predictable, controllable cost that scales with the business rather than ahead of it.