How rightsizing reduces both cloud cost and carbon

Rightsizing is the practice of matching a cloud resource to the demand it actually serves, instead of the demand someone guessed at provisioning time. Most cloud estates are over-provisioned by default, because engineers size for peak, round up for safety, and rarely revisit the choice. The unused headroom is pure waste, and it is waste in two currencies at once: the provider bills for the full instance whether or not the workload uses it, and the data center draws power to keep that capacity available. Rightsizing recovers both, which is why it sits at the overlap of cost optimization and cloud sustainability.

This article is part of our complete guide to cloud sustainability and GreenOps, the cluster pillar it links up to. It pairs with how Graviton and Arm instances cut energy and cost, the other lever that lowers the bill and the footprint together.

Why does rightsizing cut carbon, not just cost?

Rightsizing cuts carbon because energy use scales with the capacity a workload occupies, not with the work it does. A virtual machine provisioned at four times the size it needs holds physical compute, memory, and the cooling and power overhead that come with them, and that infrastructure draws energy continuously regardless of utilization. When you rightsize to the real demand, the provider can pack the freed capacity more densely or power down hardware, and the Scope 2 emissions attributable to your workload fall in step. The carbon reduction is roughly proportional to the energy removed, which is roughly proportional to the cost removed.

This is why a cost audit is the most efficient first step on sustainability. The work is already justified on the bill, and the carbon benefit arrives without a separate project. To see the footprint move, measure before and after with each provider's native tool, covered in how to measure cloud carbon emissions across providers.

What is the right order to capture both?

Capture the most cost and carbon by removing whole resources before shrinking the ones that remain, then commit last. The order is deliberate, because each step changes the baseline the next one works against:

1. Switch idle resources off. Non-production environments, dev and test fleets, and anything outside business hours can be scheduled off. An instance that is off draws no power, so this saves the most carbon per resource.
2. Delete zombie infrastructure. Unattached disks, idle load balancers, orphaned snapshots, and forgotten instances cost money and draw energy for nothing. Remove them entirely.
3. Rightsize what is left. Match each remaining instance to its real utilization, dropping a size or changing family where the data supports it.
4. Move suitable workloads to efficient hardware. Shift compatible workloads to Arm-based instances, which do the same work with less power.
5. Commit on the clean baseline. Only now buy reservations or savings plans, against a fleet that reflects real demand rather than the old waste.

Committing before rightsizing is the most common and most expensive mistake, because it locks the waste in for the term. This ordering is the Cut phase of our See, Cut, Lock, Run method, and it is what a full FinOps implementation sequences for you.

How big is the saving in practice?

The saving depends on how over-provisioned the estate is, and most are more over-provisioned than they expect. Industry analysis consistently puts roughly a third of cloud spend into waste, and our own cross-cloud average is a 31% reduction in the monthly bill once the waste is cleared and the fleet is rightsized. Because the carbon attributable to a workload tracks its energy draw, a fleet that costs a third less also emits materially less for the same delivered work. The exact carbon figure varies by region, because the same kilowatt-hour is dirtier on a coal-heavy grid than a hydro-heavy one, which is the subject of how to choose low-carbon cloud regions.

Common questions about rightsizing and carbon

Does rightsizing reduce carbon emissions?

Yes. An over-provisioned instance draws power for capacity it never uses, so shrinking it to fit actual demand cuts energy consumption and therefore Scope 2 emissions, at the same time as it cuts cost. The carbon saving is roughly proportional to the energy removed.

What saves more carbon, rightsizing or turning resources off?

Turning idle resources off saves more per resource, because an instance that is off draws no power at all, while a rightsized instance still runs. Do both: switch off what is unused, then rightsize what remains to fit demand.

Should I rightsize before or after buying commitments?

Always rightsize first. Buying a reservation or savings plan against an over-provisioned baseline locks in the waste for the term of the commitment, paying for energy and capacity you do not need. Rightsize and clean up first, then commit on the clean baseline.

Written by Morten Andersen and reviewed by Fredrik Filipsson, applying our See, Cut, Lock, Run method. Independent and vendor neutral.