Cloud rightsizing for engineering teams paying for oversized instances on AWS and Google Cloud

Cloud rightsizing is matching each instance to the load it actually carries. Most teams on AWS and Google Cloud have a handful of oversized cloud instances: sized once at launch, for a load that never came, and billed every hour since. Rightsizing finds them from utilization data and moves each one to a smaller size that still fits.

This post is for the engineers who have to make that call. It covers the signals that show an instance is oversized, how to read CPU and memory without fooling yourself, what AWS and Google Cloud recommend on their own, and the risks to check before you downsize anything in production. For the exact EC2 and RDS commands, see the companion guide on rightsizing EC2 and RDS.

What cloud rightsizing is, and what it isn’t

Rightsizing changes the size of something that’s in use. That separates it from the other common fixes:

• An instance that does nothing all day isn’t oversized, it’s idle. The fix is to stop it, not shrink it: see idle EC2 instances.
• A dev or staging instance that’s busy during the workday and idle at night needs a schedule, not a smaller size: see scheduling dev and staging.
• A Savings Plan or committed use discount lowers the price of the size you run. It doesn’t change the size, so it should come after rightsizing, not before.

Within an instance family, each size down halves the vCPUs and the memory, and roughly halves the price. As of October 2026, an m5.2xlarge costs $0.384 an hour on demand in us-east-1 and an m5.xlarge costs $0.192 (EC2 pricing). That one step saves about $140 a month for a single instance that runs all month.

Why cloud instances end up oversized

Nobody launches an instance meaning to waste money. Oversizing comes from reasonable decisions that never get revisited:

• Sized for a forecast. The launch plan expected ten times the traffic the service gets today.
• Copied from somewhere else. An infrastructure template uses m5.2xlarge for every service because the first one needed it.
• Sized after an incident. Someone doubled the size during an outage, and the real cause turned out to be a slow query.
• Lifted from on-premises. A migration matched the old server’s specs, which were bought for five years of growth.
• The load moved. A queue consumer lost half its work to a new service, and kept its size.

Each of these leaves an instance whose CPU barely moves. The bill doesn’t show it, because the bill only shows what an instance costs, not how much of it you use.

How to spot oversized cloud instances

Utilization tells you, as long as you read it the right way. Four rules keep the reading honest.

Use the peak, not the average. An instance that averages 10% CPU might hit 90% for twenty minutes every night during a batch job. Halving it would make that job slower or fail. Look at the daily maximum, or the 95th or 99th percentile, over the whole window.

Use a long enough window. Two weeks covers weekday and weekend patterns. If the workload has a monthly cycle, such as month-end billing or reporting, look at 30 days or more so the busiest days are in the data.

Check every resource, not just CPU. Memory, network and disk throughput can each be the real limit.

Leave headroom. The point is to stop paying for capacity nobody uses, not to run every instance at 95%.

The rule Omni FinOps uses is simple: if an instance’s CPU never peaked above 40% in two weeks, half the vCPUs still leave headroom above that peak, so it can move one size down. On the smaller size, the same work peaks around 80%. That’s busy, not saturated.

To pull the daily peak for one EC2 instance from CloudWatch:

aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-0123456789abcdef0 \
  --start-time 2026-09-28T00:00:00Z --end-time 2026-10-12T00:00:00Z \
  --period 86400 --statistics Maximum \
  --query 'sort_by(Datapoints, &Timestamp)[].[Timestamp, Maximum]' \
  --output table

Memory: the half CPU metrics don’t show

CPU is measured by the hypervisor, so every cloud reports it without any setup. Memory is measured inside the operating system, so it isn’t. On EC2, CloudWatch has no memory metric unless you install the CloudWatch agent. Without it, a rightsizing decision on CPU alone is a guess about the other half of the instance.

AWS Compute Optimizer works the same way: it analyzes memory only for instances running the CloudWatch agent, or when it ingests memory metrics from Datadog, Dynatrace, Instana or New Relic (AWS docs). On Google Cloud, machine type recommendations use CPU and memory, and Google recommends the Ops Agent to make them more accurate (Google Cloud docs).

If you can’t install an agent everywhere, use what the application already reports. A JVM’s heap usage, a database’s buffer pool, or a container’s memory limit and usage tell you what you need. Then check one more thing: settings sized to the old memory. A Java service started with -Xmx12g on a 16 GiB instance won’t fit on an 8 GiB one until you change the flag.

AWS EC2 rightsizing with Compute Optimizer

AWS Compute Optimizer is the native tool for AWS EC2 rightsizing. It has no additional charge (pricing) and needs at least 30 hours of CloudWatch data in the past 14 days for an instance or Auto Scaling group (AWS docs). It looks at the maximum utilization in each five-minute interval over that period (AWS docs), which is the right way to read peaks.

Fourteen days misses a monthly cycle. The enhanced infrastructure metrics option extends the lookback to 93 days, for $0.0003360215 per resource per hour as of October 2026, about $0.25 a month for an instance that runs all month (pricing).

To list only the instances it considers over-provisioned:

aws compute-optimizer get-ec2-instance-recommendations \
  --filters name=Finding,values=Overprovisioned \
  --query 'instanceRecommendations[].[instanceArn, currentInstanceType,
      recommendationOptions[0].instanceType]' \
  --output table

Treat its answer as a second opinion. Its first option is sometimes a different family or a Graviton type, which saves more but needs an arm64 build: see moving to Graviton. To show savings, Compute Optimizer needs Cost Explorer enabled, and AWS recommends opting in to Cost Optimization Hub so the estimates account for your Savings Plans and Reserved Instances.

Rightsizing on Google Cloud

Compute Engine generates machine type recommendations at no charge, from Cloud Monitoring data over the previous 8 days (Google Cloud docs). They don’t cover every VM: instances with GPUs, TPUs or ephemeral disks, memory-optimized machines, and VMs created by Google Kubernetes Engine, Dataflow or App Engine flexible are left out.

gcloud recommender recommendations list \
  --project=my-project --location=us-central1-a \
  --recommender=google.compute.instance.MachineTypeRecommender

Eight days is a short window. Before you act on a recommendation, check the VM’s CPU over a longer period in Cloud Monitoring, especially for anything with a weekly or monthly batch.

Google Cloud has one option AWS doesn’t: custom machine types, where you set the vCPUs and memory yourself. If a VM needs its memory but not its CPU, a custom shape can drop the vCPUs without dropping memory.

Downsizing safely: the risks to watch

A smaller size is a production change. Check these before each one.

• It needs a restart. On both clouds, changing a standalone instance’s type means stopping it. Plan a window, or move traffic first.
• Auto Scaling groups and managed instance groups undo manual changes. Change the launch template or instance template, then roll it out. Resizing one member by hand only lasts until the next scale event.
• Smaller sizes have lower network and disk limits. A proxy, a file server or a database replica can hit those before CPU.
• Burstable types are cheaper until they aren’t. A t3.large has a 30% CPU baseline. In unlimited mode it costs the same as an m5.large at 42.5% average CPU, and more above that (AWS docs).
• Infrastructure code still says the old size. Change Terraform, CloudFormation or Helm values too, or the next deploy puts it back.

Move one size at a time. If two steps look possible, take one, watch it for two weeks, then decide again. Keep the rollback ready: it’s the same change with the old type.

Make rightsizing a habit, not a project

A one-time rightsizing sweep decays. New services launch at the old sizes, and load shifts. A monthly pass over the candidate list keeps the savings, and it takes minutes once the list is ranked by monthly saving.

The order matters too. Rightsize before you buy commitments, or a Compute Savings Plan locks in spend you were about to remove. And watch the other direction: an instance averaging above 80% CPU is a performance risk, not a saving, and should move up a size.

Omni FinOps does this pass on every refresh. It reads CloudWatch CPU for EC2 and RDS on AWS and Cloud Monitoring CPU for Compute Engine on Google Cloud, read-only, and flags each instance whose peak stayed under 40% for two weeks. Each lead names the size one step down, the monthly saving at list price, and the exact command, or an instance refresh for Auto Scaling groups. It also notes when memory isn’t measured, so you check it before resizing.