GreenOps Became an Engineering Metric, and the AWS Sustainability Console Confirms It

 

On March 31, 2026, AWS launched the AWS Sustainability Console: a standalone, free console with a public API and its own IAM model for tracking carbon emissions from your use of AWS services.

A few weeks before that launch, I was at the AWS User Group Goiânia giving a talk called "GreenOps: why your cloud decisions impact the planet even when you don't notice". When AWS launched the console shortly afterwards, it was not a timing coincidence. It was confirmation that the topic is no longer speculative. GreenOps is becoming an engineering practice, the same way FinOps did in recent years.

I want to detail what this console represents, what it delivers concretely and where the gaps still are. Because they exist, and being honest about them is part of the analysis.

Carbon footprint data on AWS lived in the Customer Carbon Footprint Tool (CCFT), inside the Billing console. That created an access restriction: to see emissions, you needed billing permissions on the account, which are usually limited to a specific team.

The result was that the data that could drive GreenOps actions was only visible to a narrow audience.

The AWS Sustainability Console solves exactly that by decoupling access through its own IAM permissions. Anyone with the right policy can see emissions data without involving the finance team. In practice, it removes that bottleneck.

When the console launched, AWS announced that the CCFT would be discontinued on June 30, 2026, so the migration window was short.

Four concrete changes compared to what existed before.

Access decoupled from billing. Already covered above. It is the most immediate change for people who already work on sustainability but had no visibility into the data.

Public API and SDK. In my view, the change with the biggest strategic impact. For the first time, you can integrate carbon emissions data into data pipelines, operational dashboards and compliance workflows programmatically. Emissions stop being a monthly report and become an engineering metric you can query through code, next to latency, cost and availability. That is what I mean when I talk about GreenOps as an engineering practice, not a marketing agenda.

Configurable CSV reports. You can build custom reports, choosing fields, time granularity and filters. You can also set the start of your fiscal year, which makes it easier to align with your organization's ESG audit cycles.

Scopes 1, 2 and 3 consolidated, with MBM and LBM. Data is calculated using both the market-based method (MBM) and the location-based method (LBM), broken down by AWS Region, service and emission scope. Scope 3, which covers indirect emissions such as server manufacturing and data center construction, was already available in the CCFT. Now it is consolidated, with better visualizations and accessible through the API.

In the talk at UG Goiânia, I dedicated a section to the relationship between FinOps and GreenOps, which I called sibling optimization disciplines.

FinOps is about cost optimization: it measures monthly spend, ROI and budget, with the goal of doing more with less money. GreenOps is about carbon optimization: it measures CO2 emissions and energy consumption, with the goal of doing more with less environmental impact. The principles are the same: continuous measurement, data-driven optimization and shared responsibility across the whole team.

The AWS Sustainability Console makes that connection operational. Organizations that already have FinOps pipelines, such as Cost Explorer integrations feeding internal dashboards, can now add the emissions layer to the same data flow. It does not need to be a separate process. It can, and should, be part of the same decision cycle where you already discuss cost and performance.

When you optimize for GreenOps, you often optimize for FinOps too. Right-sizing instances, using managed services, serverless architectures, development environments that are automatically turned off and on. All of these decisions reduce cost and emissions at the same time. The main thing the new console delivers is the measurement tool to prove it with data.

According to analyses published around the launch, there are real gaps AWS had not yet addressed with this release.

The calculation methodology is still proprietary and not externally auditable. AWS defines how it estimates Scope 1, 2 and 3 emissions, including emission factors and the share of renewable energy, but does not publish the data in a way that external auditors can verify independently. For organizations subject to stricter ESG regulations, such as the EU CSRD, this may be a real problem in upcoming audit cycles.

Granularity is still per service, not per resource. You cannot see the emissions associated with a specific Lambda function or a particular EC2 instance. For organizations with hundreds of workloads, more precise attribution still requires cross-referencing with other tools.

The console does not generate reports in standard compliance formats such as the GHG Protocol, CDP or TCFD. The API partially solves this, but it shifts the formatting responsibility to the engineering team. Not every team can absorb that right now.

Finally, data latency is not detailed by AWS. For teams that want GreenOps in short decision cycles, sprint by sprint, it is not yet clear how long it takes for an optimization made today to show up as an emissions reduction in the console.

If you work on solutions architecture on AWS, three actions make sense after this launch.

First: create a dedicated IAM policy for the AWS Sustainability Console and share access with whoever handles sustainability, ESG or environmental reporting in your organization. Grant only the console's read actions; at launch, these actions did not support resource-level permissions, so the resource is set to all resources.

Second: if you already have FinOps pipelines or cost dashboards, evaluate integrating the sustainability API into the same flow. It is the most efficient way to turn GreenOps into an operational practice rather than a one-off report.

Third: if your organization still relied on CCFT data or exports, make sure historical data and reporting processes have moved to the new console.

When I said in the UG Goiânia talk that GreenOps is not the future, it is the present, I was talking about mindset. The AWS Sustainability Console is a practical confirmation of that. AWS does not launch a standalone console, with a public API and its own IAM model, for a topic it considers secondary.

The tool has real limitations, which I detailed above. But making carbon emissions an engineering metric accessible through an API is, for me, the clearest sign that the industry is treating sustainability with the seriousness it deserves.

Every architecture decision we make has an environmental consequence. Now we have one more instrument to measure, monitor and optimize that consequence. It is up to us, solutions architects, to use it.