Reduce AWS Costs: Right-Sizing and Spot Instances Done Right

The AWS bill goes up every month, and nobody in the company can say exactly why. Behind it there is usually an architecture decision made months or years ago and never revisited. Here is where I start in those cases, and which levers bring the bill down for good.

Key takeaways

• An oversized AWS bill is usually an architecture question first and a pricing question second.
• Right-sizing needs real utilization data over a window that captures actual peaks, and it has to be repeated regularly.
• Spot instances are the largest lever for compute savings, but they only suit workloads that can tolerate interruption.
• Databases and other stateful or latency-critical systems do not belong on spot.
• Budgets with several alert thresholds, cost dashboards per service, and enforced tagging make a cost spike traceable within minutes.

Why high cloud costs are an architecture signal

When I get called in to look at a runaway AWS bill, I don't start in Cost Explorer. I start with the architecture, because an oversized fleet is almost never a pricing problem.

Behind it there is almost always a design assumption from six months or two years ago that nobody revisited. Typical examples:

• An instance type chosen for a peak load that never materialized.
• A database sized for a migration that got postponed.
• A service that scaled out instead of up because that was easier at the time, and nobody went back later to check whether it still made sense.

Treating cost as an architecture signal rather than a finance problem changes where I look first. A consistently underutilized instance tells me how far a workload's original specification is from the way it actually behaves.

Right-sizing based on real utilization data

I never resize on intuition. Before touching an instance type, I pull real utilization data: CloudWatch metrics at minimum and, where available, Prometheus for finer-grained application metrics. The window has to be long enough to capture actual peak behavior. A quiet afternoon is not enough.

Which metrics matter

CPU and memory utilization tell the obvious story. I also look at network throughput and, for anything stateful, disk I/O. That can be where the actual constraint sits, even when CPU looks comfortably low.

Right-sizing as a recurring loop

Right-sizing isn't a one-time exercise. I treat it as a loop: resize, observe the new utilization pattern under real load, adjust again.

The reason is simple. Workloads drift, and a fleet that was correctly sized at launch quietly stops being correctly sized as traffic patterns change.

Spot instances: where they are safe and where they are not

Spot instances are the single largest lever I have for compute savings. They only suit workloads that can tolerate interruption without breaking anything, though.

Good candidates for spot

The clearest fits are batch processing jobs, CI runners, and stateless inference behind a load balancer. If AWS reclaims an instance, the job retries or the load balancer routes around it. Nothing user-facing notices.

What stays on on-demand

Anything stateful or latency-critical, where an interruption has a real cost, stays on on-demand. That means a primary database, a session-holding service, and anything where "just retry" isn't actually free.

The savings on spot are large enough that it is worth deliberately identifying every workload that qualifies. Staying on on-demand everywhere out of caution leaves that money on the table.

Guardrails: budgets, dashboards, and tagging

None of this stays correct without guardrails. I set budgets with alerts at several thresholds rather than one. That way runaway spend shows up before it becomes a surprise at month-end.

On top of that come cost dashboards broken out by service. A spike can then be traced to a specific team or workload within minutes, not after a multi-day investigation.

Tagging discipline is what makes that attribution possible. Every resource is tagged by owner and environment, and this is enforced at provisioning time instead of hoped for after the fact.

What this means for your company

For management, a rising AWS bill is a budget topic first. The cause almost always sits in the technology, though, and that is the only place it can be fixed for good. Across-the-board cuts easily hit the wrong systems, such as a database that cannot tolerate interruption, while oversized instances keep running.

The sensible first step is visibility: which workloads cause which costs, and which of them run far below their capacity all the time. For a first estimate of your own environment, the free AWS cost check gives you a starting point for where your largest levers might be.