What is GreenOps?
GreenOps adds carbon and energy use to the metrics that an operations team already tracks. FinOps made cloud spending someone’s responsibility by placing cost alongside latency and error rate. GreenOps does the same with emissions, and it works for the same reason: when something becomes visible, someone becomes accountable for it.
The relationship to FinOps is the thing to get right at the outset, because treating them as separate programmes is the most common way this fails.
| Discipline | What it adds, and what it shares |
|---|---|
| FinOps | Financial accountability for variable cloud spend. Cost per unit of value as a first-class metric |
| GreenOps | Environmental accountability over the same estate. Carbon per unit of value, measured as grams of CO2 equivalent per request, inference or job |
| What they share | The same tagging, the same dashboards, the same rituals. An untagged resource is invisible to both, which is why attribution is the foundation of each |
The practical consequence, and the reason adoption accelerated: in the cloud, inefficiency has two prices and one cause. An idle instance bills you and emits for the same reason, so a single remediation serves two mandates that previously competed for attention and budget.
What causes unnecessary energy use in cloud environments?
Capacity that exists without doing anything useful. Somewhere between a fifth and a third of enterprise cloud spend goes to idle or barely-used resources on industry estimates, and the energy follows the same curve, since hardware draws power regardless of whether a workload is hitting it.
Five sources, in roughly the order they are worth hunting.
- Zombie resources. Instances, volumes and load balancers nobody switched off after a project ended. No owner, no usage, full consumption.
- Overprovisioning. Capacity sized for a peak that happens twice a year, running at that size for the other three hundred and sixty three days.
- Static scheduling. Non-production environments running overnight and at weekends because nothing turns them off, which is often the largest single win and the easiest.
- Carbon-blind placement. Regions differ substantially in the carbon intensity of their grid. The same workload in two regions emits different amounts for identical cost.
- Data nobody reads. Logs, snapshots and backups retained indefinitely because retention was never revisited after the policy was written.
The first three are the same list a FinOps programme would produce, which is the point. What GreenOps adds is the fourth, because carbon-aware placement is invisible to a cost dashboard: moving a workload to a cleaner region can cut emissions substantially while the bill barely moves.
How do you reduce cloud waste with GreenOps?
You do it in two ways. First, make resource use follow demand instead of staying fixed. Second, treat the choice of where to run each workload as a real decision rather than accepting a default. Most waste comes from capacity that sits there whether or not there is any work for it. The core idea is to close the gap between what is provisioned and what is needed.
Four practices, ordered by effort against return.
- 01
Terminate what nothing is usingThe unglamorous first step, and usually the largest. Why it leads: it requires no architectural change and no performance trade-off, because nothing is depending on the resource being removed.
- 02
Schedule non-production to the working dayDevelopment and test environments stopped overnight and at weekends. Why it leads: roughly two thirds of the week is outside working hours, and nobody notices an environment that was asleep while they were.
- 03
Right-size against observed demandCapacity matched to what the workload actually uses rather than what somebody estimated at design time. What it needs: usage history, which is why this comes after measurement rather than before.
- 04
Treat compute as a steerable loadFlexible work, meaning batch jobs, training runs and data pipelines, scheduled for when and where the grid is cleaner. The constraint: only work that can wait is eligible, so this applies to a subset rather than to everything.
A note on sequencing that saves a lot of argument. The first two are pure waste removal and need no sustainability mandate to justify them, so they can start under an existing FinOps programme while the carbon reporting is still being built. Teams that wait for the measurement apparatus before acting lose a year of the easiest savings.
How do you track GreenOps improvements?
With the same attribution FinOps already needs, extended by one dimension. Every resource carries an owner, an application and an environment; GreenOps adds energy and the carbon intensity of wherever it ran. Without that tagging neither discipline can report anything useful.
The metric that matters is a ratio rather than a total, because totals go up when the business grows and tell you nothing about efficiency.
- Carbon per unit of value. Grams of CO2 equivalent per request, per job or per inference. The direct analogue of cost per unit, and the only number that survives a growing business.
- Carbon intensity of placement. Which regions your workloads ran in and what the grid was doing. This is the measure that moves when nothing else changes.
- Utilisation against provisioned. The gap between the two is the waste, expressed in a way an engineer can act on directly.
- Share of the estate with an owner. A governance metric rather than an environmental one, and it predicts the others, because unattributed resources are where zombies accumulate.
One caution on the numbers themselves. Cloud carbon figures are estimates built on provider models, grid averages and allocation assumptions, and they are not comparable between providers or tools. That makes them sound for tracking your own trend over time and unsound for benchmarking against another organisation, which is a distinction worth establishing before anybody puts a figure in a board pack.
What changes when the workload is agentic?
Everything above rests on one premise, and that premise no longer holds. These practices work because provisioned capacity is easy to see and can be shut down whenever you choose. Agents are different. They are billed per action, they decide at runtime how many actions to take, and they never leave an idle resource behind for anyone to notice.
Three differences, and the third is the one that catches a conventional programme out.
- There is no idle to remove. Conventional waste is capacity nobody used. Agentic waste is work that did not need doing: a run that failed on its final step, a retry, a loop that never reached its stopping condition. Every token was genuinely consumed, so nothing looks wasteful.
- Consumption is decided at runtime, by the agent. You cannot right-size something that chooses how many times to call a model. The lever moves from provisioning to constraining, meaning step limits, spend ceilings and stopping conditions. See AI agent.
- Cost and carbon can diverge. In cloud they move together, which is what makes the dual mandate easy. Route a request to a smaller model and the bill falls, but if the smaller model needs three attempts where one larger call would have sufficed, the energy may not. The routing argument is at model routing.
The prerequisite nobody mentions. Carbon accounting for agents requires knowing which agent made which call, on whose behalf, and how many tokens it consumed. That is the same instrumentation described at LLM cost attribution, and without it a GreenOps programme can report that AI emitted something and not where or why. The gap between your provider's token total and your attributed total is, almost entirely, work that failed or repeated.
How do you start without hurting performance?
Start with work where speed does not matter. People worry that sustainability efforts will slow things down, mostly because they picture carbon-aware scheduling being applied to live user traffic. But that is not where most of the savings are. They are in work that can wait, so you can begin there without any performance cost.
Five steps, ordered so nothing user-facing is touched until the end.
-
Remove what nothing is using
Zombie resources have no performance characteristics because nothing depends on them. This is the entire first phase and it is usually the largest single reduction available.
-
Put non-production on a schedule
Development and test environments stopped outside working hours. The only performance affected is for people who are asleep, and a start-on-demand button removes the remaining objection.
-
Make tagging mandatory before anything else is measured
Owner, application, environment, region. Untagged resources are invisible to both cost and carbon reporting, and retrofitting attribution is far harder than requiring it.
-
Shift only flexible work by carbon intensity
Batch jobs, training runs, pipelines. Work with a deadline rather than a latency target, which is where carbon-aware scheduling applies and where it costs nothing a user can perceive.
-
Then look at the agentic estate
Step limits, spend ceilings and stopping conditions, plus the attribution to see which agents are consuming without producing. Retries and loops are the waste here, and removing them improves reliability as well as emissions.
One framing worth carrying into the conversation with finance. Nothing on this list is a sustainability trade-off, because every item removes work that produced no value. Carbon-aware placement is the only genuinely new decision, and it applies to a narrow slice of flexible workloads. The rest is efficiency that happens to be measured twice.