AWS Sustainability Console Launch: Programmatic Scope 1–3 Emissions Reporting Comes of Age

AWS just did something that makes sustainability teams, FinOps folks, and cloud platform engineers all nod at the same dashboard—possibly for the first time since someone tried to label an EC2 rightsizing project as “a climate initiative.” On March 31, 2026, Amazon Web Services introduced the AWS Sustainability console, a standalone place to view and export emissions data (Scope 1, 2, and 3), generate configurable CSV reports, set fiscal-year reporting periods, and—most importantly for anyone who has ever had to paste numbers into a spreadsheet at 11:58 PM—pull the data programmatically via API and AWS SDKs.

This launch was announced in the AWS News Blog post “Announcing the AWS Sustainability console: Programmatic access, configurable CSV reports, and Scope 1–3 reporting in one place” by Sébastien Stormacq. That post is the canonical starting point for the story, and you should read it if you want the official guided tour and screenshots. citeturn1view0

What I want to do here—wearing my “technology journalist who has seen too many dashboards” hat—is unpack what this console actually changes, why it arrives now, how it connects to AWS’ existing carbon reporting tooling, and what it means for organizations that increasingly have to answer the same question in five different formats: “So… what are our emissions, and can you show your work?”

What AWS actually launched (and what it replaces—or doesn’t)

The big clarification upfront: the AWS Sustainability console is not a brand-new emissions methodology. AWS says the underlying data and methodology are the same as what powers the Customer Carbon Footprint Tool (CCFT)—the reporting tool that previously lived inside the AWS Billing and Cost Management console. The change is primarily about access, workflow, and integration. citeturn1view0turn0search1

In practice, this is a “separation of concerns” release:

Billing people still do billing.
Sustainability and ESG reporting people can now access emissions reporting without inheriting billing permissions they don’t need (or shouldn’t have).
Engineers and data teams can automate emissions reporting with an API instead of relying only on manual exports.

Historically, that middle bullet was a real organizational pain. Many companies keep cost data tightly controlled, while emissions reporting needs broader access (think: corporate sustainability, procurement, risk, audit, compliance, and sometimes external assurance providers). AWS explicitly calls out that requiring billing-level permissions for carbon data access was a practical blocker, and the Sustainability console introduces its own permissions model independent of Billing. citeturn1view0

Scope 1, 2, and 3: why “all three in one place” matters

Emissions accounting is often described in three scopes:

Scope 1: direct emissions from sources owned or controlled by an organization.
Scope 2: indirect emissions from purchased energy.
Scope 3: other indirect emissions across the value chain (often the biggest bucket, and usually the messiest).

AWS’ console presents these scopes as emissions attributed to your AWS usage and provides breakdowns by AWS Region and by service (for example EC2, S3, CloudFront). citeturn1view0

Why this matters is less about definitions (your sustainability team can recite them in their sleep) and more about operationalizing Scope 3. In many organizations, cloud usage lands in Scope 3 “Purchased goods and services” or similar categories. As regulations and stakeholder expectations push for higher-quality Scope 3 accounting, companies need supplier-grade data that can stand up to internal audit and—sometimes—external assurance. Cloud providers are increasingly part of that supplier data layer.

AWS has been moving in this direction with CCFT updates. For example, AWS announced in late 2025 that the Customer Carbon Footprint Tool was updated to include Scope 3 emissions data (and additional Scope 1 sources such as natural gas and refrigerants). citeturn0search0

Market-based vs location-based accounting: the console bakes in both views

The Sustainability console includes reporting for both market-based method (MBM) and location-based method (LBM)—two ways to account for Scope 2 emissions. LBM reflects average emissions intensity of the local grid; MBM reflects contractual instruments like energy attribute certificates. AWS includes both in its preset monthly and annual reports. citeturn1view0

That might sound like accounting trivia, but it’s actually a recurring reporting headache: executives ask “what’s our emissions trend,” regulators ask “which method,” finance asks “what’s the reporting boundary,” and sustainability asks “can we reconcile this to our inventory.” Having both views available by default is one less argument in a meeting that didn’t need another argument.

The headline feature for engineers: programmatic access via API, SDKs, and CLI

The most developer-friendly part of the launch is that AWS now provides an API (and supports AWS SDKs and AWS CLI) to retrieve emissions data programmatically. The AWS News Blog post even includes an example CLI call using the new aws sustainability command group:

aws sustainability get-estimated-carbon-emissions --time-period '{"Start":"2025-03-01T00:00:00Z","End":"2026-03-01T23:59:59.999Z"}'

In that example output, AWS shows a ModelVersion value and both TOTAL_LBM_CARBON_EMISSIONS and TOTAL_MBM_CARBON_EMISSIONS results. citeturn1view0

This API angle is a big deal for three common scenarios AWS explicitly calls out:

Pulling a specific month across many accounts without setting up exports.
Integrating emissions into reporting pipelines (dashboards, compliance workflows, BI tools).
Custom account groupings that don’t map neatly onto AWS Organizations structures. citeturn1view0

It’s also a big deal because it signals a shift from “sustainability as a dashboard feature” to “sustainability as data infrastructure.” In other words, the emissions numbers are no longer trapped inside a UI designed primarily for humans; they can be treated like any other operational metric.

Permissions: the underappreciated feature

There’s an entire genre of enterprise cloud problems that are basically: “We could do the right thing, but the IAM permissions are weird.” The CCFT historically required specific billing-related access patterns, which created friction for sustainability teams. The Sustainability console’s separate permission model is designed to address that. citeturn1view0

For context, AWS documentation has long noted that access to carbon footprint data requires IAM permissions such as sustainability:GetCarbonFootprintSummary. citeturn0search3turn4search0

If you’re an AWS admin, this release effectively gives you a cleaner policy story: grant sustainability analysts access to sustainability actions, keep billing access constrained, and stop sending awkward emails that begin with, “Can you please temporarily add me to the billing group so I can download our carbon report?”

Reports and exports: the CSV era isn’t over (but it’s getting configurable)

For all the excitement around APIs, a lot of sustainability reporting still runs on CSVs because… auditors, consultants, and the reality of enterprise workflows. AWS leans into that reality by adding:

Preset monthly and annual reports
Configurable CSV exports where you choose fields, time granularity, and filters citeturn1view0

This is the kind of feature that seems small until you’ve tried to reconcile emissions by region across different internal cost centers, fiscal calendars, and business units. Configurable exports reduce the “post-processing tax”—the hidden labor cost of taking a generic export and making it match what your organization’s reporting templates actually need.

Fiscal year alignment: a quietly excellent quality-of-life improvement

AWS also added the ability to configure the console to match your organization’s fiscal year and quarters (if they don’t align with the calendar year). When set, views and exports reflect that reporting period. citeturn1view0

If you’ve ever watched finance and sustainability teams argue about whether “Q4” means “the end of the calendar year” or “the end of the fiscal year,” you already understand why this matters. It’s not glamorous, but it removes a recurring source of reporting friction.

How this fits with the Customer Carbon Footprint Tool (CCFT) and Data Exports

AWS is clear that the Sustainability console builds on CCFT rather than replacing it outright. CCFT began as a tool embedded in Billing and Cost Management (launched in 2022) to help customers understand estimated emissions and the reductions possible by moving from on-premises infrastructure to AWS. citeturn0search9turn0search1

Over time, AWS has expanded how customers can retrieve CCFT data in bulk, including through AWS Billing and Cost Management Data Exports that deliver carbon emissions data to Amazon S3 on a monthly basis in formats like CSV or Parquet. citeturn2search0turn2search1

Now, with the new console and API, AWS is offering three broad “lanes” for emissions data access:

Human-first lane: in-console exploration and hotspot identification (Sustainability console UI).
Spreadsheet lane: preset and custom CSV exports (Sustainability console Reports).
Data pipeline lane: programmatic API access, SDK integration, and continued S3-based exports through Data Exports.

The choice depends on how mature your organization is:

If you’re early in your sustainability reporting journey, the UI and preset reports will likely be enough.
If you’re building repeatable reporting cycles (monthly ESG reporting, internal dashboards, CSRD/ESRS-aligned processes), you’ll want API and export automation.
If you need historical methodology stability, AWS notes that setting up Data Exports can help retain historical data using previous methodologies after updates. citeturn2search2

Methodology and verification: why “same math, better access” is a strategic move

Emissions data is only as useful as the trust people place in it. AWS points customers to its methodology documentation and notes that it has been independently verified by Apex, a third-party consultant. citeturn1view0turn4search12

This matters for two reasons:

Internal governance: sustainability teams need to defend numbers to finance, risk, and audit.
External scrutiny: regulators, investors, and sometimes customers want traceability and assurance that the model is aligned with widely used standards.

AWS has previously described updates to its CCFT methodology (for example, a “v2.0” methodology update) and referenced standards such as the GHG Protocol and ISO LCA standards as part of the approach. citeturn0search1turn0search16

One important nuance: while AWS is making access easier, cloud carbon accounting is not magically “solved.” The industry still debates allocation approaches (how shared infrastructure emissions are assigned to customers), levels of granularity, and lag times. But the direction is clear: customers want higher quality data, with clearer auditability, and cloud providers are racing to meet that expectation.

Industry context: cloud carbon reporting is turning into a competitive checklist

AWS isn’t launching this in a vacuum. Other major cloud providers have been building emissions reporting tools and exports as well.

Google Cloud: Carbon Footprint with BigQuery export

Google Cloud provides a Carbon Footprint product that includes in-console dashboards and the ability to export carbon footprint data to BigQuery for analysis and custom reporting. Google also presents location-based and market-based Scope 2 data, along with Scope 1 and Scope 3 emissions associated with covered services. citeturn3search0turn3search1

From a data-engineering standpoint, BigQuery export is a strong “analytics-native” pattern: sustainability analysts can query emissions alongside usage and cost datasets and build dashboards without reinventing the pipeline each quarter.

Microsoft: Emissions Impact Dashboard and export workflows

Microsoft offers an Emissions Impact Dashboard for Azure (and other Microsoft services), emphasizing exportability and third-party validated methodology. Microsoft documentation and product pages describe exporting emissions data for retention and sharing, and positioning Azure-related emissions as part of customers’ Scope 3 accounting. citeturn3search4turn3search6turn3search7

The takeaway: “show me the emissions” is no longer a nice-to-have. It’s a baseline expectation for enterprise cloud procurement and compliance.

Regulatory pressure: the reporting tide is still rising, even if timelines shift

One reason tools like the AWS Sustainability console keep getting more capable is that reporting requirements keep getting more complex. Even when specific rules get delayed or litigated, companies are building processes because:

customers ask for emissions disclosures in RFPs,
investors ask for standardized reporting, and
different jurisdictions keep moving (sometimes in different directions).

In Europe, the Corporate Sustainability Reporting Directive (CSRD) and ESRS reporting standards have driven significant work across enterprises, although proposed “omnibus” changes have sought to reduce or revise requirements and thresholds. citeturn3search5turn3search11turn3search8

In the U.S., climate disclosure rules and state-level reporting requirements have seen legal challenges and shifting implementation dynamics. For example, an Associated Press report in November 2025 described an appeals court decision that paused a California law related to climate-risk disclosure, while a separate emissions disclosure law could remain in effect at that time. citeturn3news12

Here’s the pragmatic enterprise lesson: you can’t build your sustainability data stack on “we’ll wait until everything is final.” By the time it’s final, you’ll be asked for two years of historical numbers, in the format your auditors prefer, yesterday.

Why programmatic emissions data changes the FinOps conversation

There’s a growing overlap between FinOps (cloud financial operations) and sustainability. The FinOps Foundation has discussed how teams collaborate to optimize carbon and cost, and cloud carbon tooling is increasingly treated like another dimension of operational efficiency. citeturn0search2

With API access, you can realistically build “CarbonOps” workflows that mirror what many organizations already do for cost:

Scheduled pulls of monthly emissions data.
Tag- or account-based allocation to business units.
Dashboards that correlate emissions with spend, workload type, and region.
Alerting when emissions spike, similar to cost anomaly detection.

And crucially, you can make it repeatable and auditable. That’s the difference between “a slide once a year” and “a metric we operate with.”

A practical pattern: emissions data lake + BI

AWS already supports an S3-based approach via Billing Data Exports that can automatically deliver monthly carbon emissions data. citeturn2search0turn2search1

Now add the Sustainability console API to the mix, and you can choose between:

Batch ingestion (monthly exports to S3 in CSV/Parquet, queried via Athena, then visualized in QuickSight/Grafana/Power BI).
On-demand retrieval (API pulls for custom groupings, ad-hoc reporting, or integration into governance tooling).

If you’ve built a cost data platform—CUR, Athena views, BI layers—this is conceptually similar. The main difference is that your “stakeholders” now include sustainability reporting, procurement, and compliance teams, not just engineering leadership.

Granularity, lag, and the reality of “estimated” emissions

It’s worth being honest about what cloud emissions reporting can and can’t do today.

First, these numbers are estimates. They are computed using provider models that allocate emissions across shared infrastructure and incorporate supply chain and energy factors. AWS provides methodology documents and independent verification to increase confidence, but there will always be uncertainty and modeling assumptions—especially in Scope 3. citeturn0search1turn4search12

Second, there is commonly a data availability delay in provider reporting because emissions allocations depend on finalized operational data, energy sourcing, and accounting processes. Some third-party dashboards built around AWS exports even call out multi-month lags as a practical consideration when building reports. citeturn2search9

The important point for organizations is not to treat this like a real-time telemetry stream. Treat it like a monthly close process—similar to finance. It’s a reporting dataset designed for governance, trends, and decision support, not for second-by-second autoscaling.

What to do with it: concrete use cases beyond “reporting for reporting’s sake”

Once you can reliably access emissions data, you can do more than satisfy a questionnaire. Here are practical ways organizations tend to use cloud emissions reporting when they get serious.

1) Tie emissions to architectural decisions (region, service, and delivery patterns)

The Sustainability console breaks down emissions by Region and by AWS service. citeturn1view0

This supports real engineering questions:

Does moving certain workloads to a different region reduce emissions and meet latency/regulatory constraints?
Do CDN-heavy architectures show different patterns than compute-heavy ones?
How do storage class choices correlate with emissions trends?

Not every decision should be made purely on carbon metrics, but carbon can be part of the trade-off matrix—especially when costs and performance are already being optimized.

2) Build “carbon budgets” alongside cost budgets

Once data is accessible programmatically, teams can build allocation models similar to showback/chargeback. The goal is not to punish teams with a new KPI; it’s to help product owners understand the footprint of their services and see the impact of optimization work.

This is where configurable exports and fiscal-year alignment help, because organizations rarely operate on a clean “one AWS account = one product” model. citeturn1view0

3) Support supplier and customer requests faster

Many organizations now receive sustainability questionnaires from customers and must respond with credible Scope 3 data. Cloud emissions reporting—especially with Scope 3 included—can reduce the scramble to assemble data from multiple internal owners.

And if your organization is the supplier (selling a SaaS product), you may need to pass emissions information downstream to your own customers. In that case, the ability to generate repeatable exports and integrate via API becomes a revenue-enabling capability, not just a compliance checkbox.

4) Prepare for assurance and audit workflows

External assurance (limited or reasonable) is becoming more common in sustainability reporting. While the specifics depend on jurisdiction and reporting frameworks, the operational requirement is consistent: repeatable data retrieval, documented methodology, and traceable transformations.

A dedicated console with its own permissions model plus API-based retrieval gives organizations a better foundation for controlled, auditable reporting pipelines than “someone downloads a spreadsheet from Billing once a quarter.” citeturn1view0turn2search7

Comparisons and adjacent tooling: where this fits in the wider “sustainability stack”

Emissions reporting in the cloud tends to land in one of three buckets:

Provider-native tools (AWS Sustainability console, Google Carbon Footprint, Microsoft Emissions Impact Dashboard).
Open dashboards and proxy metrics (for example, dashboards that use proxy metrics like vCPU-hours, storage usage, and data transfer to find optimization opportunities). AWS even publishes guidance for a Sustainability Proxy Metrics and Carbon Emissions Dashboard. citeturn0search4
Third-party carbon accounting platforms that aggregate emissions across cloud, travel, procurement, and facilities.

The AWS Sustainability console clearly targets bucket #1 but is designed to integrate into #3 via API and exports. That’s the right move: enterprises don’t want ten different sustainability dashboards; they want one controlled source of truth (or at least a governed set of sources) that can feed their enterprise reporting environment.

What’s still missing (and what to watch next)

AWS says the Sustainability console is “designed to grow” and that it plans to continue releasing new features. citeturn1view0

Based on where the industry is heading, a few things are worth watching:

More granular allocation dimensions (tags, cost categories, projects) without complex post-processing.
Better linkage to optimization recommendations (not just reporting what happened, but suggesting how to reduce it).
Standardized sustainability data schemas across providers (similar to how FinOps has pushed for standard billing formats). Some industry commentary has pointed to future sustainability extensions of billing standards efforts. citeturn2search6
Coverage expansion: which services are included, how embodied carbon is treated, and how updates are versioned and preserved.

Also: if you’re building internal reporting pipelines, pay attention to AWS release notes. AWS explicitly points to release notes in the console for tracking feature releases and methodology updates. citeturn1view0turn0search18

Getting started: a sane adoption checklist

If your organization wants to take advantage of the AWS Sustainability console without turning it into a six-month governance saga, here’s a practical sequence that tends to work.

Step 1: Decide who owns the metric

Is it Sustainability/ESG? FinOps? Cloud Platform? The answer can be “shared,” but someone should own the reporting cadence and definitions.

Step 2: Set up IAM access deliberately

Use the service’s IAM actions to provide least-privilege access. Start with read-only needs for analysts, and separate export or integration permissions for data engineers. Use AWS’ Service Authorization Reference for AWS Sustainability to understand the action surface. citeturn2search7

Step 3: Pick your data lane (UI, CSV, API, or exports)

If you just need quarterly reporting: UI + preset reports.
If you need repeatability: API or Data Exports to S3.
If you want analytics: exports into your data platform and BI.

Step 4: Align the reporting calendar

Configure the fiscal year setting early so you don’t end up backfilling reconciliations later. citeturn1view0

Step 5: Document assumptions and transformations

Even if AWS provides the model, your internal transformations (grouping, allocation, rollups) will be part of what auditors and stakeholders care about.

The bottom line

The AWS Sustainability console is a meaningful maturation of AWS’ customer-facing carbon reporting story: same underlying methodology as CCFT, but with dramatically improved access control, export flexibility, and automation potential. The message is clear: emissions reporting is becoming operational data, not a once-a-year slide deck.

And if you’re wondering whether your organization should invest time in integrating these numbers into your own reporting pipelines, consider this: you might be able to ignore sustainability reporting requirements for a while (depending on where you operate and who your customers are), but your customers’ procurement teams probably won’t ignore them for you.

Sources

Bas Dorland, Technology Journalist & Founder of dorland.org