For most organizations, cloud cost optimization and cloud sustainability have been run by different people with different data. FinOps teams chase savings plans and idle resources; sustainability teams collect annual emissions figures for a report. In 2026 those two efforts are converging under a name that has been around for a few years but is now gaining practical traction: GreenOps.
This article explains what GreenOps means, why it matters now, how cloud carbon data actually works and where it falls short, and how to extend an existing FinOps practice to optimize cost and carbon together without building a second program from scratch.
What GreenOps Is, and Why It Is Converging With FinOps
GreenOps is the practice of reducing the carbon footprint of cloud and IT workloads through efficient design and operation. Forrester analysts described it in 2024 as closely tied to FinOps because both pursue efficient cloud use, and noted that the two share most of their tactics: rightsizing, storage tiering, removing idle resources and scheduling compute so it does not run when nobody needs it. They quoted AWS CTO Werner Vogels’ observation that cost is a close proxy for sustainability.
The FinOps community has moved in the same direction. Summaries of the FinOps Foundation’s State of FinOps 2026 report describe a practice whose scope has expanded well beyond public cloud bills, to SaaS, licensing, private cloud and data centers, and which increasingly collaborates with adjacent functions including ESG teams working on carbon accounting. The same summaries report that 98 percent of respondents now actively manage AI costs, which matters for sustainability because GPU-heavy AI workloads are among the most energy-intensive in the estate.
Three forces are making GreenOps practical rather than aspirational:
- Better data from providers. AWS, Microsoft and Google all publish customer-level emissions data, and AWS’s 2025 update to its Customer Carbon Footprint Tool added region-level granularity and data exports.
- Reporting pressure. Sustainability disclosure rules such as the EU’s CSRD, even after the EU’s simplification efforts narrowed which companies are in scope, plus ISSB-aligned standards in other jurisdictions and customer supply chain questionnaires, ask companies to explain the emissions of their operations, including purchased cloud services.
- AI energy demand. The rapid growth of AI training and inference has put data center power use in the headlines, and boards are asking technology leaders what their AI ambitions mean for emissions targets.
How Cloud Carbon Data Works
Before optimizing, teams need to understand what the numbers represent and where they are weak. Cloud provider carbon tools generally estimate emissions by allocating the energy and embodied emissions of data centers to customers based on their usage.
Scopes and Accounting Methods
From a customer’s perspective, cloud emissions sit in Scope 3, the emissions of purchased goods and services. Providers report their own Scope 1 (direct) and Scope 2 (purchased electricity) emissions allocated to customers, and some also include Scope 3 elements such as hardware manufacturing. Coverage differs. Forrester noted in 2024 that Google Cloud and Microsoft Azure reported Scope 3 while AWS reported only Scopes 1 and 2. The New Stack’s coverage of AWS’s May 2025 update said AWS still reported Scopes 1 and 2, using market-based figures for Scope 2, and had committed to adding Scope 3. Because these tools evolve, always check the current methodology documentation before comparing providers.
Market-Based Versus Location-Based
Market-based figures reflect renewable energy purchases by the provider; location-based figures reflect the actual carbon intensity of the local grid. A workload can show near-zero market-based emissions while running on a carbon-intensive grid. For decision-making about where to place workloads, location-based intensity is often more informative; for corporate reporting, follow the method your sustainability team uses.
Granularity and Latency
Provider tools typically report monthly, with a lag, and at account, region and service level rather than per resource. AWS’s 2025 update brought region-level reporting, exports in CSV or Parquet and gram-level resolution, but The New Stack noted that per-service breakdowns beyond EC2 and S3 were still limited. For engineering decisions, many teams supplement provider data with estimation models, such as the open-source Cloud Carbon Footprint approach or the Green Software Foundation’s Software Carbon Intensity specification, which estimate emissions from usage data and published energy coefficients.
Where Cost and Carbon Align, and Where They Conflict
The good news is that most FinOps optimizations reduce carbon too. Turning off idle resources, rightsizing over-provisioned instances, moving cold data to cheaper storage tiers and deleting unused snapshots all cut energy use and embodied emissions along with spend. If you are doing FinOps well, you are already doing a large share of GreenOps.
But the alignment is not perfect, and a mature practice should know where the two diverge:
- Commitment discounts. Savings plans and reservations cut cost per unit without reducing consumption at all. They are good FinOps but neutral for carbon.
- Region choice. The cheapest region is not always the cleanest grid. A region with higher prices but lower carbon intensity may be preferable for flexible workloads.
- Spot and preemptible capacity. Using spare capacity improves overall data center utilization, which is generally positive for both, but retries from interruptions can add compute.
- Hardware generations and architectures. Newer, more efficient processors, including Arm-based instances, often lower both cost and energy per unit of work, but migration effort is real.
- Data transfer. Cross-region replication adds both cost and network energy; Forrester specifically flagged unnecessary cross-region transfer as having a notable carbon impact.
Most FinOps savings are also carbon savings, but not all of them. GreenOps adds the decisions where carbon changes the answer: where workloads run, when flexible jobs execute, and which hardware they use.
A Practical Playbook for Folding Carbon Into FinOps
1. Establish a Shared Data Foundation
Pull provider carbon exports into the same data platform that holds your cost and usage data, ideally normalized with the FinOps Open Cost and Usage Specification (FOCUS) for cost. Map both to the same tags, accounts and business units so you can attribute emissions to products and teams the same way you attribute spend.
2. Agree on Methodology With the Sustainability Team
Decide which figures you will use for reporting and which for engineering decisions. A common pattern is provider market-based data for annual disclosure, combined with location-based estimates for workload placement and design choices. Document assumptions so numbers can be explained to auditors.
3. Add Carbon to Existing FinOps Reviews
Rather than creating a separate meeting, add a carbon column to the dashboards and monthly reviews product teams already attend. Show cost and emissions side by side, along with unit metrics such as cost and grams of CO2e per transaction, per customer or per model inference.
4. Prioritize Actions That Win on Both
Start with the overlap: idle and orphaned resources, over-provisioned compute, storage lifecycle policies, development environments that run around the clock, and oversized GPU instances for inference. These produce quick, defensible results.
5. Introduce Carbon-Aware Decisions for Flexible Workloads
Identify workloads that can move in time or space: batch analytics, model training, test suites, media processing and backups. For these, consider scheduling into lower-intensity hours or running in lower-intensity regions where data residency rules allow. Tools based on the Green Software Foundation’s Carbon Aware SDK and Kubernetes schedulers that consider grid intensity can automate this.
6. Make Efficiency a Design Criterion
Add energy and carbon considerations to architecture reviews alongside cost, security and reliability. All three major providers include a sustainability pillar or guidance in their well-architected frameworks, which gives teams a common checklist.
GreenOps for AI Workloads
AI deserves special attention because GPU instances draw far more power than general-purpose compute and are often provisioned generously. The levers mirror FinOps for AI:
- Choose the smallest model that meets quality requirements, and route simple requests to smaller models.
- Use batching, caching of repeated prompts and quantization to raise throughput per GPU.
- Schedule training and large batch inference jobs for lower-intensity periods and regions when possible.
- Track GPU utilization; low utilization is waste in both currencies.
- Report energy and emissions per thousand inferences alongside cost per thousand inferences.
Roles, Metrics and a Simple Maturity Checklist
GreenOps works best when responsibilities are explicit. The FinOps lead typically owns the shared data model and the review cadence. The sustainability or ESG team owns methodology, reporting boundaries and alignment with corporate targets. Platform engineering owns the automation, such as schedules, lifecycle policies and carbon-aware placement, that turns decisions into defaults. Product and engineering leads own the trade-offs for their services, deciding for example whether a latency-sensitive workload can tolerate a different region.
A handful of metrics is enough to start. Track total estimated cloud emissions by business unit, emissions per unit of business output alongside cost per unit, the share of compute running on current-generation efficient instance families, average utilization of GPU fleets, and the share of flexible batch workloads that are scheduled with carbon awareness. Trend lines matter more than absolute precision, because provider methodologies will keep changing.
Use this checklist to gauge where you stand:
- Carbon data from every cloud provider is exported automatically and lands next to cost data.
- Emissions are allocated to products and teams using the same tagging rules as cost.
- Methodology choices are documented and agreed with the sustainability team.
- Product dashboards show cost and carbon side by side, with at least one unit metric.
- Architecture reviews include an efficiency and sustainability question.
- Flexible workloads have been identified, and at least some run on carbon-aware schedules.
- AI workloads report utilization and emissions per inference, not just spend.
Organizations that can tick four or more of these boxes have moved beyond reporting and are actively managing carbon as an operational metric. Fewer than two usually means the data foundation is the first job, and that the quickest win is simply adding carbon exports to the existing FinOps pipeline.
Hypothetical Worked Example: A SaaS Analytics Platform
Consider a hypothetical SaaS analytics company running on two cloud regions. Its FinOps team has already purchased commitments covering most steady-state compute. The sustainability team now needs credible cloud emissions figures for customers’ supplier questionnaires.
The teams load provider carbon exports alongside FOCUS-formatted cost data and discover that nightly batch aggregation jobs account for a large share of compute hours. Those jobs run in a region whose grid is more carbon-intensive than the company’s second region, and they run at a fixed time regardless of grid conditions. The joint plan moves batch jobs to the cleaner region, where residency requirements permit, adopts newer efficient instance types during the next commitment renewal, sets lifecycle rules for intermediate files, and introduces an emissions-per-customer metric that the company can share in questionnaires. Cost falls modestly through rightsizing and storage cleanup, and estimated emissions fall more noticeably because of the region and hardware changes. The key outcome is a single dashboard and a single review cadence rather than two competing programs.
Pitfalls to Avoid
- Comparing providers on incompatible numbers. Different scopes and methods make raw comparisons misleading.
- Treating market-based zeros as the end of the story. Efficiency still matters even when the provider buys renewable energy.
- Moving workloads without checking residency and latency. Carbon-aware placement must respect data sovereignty and user experience.
- Building a separate GreenOps team. Duplicating FinOps tooling and meetings wastes effort; extend what exists.
- Waiting for perfect data. Provider data is imperfect and lagged, but directionally useful today.
Outlook: 2027 and Beyond
Expect carbon data to become more granular and more timely, with providers expanding service-level breakdowns and Scope 3 coverage. Expect FinOps tools to treat carbon as a standard dimension next to cost, and procurement teams to ask for emissions per unit of service in cloud and AI contracts. As AI workloads grow, energy efficiency per inference will become a competitive metric in its own right. Organizations that unify cost and carbon data now will be positioned to answer customer, investor and regulator questions with the same confidence they bring to budget reviews.
Conclusion
GreenOps is not a separate discipline competing with FinOps; it is FinOps with a second currency. Start by putting carbon and cost data side by side, agree on methodology with your sustainability team, prioritize actions that win on both, and then add carbon-aware placement and scheduling for flexible workloads. The result is a cloud estate that is cheaper to run and easier to defend in a sustainability report.
How Hanoi Technology Can Help
Hanoi Technology helps teams combine cost and carbon data, build unit-economics dashboards and implement optimizations that reduce both spend and emissions.