Carbon-Aware Scheduling: Cloud Emissions Reporting Under CSRD

For most of the past decade, the sustainability conversation in cloud infrastructure was dominated by procurement: which provider had signed the most renewable power purchase agreements, which region ran on the cleanest grid, which datacenter advertised the lowest power usage effectiveness. That framing put almost all of the agency in the hands of hyperscalers and almost none in the hands of the teams actually running workloads. Carbon-aware scheduling changes that, and the regulatory environment of 2025 has given it a reason to move from research curiosity to operational practice.

The shift is being driven from two directions at once. On the technical side, the schedulers and energy-data feeds needed to make workload placement decisions on the basis of grid carbon intensity have matured to the point where they can run in production. On the regulatory side, the European Union’s Corporate Sustainability Reporting Directive (CSRD) has begun pulling cloud emissions out of the voluntary-disclosure shadows and into audited financial-grade reporting — specifically through its treatment of Scope 3 emissions.

What CSRD Actually Requires

CSRD entered into application in phases beginning with the 2024 financial year, with the first large in-scope companies reporting in early 2025. It substantially expands the population of companies required to report environmental data compared with the older Non-Financial Reporting Directive, and — critically for infrastructure teams — it requires reporting under the European Sustainability Reporting Standards (ESRS), which mandate disclosure of material Scope 3 emissions.

Scope 3 covers indirect emissions in a company’s value chain that are not from owned or directly controlled sources. For a company that runs its software on public cloud, the emissions associated with that compute fall squarely into Scope 3. This is the mechanism that makes cloud emissions a reportable, auditable line item rather than a sustainability-report footnote. A company cannot credibly report its Scope 3 footprint without some defensible accounting of the carbon associated with the cloud capacity it consumes.

That requirement runs into an awkward reality: cloud emissions data is hard to get, inconsistent between providers, and frequently based on market-based accounting (renewable energy certificates and PPAs) rather than location-based accounting (the actual carbon intensity of the grid serving the datacenter at the time the work ran). The two methods can produce dramatically different numbers for the same workload, and auditors are increasingly asking which method underlies a reported figure.

It is worth noting that CSRD’s scope and timeline are not entirely settled. The European Commission’s February 2025 “omnibus” simplification proposals signalled an intent to reduce the reporting burden on smaller in-scope companies and to revisit some of the directive’s thresholds and timelines. As of this writing the proposals are pending rather than enacted, and infrastructure teams planning emissions-reporting work should treat the exact population and deadlines as subject to change while the underlying direction — auditable Scope 3 disclosure including cloud — remains intact.

Provider Carbon Data: The Inputs

Carbon-aware decision-making depends on data, and the data landscape is uneven.

Google Cloud publishes a Carbon Free Energy percentage per region — the proportion of the region’s consumption matched with carbon-free generation on an hourly basis — alongside gross carbon footprint figures in its Carbon Footprint tool. The hourly CFE metric is the most granular carbon signal any hyperscaler currently exposes at the region level.
Microsoft Azure provides an Emissions Impact Dashboard giving Scope 1, 2, and 3 estimates for a customer’s Azure usage.
AWS offers a Customer Carbon Footprint Tool, though it has historically reported on a market-based basis and with a lag, which complicates location-based reconciliation.

For real-time scheduling decisions, third-party grid-intensity feeds matter more than provider dashboards. Services such as Electricity Maps and WattTime expose current and forecast carbon intensity (grams CO2 per kilowatt-hour) by grid region. These feeds are what allow a scheduler to know that, right now, the grid in one region is twice as carbon-intensive as the grid in another.

Carbon-Aware Scheduling in Practice

Carbon-aware scheduling exploits a simple fact: not all compute has to run immediately, and not all compute has to run in the same place. Two levers follow from that.

Temporal shifting delays flexible workloads — batch jobs, model training, large data pipelines, nightly reports — until grid carbon intensity is lower. A training run that does not need to finish until morning can wait for the overnight period when wind generation is high and intensity is low.

Spatial shifting routes flexible workloads to regions with cleaner grids at the moment of execution, where data residency and latency permit. A globally distributed batch system can prefer a hydro-heavy region over a coal-heavy one.

In the Kubernetes ecosystem, the practical tooling has consolidated around a few projects. KEDA, the Kubernetes Event-Driven Autoscaling project, has a carbon-aware scaler that can throttle or scale workloads according to a carbon-intensity signal — pausing or slowing deferrable work when intensity is high. The broader effort lives under the Cloud Native Computing Foundation’s Environmental Sustainability Technical Advisory Group, and the Green Software Foundation has published a Software Carbon Intensity specification that gives teams a consistent metric to optimize against. These align with the kind of cloud auto-scaling and workload orchestration practices teams already run, layering a carbon signal onto decisions they are making anyway.

The honest caveat: carbon-aware scheduling only helps for genuinely flexible workloads. Latency-sensitive, always-on services cannot be temporally shifted, and regulated data often cannot be spatially shifted across jurisdictions. The addressable surface is batch and asynchronous work — which, for data and AI-heavy organizations, is a substantial and growing share of total compute.

Connecting Scheduling Decisions to Reporting

Here is where the technical and regulatory threads meet. A carbon-aware scheduler does not just reduce emissions; it produces a record of the carbon intensity under which work actually ran. That record is exactly the location-based, time-resolved evidence that auditable Scope 3 reporting increasingly wants.

A team that schedules on grid-intensity signals and logs the intensity at execution time can produce a location-based emissions estimate grounded in operational data rather than annualized provider averages. This is a meaningfully stronger position than reporting a market-based figure derived from a provider dashboard, and it is more defensible under audit scrutiny.

The architectural implication is that emissions measurement should be treated as telemetry. The same observability pipeline that captures CPU, memory, and request metrics can capture energy-proxy metrics (CPU and GPU utilization correlated with hardware power draw) and the grid intensity at the time and place of execution. OpenTelemetry-based instrumentation makes this telemetry portable across environments, which matters for organizations running hybrid or multi-cloud estates where no single provider dashboard sees the whole picture.

What Infrastructure Teams Should Track

For teams getting ahead of CSRD-driven cloud emissions reporting:

Determine your accounting method. Decide whether you are reporting location-based or market-based emissions, and be consistent. Auditors will ask, and the two methods are not interchangeable.
Instrument energy and intensity as telemetry. Capture utilization-derived energy proxies and grid carbon intensity at execution time, through your existing observability pipeline rather than as a separate annual data-gathering exercise.
Identify your flexible workload surface. Catalogue which workloads are temporally or spatially shiftable. This is both the carbon-reduction opportunity and the part of the estate where scheduling investment pays off.
Treat provider carbon data as one input, not ground truth. Provider dashboards lag, differ in methodology, and rarely expose hourly granularity. Pair them with independent grid-intensity feeds for operational decisions.
Watch the omnibus process. The exact CSRD population and deadlines may shift. Build reporting capability that is robust to threshold changes rather than tuned to one specific year’s rules.

Conclusion

Carbon-aware scheduling has reached the point where the tooling is production-viable and the regulatory pull is real. CSRD’s Scope 3 requirements give infrastructure teams a concrete reason to instrument cloud emissions at the granularity that makes carbon-aware decisions possible — and the same instrumentation that drives lower-carbon scheduling produces the audit-grade evidence those reporting obligations demand. The two used to be separate projects. Under CSRD they have become the same project, and the teams that recognize that early will spend less effort reconciling them later.