Most AWS environments are sized once, under pressure, and never revisited. An instance gets picked during a migration or a launch — usually erring generous, because nobody wants to be the reason a production workload falls over — and then it just sits there. Eighteen months later, that “temporarily generous” choice is still running, still being billed at the same rate, and nobody remembers why it’s an m5.2xlarge instead of something half the size.

This is the single biggest reason AWS bills creep upward without any corresponding growth in what the business actually does. Manual right-sizing doesn’t fail because engineers are careless — it fails because it doesn’t scale. Reviewing CloudWatch utilisation graphs instance-by-instance is fine for five servers and completely impractical for two hundred. Left to manual review, right-sizing becomes something that happens during a cost crisis, not something that happens continuously.

Why manual right-sizing quietly stops happening

The problem compounds because resizing feels riskier than leaving things alone. Downsizing an instance carries a visible, immediate risk (what if it’s too small during next month’s peak?), while overpaying carries an invisible, diffuse one (a slightly bigger bill, buried in a much larger monthly total). Faced with that asymmetry, most teams default to inaction — which is exactly the opposite of what the data usually supports.

What Compute Optimizer actually does

AWS Compute Optimizer is a free service, already available in every account, that removes the guesswork from this decision. It analyses CloudWatch utilisation history for EC2 instances, Auto Scaling groups, EBS volumes, Lambda functions, and ECS services on Fargate, and returns specific recommendations — not vague “consider downsizing” advice, but named instance types and sizes, alongside a projected utilisation for each option.

Three things make it more useful than eyeballing a dashboard:

  • It’s finding-based, not threshold-based. Rather than flagging “CPU under 10%” as a rule of thumb, it models how the workload would actually behave under a different instance type, using the account’s real historical performance data.
  • It scores risk, not just savings. Every recommendation carries a performance risk rating (Very Low through High), reflecting how confident the model is that the change won’t degrade performance under observed usage patterns.
  • It works at the estate level. Through the organisation-wide view, a multi-account environment gets one consolidated list of opportunities rather than someone manually checking each account in turn.

Reading the recommendations correctly

Not every recommendation is worth acting on immediately. The risk rating is the first filter: Very Low and Low risk items are the genuine quick wins — cases where the workload has consistently and predictably used a fraction of the provisioned capacity, with enough history behind the recommendation to be confident. Medium and High risk items deserve a conversation before anyone touches them, not automatic action.

It’s also worth understanding the three finding categories Compute Optimizer uses: over-provisioned (paying for capacity that’s consistently unused), under-provisioned (the opposite problem — a resource occasionally starved, which shows up as latency or throttling rather than an obvious cost signal), and optimized (no change recommended). Over-provisioned findings are where most of the savings live for a typical SME environment, but under-provisioned findings matter too — they’re often the quieter cause of intermittent performance complaints that never get traced back to instance sizing.

Where the tool falls short

Compute Optimizer is a strong starting point, not a complete answer, for a few reasons worth knowing before treating its output as gospel:

  • It needs enough history to be confident. A workload that’s genuinely seasonal or bursty (end-of-month batch processing, a once-a-quarter reporting job) can look over-provisioned for most of the year and still need that capacity when it matters. Recommendations are only as good as the observation window behind them.
  • It doesn’t know your commitments. A recommendation to move off an instance family you’ve already committed to via a Reserved Instance or Savings Plan can undercut the value of that commitment — the tool and your commitment strategy need to be reconciled together, not read independently. (Worth double-checking Compute Optimizer’s current level of RI/Savings Plan awareness against AWS’s own documentation before acting, since this has evolved over time.)
  • It doesn’t know your licensing. Software licensed per-core or per-vCPU can make a “smaller instance” recommendation more expensive overall once the licensing implication is factored in — something Compute Optimizer has no visibility into.
  • It doesn’t know your business criticality. A Very Low risk rating means the data supports the change; it doesn’t mean the business is indifferent to that system having an issue.

A practical adoption pattern

The workable approach for most SMEs: enable Compute Optimizer account-wide (or organisation-wide, if running multiple accounts) and treat it as a standing input rather than a one-off audit. Action the Very Low and Low risk, over-provisioned findings on a rolling basis — these rarely need a debate. Route Medium and High risk findings, and anything under-provisioned, into a proper quarterly review where the people who understand the workload’s business context are in the room.

That quarterly rhythm matters more than it sounds like it should. Environments drift — a workload that was correctly sized in January can be meaningfully different by June, simply because usage patterns changed. A rightsizing exercise treated as a one-off event is stale within a couple of quarters.

This is exactly the kind of finding a Yemberzal Cost Optimisation Audit surfaces and correctly sequences — separating the quick wins that can be actioned immediately from the items that need a proper conversation first, and checking recommendations against existing Reserved Instance and Savings Plan commitments before anything gets touched.