Three Ways to Cut Cloud Spend, and When Each One Works

Rightsizing means matching what you provisioned to what you actually use: shrinking an oversized database instance, turning off a staging environment overnight, or deleting storage nobody's touched in a year. It's the fastest lever because it usually needs no code changes, just a review of utilization metrics against what's running.

Its limit is that it only recovers waste. Once everything running is actually being used, rightsizing has nothing left to give you, and the next dollar of savings has to come from one of the other two levers.

Committing to a term (a reserved instance, a savings plan, whatever your provider calls it) trades a discount on compute for a promise to keep paying for it, whether or not you end up using it. This works well once your baseline usage is stable and predictable, and poorly if you're still figuring out what your steady-state footprint even looks like.

A reasonable rule: commit on the portion of your usage that's been flat for a few months, and leave anything still growing or shrinking on demand pricing until it settles.

This is the lever that actually changes how much your product needs, rather than how much you're paying for what it needs today: moving a workload to a cheaper storage tier, batching jobs that were running constantly, or redesigning a service that was over-provisioned by its original architecture. It takes engineering time to plan and ship, but the savings compound instead of being a one-time cleanup.

Save this lever for the workloads where rightsizing and commitments have already been exhausted and the bill still doesn't make sense for what the workload actually does. A service that's ten times more expensive than a comparable one elsewhere in your stack, with no clear reason why, is usually the first candidate worth this level of attention.

Say your monthly cloud bill is $40,000. A rightsizing pass might typically find idle staging environments, oversized instances, and orphaned storage worth cleaning up first, often the fastest win available. Committing the stable portion of your compute usage to a discount plan is the next step, once you know what's actually steady. Only after both of those would it make sense to consider redesigning the specific service that turns out to be the biggest remaining line item.

Do them in this sequence, and stop as soon as the savings stop justifying the effort:

• Rightsize first, because it's fast and usually needs no engineering sign-off
• Commit next, once you can see which usage has actually stabilized
• Redesign last, and only for the specific workloads still worth the engineering time

Trying to do all three simultaneously usually means none of them gets finished, because each one competes for the same reviews and the same engineers.

Cost review tends to fall through the cracks on small teams because it belongs to everyone and no one at the same time: engineers provision what they need without seeing the bill, and whoever does see the bill often isn't the person who can change how a service is built. Naming one owner, even part time, fixes most of this without adding headcount.

That person doesn't need to be your most senior engineer. They need standing access to billing data, the authority to ask why a resource exists, and a recurring slot, monthly is usually enough, to actually look. Without that combination, cost review turns into a scramble that only happens after the bill has already jumped.