Right-size EC2 instance

EC2 pricing is proportional to size: an m5.4xlarge costs almost exactly 4× an m5.xlarge for 4× the vCPUs and 4× the RAM. When a workload only uses 10–15% of that capacity, the team is paying for three or more virtual machines that sit idle every hour. Multiply that across a fleet of dozens or hundreds of instances and the waste can reach six figures annually — without a single failed service or missed SLA.

Right-sizing is the FinOps practice of matching the purchased instance size to measured utilisation. The inputs are CloudWatch CPU and memory metrics, at least two weeks of history, and a recommendation from Compute Optimizer or an equivalent tool. The output is a specific, data-backed change: drop from m5.4xlarge to m5.xlarge, save 75% on those instances, with the tool's projected headroom confirming the workload still fits.

This is one of the highest-return cost optimisation actions available because the savings are immediate and recurring — there's no amortisation lag, no contract to renegotiate, no dependency on a vendor discount. A right-sized fleet also improves the economics of Reserved Instances and Savings Plans: you only commit to the correct shape, so commitments stay fully utilised rather than stranding capacity you no longer need.

At the monthly cloud spend review, Jordan notices that three engineering teams collectively account for $180k of annual EC2 spend with no right-sizing review in the past year. Rather than flag a generic "reduce compute" action, Jordan asks each team for two data points: average CPU utilisation over the last 14 days, and whether Compute Optimizer has been enabled and reviewed.

The largest team comes back with 9–14% average CPU across their fleet of m5.2xlarge nodes and a Compute Optimizer export showing LOW-risk recommendations to drop to m5.large across 18 instances — a 50% reduction per instance. Jordan works the math: $6,200/month savings, $74k annually, with a one-time engineering effort of roughly a sprint to update launch templates and roll the fleet.

Jordan's contribution is framing the ROI clearly: 12:1 return in year one, annualised savings that outrun the next three planned Savings Plan commitments combined, and a quarterly review cadence baked into the FinOps calendar to catch drift before it compounds. The recommendation goes to leadership as a funded line, not an open-ended "we should investigate."

Oversized EC2 instances create a specific type of waste: the cost is fully incurred whether or not the capacity is used. Unlike variable-cost services, a running instance charges the same hourly rate at 5% utilisation as at 95%. A 4× oversized m5.4xlarge fleet of twenty nodes is paying for fifteen nodes of ghost capacity — compute that is provisioned, billed, and idle every hour of every day.

The compounding effect is what makes this a budget issue rather than a line-item rounding error. A single m5.4xlarge in us-east-1 costs roughly $550/month on-demand.A fleet of twenty m5.4xlarge instances in us-east-1 costs roughly $11k/month on-demand. If the workload can safely move to a 4× smaller size, about 75% of that instance spend — roughly $8k/month — becomes recoverable before any RI or Savings Plan commitment is applied. Multiply this across multiple teams and the aggregate is typically 20–30% of total EC2 spend.

The RI/Savings Plan interaction makes oversize specifically expensive to fix later. Commitments purchased against oversized instances are partly stranded the moment the fleet is right-sized: you have a 1-year RI for an m5.4xlarge you no longer run, which now converts to on-demand credit at a discount or sits partially unused. The clean order is right-size first, then commit — and the finance contribution is to hold that sequencing as a standing rule in the commit approval process.

On the chargeback side, oversized fleets inflate the per-unit cost of every team using shared infrastructure. Right-sizing is one of the fastest ways to improve showback accuracy — if a team is charged for 75% idle capacity, their chargeback overstates their real compute consumption and makes cross-team benchmarking meaningless.

Cloud infrastructure is provisioned once and rarely revisited. Engineers pick an instance size for launch day headroom, the workload stabilises at a fraction of that capacity, and the cost quietly compounds at the wrong size for months or years. Right-sizing is the practice of periodically measuring what the workload actually uses and adjusting the instance to match.

The consequence of not doing this is structural overspend — not a single high-cost incident, but a persistent and growing gap between what is being paid and what is being consumed. Across a mid-size cloud footprint, this can easily represent 20–40% of EC2 spend going to idle capacity. Reserved Instances and Savings Plans can reduce the rate, but they do not remove the underlying waste. If commitments are made before right-sizing, the organisation may lock in spend against an oversized baseline.

The leadership question is whether right-sizing is a recurring, governed process or an occasional, reactive one. Organisations that treat it as a standing quarterly review — with Compute Optimizer recommendations reviewed and acted on by default — capture the savings continuously. Those that treat it as a one-off project re-accumulate waste within a few deployment cycles.

At one company, the VP of Engineering used to get a one-line answer to "are our EC2 costs optimised?": "we think so." After the FinOps team instituted a quarterly right-sizing review — Compute Optimizer recommendations reviewed, actioned, and documented by default — the answer changed to a dashboard: $X recovered last quarter, Y instances resized, fleet average utilisation at Z%.

The VP's insight wasn't that the numbers were impressive. It was that right-sizing had become a routine rather than a reaction. The team was no longer scrambling to find savings after a budget overage; they were systematically returning capacity to the pool before it showed up on a quarterly report as a problem.

That's the right end state: not a one-time project that recovers savings and drifts again, but a standing process — Compute Optimizer as a feed, a 30-minute review every quarter, and launch templates updated before commitments are signed. Right-sizing as organisational muscle memory, not a heroic effort.

Oversized EC2 fleets are the cloud equivalent of leased office space that's never fully occupied: the cost is fixed and fully committed, but a large fraction of the capacity sits idle. Unlike a lease, cloud compute can be right-sized in a matter of hours — so persistent oversize is evidence of a process gap, not a technical constraint.

The governance issue is that instance size decisions are usually made at launch and rarely revisited. Engineering teams optimise for performance headroom and operational simplicity; finance teams optimise for cost. Without a shared, recurring process that surfaces utilisation data and ties it to a spend decision, instance sizes drift in one direction only: up. Bigger is always safe; smaller requires evidence and approval.

The second-order cost is distorted commitments. Reserved Instances and Savings Plans — the organisation's primary mechanisms for getting cloud discounts — work best when applied to a right-sized baseline. Committing to the wrong instance size effectively locks in the waste at a discount, making it more expensive to correct later than to catch now.

The fix is organisational: make right-sizing a standing quarterly review with a clear owner, a standard output (Compute Optimizer export, savings estimate, change plan), and finance sign-off on commit sequencing. That converts right-sizing from a heroic one-time effort into a continuous process with predictable returns.