Rightsizing Recommendations That Name the Target

Rightsizing covers resources that are in use but provisioned beyond what their measured load needs. The category is broader than instance downsizing: it also includes storage classes, disk types, provisioned IOPS, database tiers and serverless memory settings.

The template is strict

Every rightsizing recommendation is titled “Resize [name] from [current size] to [target size]”. The engine refuses to compose that line if it cannot read the current value, cannot name a target, or the target equals the current spec. In those cases the finding falls back to the rule’s written explanation, or does not fire at all. Savings come from real rate differences between the source and target SKUs, not from a flat assumed fraction.

What gets measured

Each rule reads the signals relevant to its resource and applies a veto where downsizing would hurt:

• EC2 Rightsizing picks a one-step or two-step same-family downsize from 30-day average CPU, with a memory veto.
• RDS Instance Right-sizing reads CPU and the native FreeableMemory metric, pricing only the compute portion of the bill.
• GCP Cloud SQL Right-sizing steps to the next-smaller tier from live SKU rates.
• Azure Cosmos DB Provisioned Throughput Rightsizing sizes a new RU/s target from the measured peak plus burst headroom, and refuses when no safe smaller value exists.
• Lambda Over-Provisioned Memory fires when peak memory used is under half of the configured memory.

Storage rules work the same way: EBS gp2 to gp3 Migration nets out any IOPS or throughput charge the volume would inherit, and GCS Bucket Standard Class with Low Access needs a measured access rate before it suggests a colder class. A missing metric series is a data gap and the rule abstains.

Applying a resize

Several rightsizing rules are wired to remediation, including EC2 Rightsizing and GCP VM Oversized (resize with a stop), and EBS provisioned IOPS and Azure VM downscale (resize in place). Lambda memory findings are advisory. A resize that needs a restart is demoted to advisory on stateful resources, so a database is never rebooted automatically. After you apply a change, ZopNight compares the resource with the target it recommended and records whether the change was adopted. The workflow is described in rightsizing and the method in rightsizing methodology.

By cloud

AWS rightsizing, GCP rightsizing and Azure rightsizing list the rules per provider.

Every rightsizing check ZopNight runs has its own page, with the reason it fires and the fix: see the rightsizing checks in the ZopNight rule catalogue.