When Discounts Lock In Waste – Reserved Instances vs. Sustainability

Reserved Instances and long-term commitments are some of the sharpest tools in the FinOps toolkit. Commit to capacity for one or three years, and you can unlock substantial discounts compared to on-demand pricing. For many organizations, these deals are how big cloud bills become politically acceptable.

But from a GreenOps perspective, those same commitments can quietly freeze inefficient architectures in place. But noboday wants to “lose money”

Why FinOps loves commitments

In the FinOps mindset it is all about financial accountability and predictability:

• Lower unit costs via reservations, savings plans, or committed-use discounts.
• Higher coverage of baseline workloads with discounted capacity.
• Better forecasting and fewer budget surprises, whatever is most predictable.

If you have a stable, well-understood workload, committing to capacity makes sense, you know your system best. The problem is that many organizations commit before their workloads are truly optimized and it became a wide phonemena. Overprovisioned instances, idle services, or legacy sizing assumptions get embedded into multi-year contracts.

From a pure FinOps perspective, once a reservation is bought, the incentive is to “keep it utilized” to justify the discount—even if a leaner architecture would be both cheaper and greener in the long run.

See Avishi Ish-Shalom talk “Let’s talk about limits” for some of the problems that might arise from oversized instances: link

How commitments collide with GreenOps

GreenOps asks a different question: “What is the minimal, efficient amount of infrastructure needed to deliver the required business outcome, at the lowest environmental cost?”

Here’s where the collision happens:

Oversized instances on long-term reservations

A team commits to large instances “just in case” and gets a great discount. A year later, usage data shows they could safely run on instances 30–40% smaller, or even on autoscaling spot fleets. But migrating would strand some of the committed capacity.

Legacy architectures you can’t decommission

Older monoliths reserved for three years become politically harder to refactor or replace, because leaders see them as “already paid for.” Meanwhile, they keep drawing power at higher-than-necessary levels.

Region and SKU lock-in

Discounts tied to specific regions or instance families can discourage moving workloads to greener regions or newer, more energy-efficient chips.

In all three cases, the GreenOps answer would be: “Right-size, modernize, and move.” The FinOps answer, narrowly applied, becomes: “Keep the reservations utilized.”

Designing a commitment strategy that doesn’t fight sustainability

The good news: FinOps and GreenOps do not have to be enemies here. With a few adjustments, the same financial mechanisms that reduce cost can also support sustainability.

Some practical patterns:

Optimize first, commit second

Treat rightsizing, idle resource cleanup, and basic elasticity as prerequisites to any major commitment. Analyze 3–6 months of stable usage data before locking in capacity.

Favor flexible discount models where possible

Some commitment programs are less rigid about instance family or region. Using these more flexible constructs gives you room to adopt newer, more efficient SKUs or shift workloads as carbon data improves.

Make carbon a first-class KPI in commitment decisions

When modeling “savings” from a reservation, include both:

• Direct financial impact
• The carbon profile of the architecture you’re locking in

A three-year discount on a dirty, oversized setup might not look so attractive when emissions are part of the business case.

Timebox legacy commitments with refactor roadmaps

If you must reserve inefficient but business-critical workloads, pair the commitment with an explicit refactoring plan. For example: year 1 spent on observability and modularization, year 2 migrating pieces to more efficient services, year 3 reducing commitment or shifting to greener regions.

Shifting the narrative: from “utilization” to “intentionality”

One subtle but important change is cultural. FinOps conversations often revolve around “reservation utilization” as a success metric. GreenOps encourages a different framing: “Are we intentionally using the right amount of the right infrastructure?”

A 95% utilized reservation for an overpowered instance type is not success from a sustainability perspective. A 70% utilization rate during a planned migration to a cleaner, more efficient architecture might be exactly the right strategic tradeoff.

When FinOps and GreenOps teams sit together, long-term commitments stop being purely financial instruments and become part of a broader sustainability strategy. The goal is not simply to minimize your effective rate—it is to ensure that every committed unit of capacity represents infrastructure you are genuinely proud to keep running for years.