A fleet of 200 instances averages 15% CPU and 85% memory. Finance wants a 40% cost reduction. What do you do?

The diagnosis

The instance family is wrong. 15% CPU and 85% memory means the workload is memory-bound running on general-purpose or compute-optimised instances, so you are paying for CPU that will never be used.

The moves, in order of return per unit of effort

1. Change family to memory-optimised. For the same cost, a memory-optimised instance gives roughly two to four times the memory per vCPU. Since memory is the binding resource, that means far fewer instances serve the same load. This alone can approach the target.

2. Move to a newer generation. Usually cheaper and faster for the same nominal size — one of the rare free optimisations, and frequently skipped because nothing forces it.

3. Evaluate ARM. Graviton, Ampere or Cobalt typically give materially better price-performance for anything not tied to x86, which for a modern managed runtime is most workloads. Requires a rebuild and a test, not a rewrite.

4. Then right-size within the family, from measured peak plus headroom rather than from the size someone first chose.

5. Only then apply commitments. Reserved instances or savings plans on the corrected baseline. Committing first locks in the oversizing for one to three years, which is the most common sequencing error in cost programmes.

What I would check before promising the number

Whether memory at 85% is real working set or garbage-collector headroom. A JVM or .NET runtime configured with a large heap will use it regardless of need; the fix there is heap configuration, not a different instance.

Whether the 200 instances are needed for capacity or for redundancy. If they are spread across zones for availability, consolidation reduces failure isolation, and that trade should be explicit.

What the actual peak is. Averages hide it. Sizing from average utilisation produces an outage at peak.

What a strong answer adds

Naming the sequencing rule explicitly: delete the unused → right-size → schedule non-production shutdown → then commit. And noting that non-production environments running 24/7 are frequently 60–70% of their own cost, which is often a larger and easier win than anything in the production fleet.