Does Saving Money Cost the Planet? How Anne-Gaëlle Roux Is Unifying FinOps and GreenOps from the Inside

Most organisations treat FinOps and GreenOps as separate functions: separate teams, separate dashboards, separate reporting lines. Anne-Gaëlle emphasizes the importance of creating connections between these two disciplines. Her perspective is grounded in the realities of governance transformation: building FinOps practice with top-down mandate, navigating organisational silos, and holding the line on cloud discipline when hyperscalers' commercial interests sometimes run in the opposite direction. She has agreed to share her insights on building resilient FinOps practices in enterprise environments, the intersection of financial and environmental responsibility, and practical strategies for establishing cloud governance in complex organisations.

For most enterprises, FinOps and GreenOps live in separate organisational compartments. The sustainability team reports CO2 metrics upward. The FinOps team optimises spend. The two functions do not necessarily talk to each other. Anne-Gaëlle saw the connection before her organisation did, and spent years advocating for an integration that is still, by her own assessment, largely unfinished business.

Two dashboards, two teams, one practitioner trying to bridge them.

Q: As a FinOps practitioner, how did you come to connect it with GreenOps, and why do you see the two as inseparable?

I've always linked the two. For me, it was obvious they belonged together. But that's far from a shared instinct inside most enterprises. However, we have common interests within organizations that are willing to take their carbon footprint into account. When I started on this topic five years ago, I was quite literally preaching in the desert, within my own organisation. What changed over the last three or four years is that the concept has worked its way into C-suite conversations, often via consulting firms or external pressure. Today, the conversation is less about convincing people FinOps is necessary, and more about giving practitioners the governance structure and budget to actually operationalise it. But the FinOps and GreenOps integration? That part is still largely a work in progress.

On the surface, GreenOps looks like FinOps with a different unit of measurement: carbon instead of currency. In practice, it is far more structurally complex. The tools that report CO2 emissions are provided by the same hyperscalers whose consumption generates them. Financial savings and carbon reduction are tracked in parallel but never bridged. And when region selection creates both a cost differential and a carbon differential, the information that should shape the architect's decision often never enters the room.

France runs on nuclear; Germany on a mixed grid. The carbon differential rarely makes it into the architect's decision.

Q: Is GreenOps just a swap of metrics (carbon instead of dollars), or is it more structurally complex than that?

It's far more complex, and that's the problem. Today, carbon footprint KPIs and financial savings are completely decoupled. The tools that measure CO2 emissions (mostly provided by the CSPs themselves) don't tell you what a reduction in emissions is worth in euros or dollars. There is no bridge. You have one team reporting a carbon footprint figure, and another team reporting spend. Neither is leveraging the other's data as a lever. And when the CSPs are both the data provider and the entity being measured, you have an inherent conflict of interest. They are, as I'd put it, judge and party in the same process.

There are moments of convergence, though. Architecture decisions involving region selection are one of them. Choosing between France (which runs predominantly on nuclear energy) and Germany, which has a more mixed grid with coal, creates both a cost differential and a carbon differential. GreenOps can surface that second dimension for the architect who might otherwise only look at the price tag. Whether the organisation actually weights it is another matter. Today, without financial penalties for higher emissions, most will still follow the lower cost. But at minimum, that information should be in the room.

The financial incentive and the ecological imperative do not always pull in the same direction.

Commitment-based instruments like Saving Plans are cornerstones of cloud cost optimisation. They are also, in certain configurations, structurally at odds with one of GreenOps' foundational principles: decommission what you are not using. When a discount requires a resource to run for a minimum number of hours, the financial logic can quietly override the ecological one, and most organisations never notice the contradiction.

Developers rarely have cloud spend as a personal objective. Cost reduction is an abstraction, a corporate goal that lives in someone else's OKRs. Environmental responsibility, on the other hand, is personal. Anne-Gaëlle has found that reframing the ask (from financial to ecological) unlocks behaviour change that years of FinOps advocacy could not.

The gap is not skill. It is prioritisation. No one asked, so no one built it.

Q: How do you get developers (who typically don't have cost as a personal objective) to actually care about these questions?

Here's what I've observed: framing matters enormously. A developer who doesn't particularly care about reducing cloud spend will often care deeply about not wasting energy. They turn off the lights at home. They're conscious of their individual footprint. When you bring the same logic into their codebase (asking them to build in auto-termination for non-production environments, scheduling infrastructure to run only Monday to Friday between business hours), they're receptive. More than receptive: they sometimes ask why no one asked them to do this sooner.

The technical ask is minimal. A few lines of code. A variable. It's not complex. The gap isn't skill. It's prioritisation. If the business never formally expresses this as a requirement, it lands in the backlog and stays there. We end up in a loop where no one is asking for it because no one is being charged for it, and no one is being charged for it because no one built the awareness to demand it.

European regulation mandates carbon reporting but imposes no financial penalties for rising emissions. The 2030 targets have already slipped to 2050. In this enforcement vacuum, a striking inconsistency has emerged: organisations that apply no internal carbon targets will rigorously audit their suppliers on sustainability practices. However, a paradox remains.

The legislation implies urgency. The enforcement says otherwise.

Q: Where does legislation fit? Is regulatory pressure actually driving behaviour today?

Not yet, not in a meaningful way. Today's legislation mandates reporting, not reduction. There are no financial penalties for increasing your carbon footprint year over year. No company receives a fine for choosing a more carbon-intensive cloud region because the price was lower. The EU's 2030 zero-carbon targets have been pushed to 2050. So the urgency the legislation implies hasn't translated into organisational urgency. Companies do what they're measured and penalised on. Right now, they're not penalised on emissions.

However, in certain companies, procurement exhibits a striking paradox. The same organisations that have no internal carbon targets will rigorously audit their external suppliers on sustainability practices, weighting those criteria in vendor selection decisions. What you demand externally but don't apply internally is, at best, inconsistency, and at worst, a form of performance theatre. The coherence has to go both ways.

Even in organisations with mature FinOps practices, AI has introduced a layer of cost complexity that existing tooling was not built for. Costs are distributed across logs and data sources that must be aggregated before they can be attributed. Building the dashboards to deliver real-time visibility can take months, and during those months, spend scales exponentially.

The moment you stop paying attention, it boils over.

Q: How are AI workloads changing the FinOps equation for organisations that thought they had cloud cost governance under control?

AI workloads have reopened questions we thought we had answered. Even in organisations with a mature FinOps practice, AI introduces a new layer of complexity that traditional tagging simply cannot address. Costs are distributed across logs and multiple data sources that must be aggregated before they can be attributed. Building the dashboards to do that properly, to have a real-time view, can take months. During those months, costs can scale exponentially. I use the image of watching milk on the stove: the moment you stop paying attention, it boils over.

What's happening in practice is that the AI cost challenge is actually re-engaging business teams on FinOps governance frameworks they thought they'd already mastered. Teams that had stabilised their cloud optimisation work are discovering that AI has disrupted some of those certainties. When you can lean on business teams who already have FinOps maturity, you can move faster to close the visibility gap, but you have to plan and budget for that work from the start, not after the bills arrive.

Anne-Gaëlle's vision for maturity is deceptively simple: cost annotations on architecture diagrams. Not a separate spreadsheet. Not a budget review at the end of the design cycle. A symbol (low, medium, high) visible to finance, engineering, and business stakeholders simultaneously, at the moment the decision is being made. When cost literacy becomes ambient rather than argued for, the culture has crossed a threshold that no governance policy alone can achieve.

When cost is in the diagram, it stops being a separate agenda item.

Q: In your opinion, what characteristics should a mature FinOps and GreenOps practice exhibit within an organisation?

My ambition is that cost thinking becomes native to architecture design, not a correction applied after the fact. What I'm trying to promote at my level is having architecture diagrams that already carry cost annotations: a simple symbol indicating whether a storage component is low-cost, medium-cost, or high-cost. That's it. Not a separate spreadsheet. Not a budget discussion at the end of the design review. The cost signal is embedded in the diagram itself, visible in decision-making committees, simultaneously to finance teams, technical teams, and business owners.

When cost is part of the architecture diagram, it stops being a separate agenda item. People absorb it passively. It becomes part of how they think, without having to be argued for each time. When that kind of embedded cost literacy makes its way into senior architects' standard patterns (into the catalogue of building blocks they hand to junior engineers), you've crossed a threshold. The conversation shifts from "do we need to think about cost" to "of course we do, it's already in the diagram." That's the culture I'm working toward.

Anne-Gaëlle Roux's practice is a reminder that FinOps, at its best, is not a cost-cutting function. It is an organisational capability that enables faster, more confident decision-making about how resources are deployed and to what end. The integration of GreenOps into that practice is not an added burden; it is the next logical frontier for practitioners who have already mastered spend visibility and optimisation.

For senior leadership, the strategic imperative is clear: organizations capitalizing today on both financial responsibility and environmental responsibility in cloud operations will move faster, waste less, and face regulatory reckoning with confidence, while those who keep the disciplines siloed will find themselves rebuilding from scratch when the rules change.

The perspectives expressed reflect the interviewee's personal experience and views. Cloud Value Lab publishes practitioner-led thought leadership at the intersection of FinOps, GreenOps, and AI Economics.