When infrastructure teams choose a cloud region, they evaluate latency, data residency, compliance, and cost. Carbon rarely enters the decision. This isn't because cloud workloads have no carbon footprint. It's because the data needed to make geography a carbon variable hasn't been available at the right level of detail.
That's the gap this article addresses.
Every cloud datacenter draws electricity from the grid it's physically connected to. That grid is supplied by a mix of generation assets — nuclear plants, hydropower stations, gas peakers, wind farms, solar installations — whose composition varies by geography and changes hour by hour.
The carbon intensity of that electricity, measured in gCO₂eq/kWh, is determined by what's being generated at that location at that moment. It is not a property of the cloud provider. It is not a national average. It is a function of where the datacenter sits on the grid and what the local generation mix looks like when your workload runs.
Two datacenters operated by the same provider, in the same country, can see materially different carbon intensities — because they connect to different nodes on a network where generation assets are distributed unevenly, and where transmission constraints mean that electricity doesn't flow freely from one region to another. The regional dispatch of generation, curtailment patterns, and local demand all shape what reaches each physical location.
Under the GHG Protocol's location-based method, Scope 2 emissions are calculated by multiplying electricity consumption by the carbon intensity at the point where that electricity was consumed. For a factory or an office building, the point of consumption is fixed. For a cloud workload, it's a choice — the region you deploy to.
That choice has carbon consequences that neither a national emission factor nor a provider-level Energy Attribute Certificate can capture. A national factor averages across the entire grid, erasing exactly the regional variation that matters. An EAC reflects a procurement decision about renewable energy certificates, not the physical carbon intensity of the electricity flowing into a specific datacenter at a specific hour.
If your infrastructure team deploys to a region with structurally lower carbon intensity — because of its proximity to low-carbon generation assets or favorable grid topology — your location-based Scope 2 emissions will be lower than if the same workload ran elsewhere. This is not a rounding error. Across significant compute volumes, it compounds.
Carbon intensity within a region isn't static. It shifts with the generation mix: solar output rises through the morning and collapses at dusk, wind production is intermittent, cross-border imports vary with neighboring grid conditions. The carbon intensity of a given cloud region at 11am on a sunny day in spring can be substantially different from its intensity at 7pm in winter.
For workloads with scheduling flexibility — model training runs, batch data pipelines, inference jobs that don't require real-time execution — this temporal variation is an actionable signal. Shifting a GPU-intensive training job to a window when regional carbon intensity is forecast to be lower produces the same emissions reduction as migrating it to a lower-intensity region. Both are expressions of the same underlying optimization: matching compute to low-carbon electricity.
This is where carbon intensity moves from a reporting input to a planning tool. A forecast of regional carbon intensity — hours or days ahead — lets infrastructure and GreenOps teams schedule workloads against the grid the same way they might schedule them against cost signals. The logic is identical; the variable is different.
Nodera built Cloud Carbon Intensity to make this level of precision accessible to the teams that make infrastructure decisions.
We mapped the physical location of cloud datacenters across providers and regions, then applied Nodera's local grid carbon intensity modeling at that level of granularity. The result is hourly carbon intensity data for each cloud region — not a national average pushed down to a provider label, but a signal derived from the actual grid node serving each datacenter.
The data is available as historical series and as forecasts, so teams can report on past emissions with location-based precision and plan future workloads against a carbon signal. For developers integrating carbon awareness into pipeline orchestration, for GreenOps teams building Scope 2 reporting on cloud infrastructure, and for infrastructure architects making region selection decisions, it provides what has been missing: the right number, at the right location, at the right time.
Cloud workloads have a location and a timestamp. Both determine their carbon intensity. Cloud Carbon Intensity by Nodera measures both — and forecasts what comes next.
