AWS Revives and Updates Its Customer Carbon Footprint Tool

Cloud colossus Amazon Web Services has released an update to its much-criticized Customer Carbon Footprint Tool (CCFT), which has received little attention since its original release in 2022.

Adrian Cockcroft, who was head of sustainability at AWS at the time, freely acknowledged to The New Stack in an interview that that first release was “pretty woeful.”

“It was built by a team in the energy organization who provided power to the data centers,” said Cockcroft, an occasional TNS contributor. “They wanted to surface the data but didn’t own a customer-facing service, and they didn’t go through the normal product release process because they weren’t part of that system.”

The energy organization team talked to the billing team, which made the energy team a webpage to use in the portal. But the product got watered down, as there was some nervousness around making the data public. There was no export. It was also very low resolution, with “everything rounded to the nearest 100kg,” Cockcroft told us. The ability to download data in CSV format was added, but “the team and product manager who built it were all long gone.”

Fast forward to 2024 and a new manager, Alexis Bateman, has been working with her team to address the shortcomings.

“This is AWS digging themselves out of a hole,” Cockcroft told us.

Bateman and the various sustainability teams at AWS have already made some progress; last December, AWS provided Power Usage Efficiency (PUE) data for 2022 and 2023, allowing Cockcroft to write a post for The New Stack comparing AWS, Azure and GCP global regions for the first time, and in May to get an update to the CCFT.

The main change in this new release is support for regional data, allowing you to see your carbon footprint in, say, Dublin or US-East 1 on AWS for the first time; previously you could only see data at a geographic level. We also get an improved export feature, allowing data to be exported in either CSV or Parquet formats, with an increase in resolution in the exported data down to a gram.

Unfortunately, that’s it for now. Major features still missing include any per-service data, Scope 3 emissions coverage and any location-based (as opposed to market-based) reporting.

The v.2 Methodology

We should note, however, that AWS has introduced a new, independently audited reporting methodology, which the vendor claims “addresses the challenge of tracking and apportioning carbon emissions for customers, using a wide array of AWS services across multiple regions.”

Clearly, AWS feels it can stand behind this revised approach. Digging into the details, the difference between the v.2 methodology and when the tool first shipped is that estimated carbon emissions associated with the unused AWS capacity are now proportionally allocated to all customers using AWS services.

“It’s an interesting change and it isn’t something the other cloud providers are doing,” Cockcroft told The New Stack. “If customers only use 70% of a cloud region to support them, the other 30% is allocated across those customers on some proportional basis as overhead.”

Since the change was introduced in January, this approach will have increased the reported carbon emissions of a workload by a noticeable amount. But it is more comparable to how a company would treat a private data center; if an organization is only using 50% of its data center, you still count the idle capacity for carbon accounting purposes.

The new methodology makes a better fist of allocating estimated emissions from AWS services between AWS customers and Amazon’s own teams, without dedicated hardware such as Lambda or Redshift.

Finally, there are some changes to try and better allocate overhead associated with running the data centers, including estimated carbon associated with networking racks and launching new regions.

Other aspects are unchanged. The unit of measurement for carbon emissions is “metric tons of carbon dioxide equivalent” (MTCO2e), an industry-standard measure. This measurement considers multiple greenhouse gases, including carbon dioxide, methane and nitrous oxide, which are converted to the amount of carbon dioxide that would result in equivalent warming.

Reporting uses the Greenhouse Gas Protocol scopes:

• Scope 1 covers direct emissions from sources owned or controlled by AWS, such as fuel combustion in backup generators and their data centers
• Scope 2 includes indirect emissions from purchased electricity

Scope 3, which covers the rest of the supply chain, is not reported, although as part of this new release AWS has made a public commitment to report it in the future.

“We’re conducting robust life cycle assessments for our business, to provide customers with high-quality Scope 3 carbon emissions data,” David Ward, from the AWS worldwide sustainability communications team, told The New Stack.

The new methodology document provides more detail on how AWS arrives at the figures it currently provides.

Scope 1 data for the year is received in the first quarter of the following calendar year. AWS then calculates estimated carbon data with site-level granularity and aggregates it to cluster level. An AWS cluster can be an AWS Region (e.g. us-east-1, eu-central-1), or an AWS CloudFront edge cluster (e.g. CF in North America, CF in South America).

Scope 2 data is delivered once a month but has a three-month lag; in other words, any “new”  data can be up to four months out of date. Actual metrics remain market-based only. Market-based reporting reflects emissions from the specific electricity your company purchases, taking into account RECs (renewable energy certificates), REGOs (renewable energy guarantees of origin) or other energy contracts AWS has made. This is a carbon accounting model supported by the Greenhouse Gas Protocol and explored in more detail in our eBook.

To calculate their Scope 2 emissions, the Greenhouse Gas Protocol currently lets companies subtract their annual clean energy generation (PPAs) and purchases (RECs) from their annual electricity use, then multiply the remaining unmatched load by an average emissions rate for the power grid in question.

As noted earlier, CCFT doesn’t include any location-based reporting that calculates emissions based on the average emission intensity of the power grid your workloads are physically connected to. In other words, the report doesn’t show emissions tied to your physical electricity consumption.

AWS’s model first allocates emissions to server racks at the AWS cluster level, then maps those emissions to specific AWS services based on their resource consumption. However, we only get splits for Amazon Elastic Compute Cloud (EC2), and Amazon Simple Storage Service (S3), with everything else lumped under “other.”

Even for the services that do get broken out, that data isn’t really usable; you can’t compare Graviton to Intel for example, or get a breakdown for GPUs. And of course, you have no way of knowing what is included under “other.”

This lack of per-service data is a major issue for customers.“For one of my clients, most of their carbon footprint is categorized in ‘other,’” Cockcroft told TNS. “I’ve not been able to figure out why it randomly changes up and down and doesn’t appear correlated with anything we’re using.”

Both Google and Azure offer more detailed emissions information. Google’s Cloud Carbon Footprint provides both location-based and market-based approaches. It covers Scopes 1, 2 and 3 broken down by region and service, with the ability to add user-defined projects.

As it stands, the CCFT is useful for helping your CFO buy carbon credits, but “it is pretty much useless for optimizing a workload,” according to Cockcroft. “If I’m trying to do workload placement optimization, or measuring something to cut its carbon, the Google data is much more useful.”

Kepler and the Real-Time Cloud Project

None of the cloud tooling is perfect. The ideal situation would be to get real-time carbon metrics for optimization. Ideally, this would be another metric, like CPU utilization, that we could report using the tools we already have.

Kepler (Kubernetes-based Efficient Power Level Exporter), a Cloud Native Computing Foundation sandbox project, gets us closer. It uses eBPF (Extended Berkeley Packet Filter) to probe energy-related system stats and exports them as Prometheus metrics, which can then be imported via the pre-generated Kepler dashboard into Grafana:

Kepler allocates the energy usage of a host node to the active pods and containers running in that node, so that energy and carbon data can be reported for workloads running on Kubernetes. In data center deployments, Kepler can directly measure energy usage and obtain carbon intensity data from the data center operator.

As I discussed recently at Devoxx, Kepler is also a fantastic tool for people running workloads in their own data centers, assuming those workloads are run using Kubernetes.

Cockcroft has been leading the Real Time Energy and Carbon Standard for Cloud Providers. Originally proposed at QCon London in 2023, this aims to give us a standard format for the relevant metadata.

The cloud providers disclose metadata about regions annually, around six months after the calendar year ends. This data may include power and water usage effectiveness (PUE and WUE), carbon-free energy proportion, and the location and grid region for each cloud region.

In the initial V1.0 release, annual metadata from AWS, Microsoft Azure and Google Cloud Platform (GCP) has been normalized into a single CSV data source, with work ongoing to add data for Oracle Cloud.

The data Cockcroft has, which is currently available for 2023 and earlier, has been projected into an estimate for 2024 and 2025 using some Python code, which is available to review in the project’s GitHub repo.

Pulling all of this together involves painstaking data wrangling, but Cockcroft’s work gives us all the ability to download information from GitHub, pop it into a spreadsheet, then filter it for the relevant provider and region, such as AWS US-East 1:

We get the PUE for that region, carbon-free energy and comparable data for different standards. Along with the annual data, you can access daily or hourly data for a particular point in time using a tool like Electricity Maps or WattTime. And from this, we can get a regional real-time carbon number.

Cockcroft is hopeful that the cloud providers will start to provide all the data in a standard format. The FinOps Foundation is pushing its FOCUS standard to try to standardize billing records across cloud providers.

“A proposed future extension of FOCUS is sustainability information, which is largely what I have in my real-time cloud metadata, but with more granularity than AWS provides,” Cockcroft told us.

He is just starting to collaborate with the FinOps Foundation’s sustainability group to combine his work with what they are doing. “This should provide a better place to get the cloud providers onboard with standard information in a standard way,” he told TNS. “We’re hoping that this will give us data that can be used to optimize workloads and make choices about where to place things.”

As for AWS’s CCFT: as an update three years in the making, it feels rather dispiriting, but we should give the new team time and assume that they will continue to add new capabilities. The public commitment to adding Scope 3 makes me cautiously optimistic that we’ll see more progress during the year.