Most cloud servers are sized once, at launch, based on a guess about expected load, and then never revisited. Months later the instance is either quietly wasting money on capacity nobody uses, or it is limping through peak hours on a size that was never enough to begin with. Right-sizing means replacing that original guess with an instance size based on what the server has actually been doing, not what seemed reasonable on day one.
Why the original size is almost always wrong
Instance sizing at launch time is usually based on one of two flawed inputs: a rough multiple of what the previous server used, or a provider's own suggested "general purpose" default. Neither reflects your actual workload's CPU pattern, memory footprint, or how much of that resource use is sustained versus occasional bursts. Real usage data, collected over at least two to four weeks including any weekly or monthly peak, is the only reliable basis for a sizing decision.
Start with CPU utilization, not CPU allocation
The number of vCPUs an instance has tells you the ceiling, not what you actually use. Pull real utilization history rather than checking current load with a single snapshot command.
sar -u -f /var/log/sa/sa01sar reads historical data collected by sysstat, which most Linux distributions run by default, and shows CPU usage across whatever retention period is configured, typically the current month. Look specifically at the 95th percentile of usage, not the average and not the single highest spike. An instance sitting at 15 percent average CPU with occasional spikes to 40 percent is a strong over-provisioning candidate. An instance regularly touching 85 to 90 percent, even if the average looks moderate, is undersized and heading toward a performance problem.
If sysstat was never installed and no history exists, start collecting now for future decisions, and in the meantime use a short live sampling window as a rough proxy:
vmstat 5 60Check memory the same way
Memory sizing mistakes are more expensive to get wrong in the low direction, since running out of memory causes the kernel's out of memory killer to terminate processes rather than simply slowing down.
free -hA snapshot only shows the current moment. For a genuine picture, check whether swap is being used at all under normal operation:
vmstat 5 60Persistent swap activity, visible in the si and so columns, under normal (not peak) load is a sign the instance is undersized for memory, regardless of how comfortable the CPU numbers look. An instance with memory sitting mostly idle and zero swap activity across weeks of monitoring is a legitimate downsizing candidate.
Use the cloud provider's own recommendation engine as a second opinion
Each major provider now offers a built in tool that analyzes your actual CloudWatch, Azure Monitor or Cloud Monitoring history and suggests a specific instance size change, which is worth cross-checking against your own manual analysis rather than trusting blindly.
AWS Compute Optimizer:
aws compute-optimizer get-ec2-instance-recommendations --instance-arns <instance-arn>Azure Advisor surfaces sizing recommendations directly in the portal under Cost recommendations, based on the same underlying Azure Monitor metrics available through the CLI.
Google Cloud's recommender API provides equivalent machine type recommendations:
gcloud recommender recommendations list --project=<project-id> --location=<zone> --recommender=google.compute.instance.MachineTypeRecommenderThese tools are useful as a cross-check, not a final answer, since they typically look at a shorter window than a full seasonal cycle and can miss workloads with genuine periodic peaks, such as month-end reporting jobs or seasonal retail traffic.
Account for burst behavior before downsizing
An instance with low average utilization is not automatically safe to downsize if its peaks are business-critical and infrequent. A reporting job that runs once a month and genuinely needs the current CPU count for two hours is a poor candidate for downsizing based on a 30-day average, even though the average looks wasteful. Separate genuinely idle capacity from capacity reserved for real, predictable peaks before making a change.
For workloads where the peak itself is unpredictable rather than scheduled, our guide on diagnosing a slow cloud VM covers how to tell a genuine capacity shortfall apart from noisy-neighbor or burst-credit throttling, which matters because upsizing an instance to fix a throttling problem, rather than a genuine capacity shortfall, wastes money without solving the actual issue.
Making the change safely
Resizing a cloud instance almost always requires a stop and start cycle, not a live resize, so plan the change for a maintenance window even though the operation itself typically takes only a few minutes. Before resizing:
- Confirm the new instance type is available in your current availability zone, since not every size exists in every zone.
- Check whether any attached resources, such as instance store volumes or specific network configurations, are tied to the current instance family and would be affected by a family change rather than just a size change within the same family.
- Take a snapshot or AMI image immediately before the change as a rollback point.
After resizing, repeat the same utilization monitoring for another two to four weeks to confirm the new size holds up under a full cycle, rather than assuming the change was correct because nothing broke on day one.
The ongoing discipline, not a one-time fix
Right-sizing is not a task you complete once. Traffic patterns shift, application code changes its resource profile after updates, and a size that was correct six months ago quietly drifts out of alignment with actual usage. Reviewing utilization data on a quarterly cadence, rather than only when a bill looks high or a server feels slow, keeps sizing decisions based on evidence instead of memory.
iServerSupport provides cloud server management for AWS, Azure and Google Cloud instances, including ongoing utilization monitoring and right-sizing reviews, so capacity decisions stay based on what the server is actually doing rather than what seemed reasonable when it was first launched.
Get an experienced server engineer involved
We diagnose and manage infrastructure you already own or rent, with practical help matched to the issue in this guide.
