GreenOps

The GreenOps dashboard tracks the estimated carbon, energy, and water footprint of your cloud usage across Amazon Web Services, Google Cloud, and Microsoft Azure, built on the same reporting engine you already use for cost.

GreenOps is available in Preview. To enable it for your organization, contact your account manager.

What you see

• Carbon this month: estimated carbon emissions (kgCO2e) for the current month per cloud provider, compared with the prior month.

• Carbon intensity (kgCO2e/$): estimated carbon per dollar of cloud spend, trended over twelve months. Total emissions rise when your usage grows; intensity tells you whether you're getting cleaner or dirtier per unit of cloud you buy.

• Carbon footprint trend, Carbon by cloud, Carbon by service, Carbon by region, and a 30-day daily trend.

• Energy (kWh) and Water (litres) trends.

Carbon, energy, and water behave like any other metric in Cloud Analytics: open a widget as a full report, slice it by the dimensions you already use, or build your own reports — for example, carbon intensity grouped by region.

Methodology

GreenOps figures are estimates, computed from your billed usage with an open, published methodology. They are location-based and Scope-3-inclusive, and they are designed for tracking direction and finding hotspots, not for regulatory-grade accounting.

How a number is calculated

Every billing line item is matched to a rate for its SKU, region and pricing unit. The rate converts the line's usage quantity, the same quantity you are billed for, into energy, carbon, and water:

• energy = usage x energy per unit x PUE
• carbon = energy x grid intensity + manufacturing (embodied) share
• water = energy x WUE

A carbon figure in any widget is the sum of those per-line values for the rows the widget shows. That makes every number traceable: open the widget as a report and group by service, SKU, or region to see which lines contribute.

The energy per unit depends on what the line bills for:

What the line bills	Energy per unit	Source
Virtual CPUs (instances, containers, serverless compute)	Average watts per vCPU at 50% utilization: 2.12 W (AWS), 2.49 W (Google Cloud), 2.27 W (Azure)	Cloud Carbon Footprint (CCF) min/max coefficients
Memory	0.392 W per GiB	CCF
Storage	1.2 Wh per TB-hour on SSD, 0.65 Wh per TB-hour on HDD, multiplied by the copies the provider keeps	CCF coefficients and replication factors
Network transfer	1 Wh per GB	CCF
GPUs and accelerators	55% of the board power (an idle floor of 10% plus 50% utilization)	Published board power (TDP) per accelerator
AI model output tokens	Energy per generated token for the model's size	EcoLogits
Requests and API operations	About 20 ms of one vCPU per operation	DoiT assumption

Data center overhead uses each provider's published fleet-average power usage effectiveness (PUE): 1.135 for AWS, 1.10 for Google Cloud, and 1.185 for Azure. Water uses the published water usage effectiveness (WUE): 0.18, 1.10, and 0.49 litres per kWh respectively.

Compute and memory

An instance is priced at its published shape: its vCPU count and the memory it includes. AWS instance types use the vCPU and memory figures from the AWS price list, and Azure VM sizes use their published size tables, so a memory-optimized instance carries more energy per hour than a compute-optimized one with the same vCPUs. Memory billed on its own line (for example Compute Engine RAM, Cloud Run, or Fargate GB-hours) is counted once, on that line.

Burstable AWS instances (the t2, t3, t3a, and t4g families) are priced at their published baseline CPU utilization rather than at 50%. Fractional units such as GKE Autopilot milli-vCPU hours and App Engine instance classes are priced at the share of a vCPU they bill.

BigQuery is priced as compute. A slot-hour is one vCPU with 4 GiB of memory, scaled by a factor of 1.63 that calibrates BigQuery to Google's own Carbon Footprint report. On-demand queries billed per TiB scanned are converted to slot-hours at list-price parity ($6.25 per TiB against $0.06 per slot-hour), so on-demand and reserved BigQuery land at the same carbon per dollar.

Storage

Stored data is multiplied by the number of copies the service keeps: for example 3 for S3, EFS, and DynamoDB, 2 for EBS, 6 for Aurora and DocumentDB, 2 for regional and 4 for dual- or multi-region Cloud Storage, 3 for Azure LRS and ZRS, and 6 for GRS and GZRS. Object, archive, and standard block storage use the HDD coefficient; other storage uses the SSD coefficient.

AI models

Output tokens of hosted AI models (for example Gemini on Vertex AI, Claude and other models on Amazon Bedrock, and Azure OpenAI) are priced with the EcoLogits per-token model, using the model's published parameter count or an estimated one for closed models, and include the manufacturing share of the accelerators that serve them. Because these rates rest on model-size assumptions rather than a hardware quantity, a token line never draws more energy than its list price would buy as general-purpose compute ($0.04 per vCPU-hour).

Grid carbon intensity

Carbon intensity is location-based: the average emissions of the electricity grid where the region runs, with no deduction for the provider's renewable energy purchases. One country can span very different grids (from 11 gCO2e per kWh in Québec to 579 gCO2e per kWh in South Carolina), so regions are priced as precisely as published data allows:

• Google Cloud regions use Google's published grid intensity for the region's grid zone (2025 figures).
• AWS and Azure regions use the zone of the Google Cloud region in the same metro or balancing area. AWS GovCloud and Azure Government regions use the zone of their state.
• Google Cloud multi-regions (us, eu, asia) average their member zones. SKUs that carry no region resolve their location from the SKU description.
• EU countries with cloud regions but no published zone, such as Ireland, use the European Environment Agency's 2023 figures.
• Everywhere else, the country's yearly average from Ember open data (CC-BY). A region that cannot be placed is priced at the US average.

Manufacturing emissions (Scope 3)

Each unit also carries a share of the emissions from manufacturing the hardware, spread over its lifetime: 0.85 gCO2e per vCPU-hour for servers (CCF), plus Boavizta manufacturing factors for memory and storage over four years, and EcoLogits factors for GPUs and their servers over three years.

What carries no carbon

Lines that bill for something other than running hardware carry no energy or carbon of their own: taxes, credits, support plans, licence and software fees, Marketplace subscriptions, management and premium surcharges, commitment and reservation fees already covered by the usage they pay for, and lines billed at no charge under a free tier or an assumption. Fees on top of separately billed compute (for example the EMR or ECS fee on EC2 capacity) carry none either, because the instances they run on are priced on their own lines.

AWS calibration

AWS publishes location-based carbon estimates per account, region, and product group (EC2, S3, CloudFront, and everything else). Compared with those estimates, the coefficient model above reads high for EC2 and well below AWS for managed compute and database services, where AWS also attributes the shared and idle capacity behind the service. GreenOps therefore scales AWS energy and manufacturing emissions to match AWS's split:

AWS product group	Energy	Manufacturing
EC2	x 0.733	x 0.560
S3	x 1.430	x 1.709
Managed compute and databases: Lambda, RDS, ElastiCache, MemoryDB, MSK, OpenSearch, DocumentDB, Neptune, Redshift, DynamoDB, Timestream, ECS, EKS, Glue, EMR, Athena	x 5.797	x 6.172

Other AWS services (for example CloudTrail, EventBridge, SNS, Kinesis, and networking) keep the coefficient estimate. The factors were fitted on a DoiT-managed AWS payer account and are refitted when new AWS data is added.

How the model is validated

Each version of the rates is checked against the providers' own location-based reports before it ships:

• Google Cloud: GreenOps totals fall within about 12% of Google's location-based Carbon Footprint figures over twelve months, on two DoiT billing accounts (one never used for tuning).
• AWS: on the reference payer account, GreenOps matches AWS's location-based estimate per product group, and month by month within about 20%. Accounts whose service mix differs from the reference account can differ more, most often for managed services AWS does not break out.
• Azure: Microsoft does not publish a comparable location-based export, so Azure rates are checked for plausibility only.

Coverage is typically above 95% of billed cost. Line items whose usage unit cannot be classified are excluded rather than guessed.

Why your numbers differ from AWS or Google Cloud tools

Provider tools show market-based emissions by default: they subtract the provider's renewable energy purchases, which can bring a region close to zero. GreenOps reports the location-based figure, so compare it with the location-based view in the AWS Sustainability console or Google Cloud Carbon Footprint. Reporting frameworks such as the GHG Protocol treat the two as distinct figures, and many organizations report both.

Against location-based figures, expect totals in the same range, with differences per service: providers allocate shared and idle capacity and manufacturing emissions with their own internal data, which GreenOps approximates from published coefficients. Provider tools also lag one to three months; GreenOps updates daily, so a current-month comparison contrasts final data with partial data.

FAQ

Why did my carbon change when my usage did not?

The rates are versioned. When a new version ships, new billing data uses it right away, and earlier months keep the rates they were processed with until they are reprocessed. A change in rates moves carbon without any change in usage or cost; cost data is never modified.

Why does one service carry so much carbon for its cost?

Carbon follows hardware, not price. A service that bills large amounts of compute, memory, or GPU time at a low price (for example spot instances or committed-use capacity) reads high per dollar, and fees, licences, and Marketplace charges read zero. Group a report by SKU to see which lines drive a service.

Why does the same service differ between regions?

Grid intensity varies by more than 20 times between regions, so the same workload in Oregon or Montréal carries a fraction of the carbon it carries in Virginia, Mumbai, or Singapore. Carbon by region shows where moving workloads would matter most.

Why does BigQuery vary month to month?

BigQuery editions bill slot capacity, including autoscaled capacity, rather than the work your queries did, so carbon follows the capacity you were billed for.

Limitations

• Figures are estimates built from published coefficients, not metered power. They are not audit-grade and carry no third-party verification.
• Rates are location-based: your provider's renewable energy purchases (RECs, PPAs) are not netted out.
• Grid intensity uses yearly averages; hourly variation is not reflected.
• AWS calibration factors come from a reference account and apply at the product-group level, so a single service can differ from AWS's own figure.
• Only matched AWS, Google Cloud, and Azure usage is covered.