In this guide 6 sections
Record CPU, memory, disk and response times at peak, pick the next size down, change one server at a time and compare against the baseline. If latency or errors move, roll back at once. Never resize on average usage alone, because peaks decide whether users feel it.
Record a baseline at peak load
Pull at least two weeks of metrics from CloudWatch, Azure Monitor or Cloud Monitoring. Include a month-end or a campaign if your traffic has one. Averages hide the hour when the application actually struggles.
For each server note the peak and the ninety-fifth percentile of CPU, memory, disk IOPS and network throughput. Memory is not shown by default on some providers, so install the agent first. A server that looks idle on CPU may be full on memory.
Add user-facing numbers beside it: p95 response time, error rate and queue depth.
- CPU at peak and at the 95th percentile
- Memory used, including cache and swap
- Disk IOPS, throughput and queue length
- p95 response time and 5xx error count
Choose the next size down, not the smallest
Pick one step smaller in the same family. Going from a four-core to a two-core machine is a clear test. Jumping three sizes tells you nothing if it fails.
Check the shape as well as the size. A memory-heavy service belongs on a memory-optimised family, a batch worker on a compute family. Switching family often saves more than shrinking inside the old one.
Watch for burstable instances. Their CPU credits run out under steady load, and throttling then looks like a slow application.
Change one server at a time
Resize a single instance behind the load balancer and leave the others alone. Traffic splits between old and new sizes, so you can compare them side by side.
Do it in a quiet hour and write down the time. Keep the old size one click away. Stateless web servers are the easy first candidates. Databases and anything with local disk state need a planned window and a snapshot.
Hold the change for several days before judging it.
Compare against the baseline and decide
Set the pass mark before you start. For example, p95 response time stays inside the baseline range and CPU stays below the level where autoscaling kicks in. Anything outside that range is a fail.
If the numbers hold, apply the same size to the next server and repeat. If they move, return to the previous size and note which resource was the limit.
Keep a short log of each change, the result and the monthly saving. It builds confidence with the team and shows finance what the work achieved.
- Same load window as the baseline
- Same traffic mix, not a quiet weekend
- Error logs read, not only dashboards
- Autoscaling thresholds rechecked
Repeat after every major release
A right size is true for one version of the code. A new feature, a heavier query or a larger image library can change the curve within weeks.
Add a quarterly look at the same metrics and a rule that new services launch one size smaller than the guess. They can always grow.
Your next step: pick the three servers with the lowest peak CPU and highest cost, and record their baselines this week.
Right sizing test sheet
A one-page template with a row per server. Columns hold current size, peak CPU, peak memory, disk IOPS, p95 latency, proposed size, change date, result after seven days and rollback note. A header block records the pass mark agreed before the change.
Open a blank worksheet to printQuestions owners ask
Will right sizing slow my application?
Not if you test against a baseline and change one server at a time. The risk comes from resizing on average usage or all servers together.
How long should I watch metrics before resizing?
Two weeks is a practical minimum, longer if your traffic has monthly peaks. Include one busy period so the peak numbers are real.
Can I resize a database the same way?
Yes, but with more care. Take a snapshot, choose a quiet window and expect a short restart. Storage and IOPS limits matter as much as CPU.
What if memory is not visible in my metrics?
Install the provider’s monitoring agent or an exporter. Without memory data, a resize decision is a guess.