Rightsizing Methodology: Measure, Resize, Verify

Rightsizing is changing a resource’s size or type so that its provisioned capacity matches what the workload actually uses, for example by moving an over-provisioned instance to a smaller size or a better-fitting family. It differs from scheduling, which changes when a resource runs, and from idle cleanup, which removes resources that do no work at all. A rightsized resource keeps running; it just costs less per hour.

Step 1: measure the right things

CPU alone is not enough. A useful measurement set covers each dimension that can constrain the workload:

• CPU, as a high percentile rather than an average, because sizing to the mean leaves no room for peaks.
• Memory, which is measured inside the guest. On AWS, Compute Optimizer uses EC2 memory utilization when you enable it with the CloudWatch agent.
• Network and disk throughput and IOPS, since each instance size has its own limits.
• For databases, connections and free memory, since a smaller class can mean a lower connection ceiling.

Step 2: use a window that includes real peaks

The window must cover the workload’s normal cycle, including month-end or weekly batch jobs. The provider tools show the trade-off. AWS Compute Optimizer analyses a default 14-day lookback and needs at least 30 hours of CloudWatch data in that period; its paid enhanced infrastructure metrics option extends the lookback to up to 93 days. Azure Advisor’s VM recommendations default to seven days and can be configured to 7, 14, 21, 30, 60, or 90 days.

Step 3: pick a concrete target

A recommendation should name a specific size, not “go smaller”. Consider the family as well as the size: a workload with low CPU and high memory may fit a memory-optimized size better than a smaller general-purpose one. Check that the target keeps enough headroom on every dimension from step 1. Azure Advisor, for comparison, targets P95 CPU and outbound network at or below 40% on the recommended SKU for user-facing workloads (with P99 memory at or below 60%), and 80% for non-user-facing ones.

Step 4: plan the restart

Resizing is disruptive on every major cloud:

• AWS EC2: you must stop an EBS-backed instance before changing its type; instances with instance-store root volumes, or incompatible target types, need migration to a new instance instead.
• Google Cloud: you change the machine type after stopping the VM; VMs with Local SSD or in a managed instance group follow a different procedure.
• Azure: changing the size of a running VM restarts it, and deallocation is sometimes required if the size is not available on the current hardware cluster.

Schedule the change in a maintenance window, record the original size, and keep a rollback plan. A resource already on a stop/start schedule can be resized during its off-hours.

Step 5: verify

After the change, compare the new utilization against the new capacity for at least one full cycle of the workload. Confirm the saving on the bill, not only in a calculator.

How ZopNight supports this

ZopNight’s rightsizing recommendations name a concrete target, in the form resize from A to B, and abstain rather than invent a saving when the target’s rate is unknown. Database rules add guards; the RDS rule reads the FreeableMemory metric and abstains on memory-constrained or zero-connection databases. The remediation workflow supports resize and resize-with-stop steps, and each recommendation records its target at emission so a later check can confirm whether the resource was actually resized.

Related: the idle resource problem, what keeps billing when idle, and how to rightsize EC2 instances.