So far, the standard way to put a cloud carbon number into a CSRD filing has been some broad multiplication: most often cloud costs times a national grid carbon intensity factor averaged across the year. Sadly, this CSRD reporting value can not be audited and even less acted upon.
This week we are launching Ambra, Nodera's cloud carbon platform. Spectrum, the first product in the suite, connects to your cloud provider's monitoring APIs, applies hardware-level energy coefficients to the actual utilization signal, and multiplies that energy by Nodera's local, time-resolved grid intensity. The output is a carbon figure per cloud resource (VM, serverless, storage, AI service, network), up to minute-level resolution, computed from usage data rather than from your invoice.
The disclosure most companies file today is built on three approximations stacked on top of each other.
The first is purely spend-based: euros of cloud spend multiplied by a sector-average emission factor. The GHG Protocol Scope 3 Category 1 spend-based method, applied via EEIO models like EPA USEEIO or EXIOBASE, carries a single coefficient for NAICS 518210 — "Data Processing, Hosting, and Related Services". Object storage, GPU compute, and network egress all map to the same gCO₂eq per euro of spend, even though their physical signatures are nothing alike. Two companies with identical cloud invoices and very different fleets get the same carbon number. The logic also creates a strange operating constraint: if your cloud footprint is proportional to your spend, the only way to reduce it is to reduce the invoice. That is workable for a company in steady state. It is incompatible with the kind of growth most software businesses are pursuing right now, especially the ones leaning into AI workloads.
The second is utilization-based, but with a fixed assumption. The open-source standard most teams start with assumes 50% CPU. Cloud provider dashboards make similar assumptions, work off monthly billing cycles, and surface results monthly. Most commercial carbon platforms follow the same path. The assumption is reasonable as a default. It is also wrong for almost every individual resource.
The third is the grid factor, and it has two dimensions, time and geography, both usually flattened. National annual averages get applied uniformly to every hour of every day and to every region inside the country. Modern grids carry meaningful intra-day swings: as solar and wind take a larger share of generation, the same grid sits at one intensity at midday on a sunny weekend and at a very different one at 7pm on a still weekday. France's range, for instance, runs from around 5 gCO₂eq/kWh in low-carbon hours to 93 in higher-carbon ones. None of that enters a national-annual figure. Neither does the fact that the physical datacenter underneath a given cloud region label sits in a specific location, on a specific sub-national grid, with a mix that can be meaningfully different from the country average. Nodera's Local Carbon Intensity engine is built to capture both axes, time-resolved and physically located, and it is the input the rest of the methodology depends on.
Stacked, the three approximations produce a number that satisfies the filing requirement and tells you nothing about your fleet.
For a company that buys cloud services, the carbon associated with those services sits in Scope 3, Category 1 (Purchased Goods and Services). The cloud provider purchases the electricity that runs your cloud resources, so the kWh shows up in their Scope 2; the service you buy from them shows up in your Scope 3. AWS's own Customer Carbon Footprint Tool reports to customers on this basis.
ESRS E1, the climate standard under CSRD, requires gross Scope 3 emissions disclosed by category for every material category, alongside the methodology and the underlying data the figures were derived from. For software-heavy companies, cloud almost always qualifies as material under Category 1. Companies in scope are expected to declare enough about how the number was produced that an external audit team can trace it back to source.
The standard does not, today, require hourly granularity. But the underlying calculation is the same physics Scope 2 deals with: how much electricity your cloud resources caused to be consumed, where, and on what grid at what hour. The GHG Protocol Scope 2 Guidance, which the calculation sits on top of, frames it that way. Higher time and spatial resolution of the grid factor produces a more accurate number, and a more evidenced one. The direction of travel in the GHG Protocol Scope 2 revision currently in progress, and in the Scope 3 Standard, is towards more granular data, not less.
This is the gap Ambra Spectrum is built to close. Spectrum connects to the cloud provider's monitoring API (CloudWatch on AWS, Cloud Monitoring on GCP) and reads the actual utilization signal at the granularity those APIs expose, which today is up to the minute-level. For compute, it applies SPECpower-derived coefficients per instance type to convert utilization into energy consumed; AI services, network, storage and serverless use their own per-resource energy models, multiplied by Cloud Carbon Intensity at that time. And it writes out one carbon row per resource_metrics row, with no aggregation before computation, so every number traces back to a primary observation.
The result is a carbon figure that is minute-level, per cloud resource, and reproducible from raw data. It mirrors the GHG Protocol Scope 2 location-based method at the resource level, and is designed to support ESRS E1 disclosure of Scope 3, Category 1 emissions.
The Local Carbon Intensity engine remains the layer underneath. Ambra is not a new methodology bolted onto a different stack. It is the application layer that connects directly to cloud usage APIs and delivers the most accurate and granular emissions figures the underlying data allows, on the customer's actual environment, end to end.
A defensible number in a filing is necessary. It is not sufficient. The point of measuring is to reduce.
Ambra Delta is the second product in the launch. Delta consumes Spectrum's output and surfaces broad optimization signals: resources running on instance families with high carbon-per-vCPU ratios; environments where utilization patterns suggest right-sizing; regions where the same resource would produce a lower carbon footprint elsewhere.
Spectrum measures. Delta recommends. The separation is deliberate: it keeps each product accountable for one thing.
Nodera started in 2025 by publishing local, per-hour carbon intensity, and then the same signal for the cloud regions sitting on top of it, based on the physical locations of the underlying datacenters. That data product, Cloud Carbon Intensity, exists because we believe the unit of decision in carbon-aware computing is the hour, not the year. It is still available as a standalone API for teams who want to build their own tooling.
What is new is the application layer. Ambra Spectrum and Ambra Delta take the same time-resolved, locally-grounded signal and apply it directly to a customer's cloud environment, so the resulting number is both filing-grade and operationally meaningful.
The mission has not changed. Servers should run when renewables do. The local intensity engine made it knowable. Ambra makes it usable.
If you are preparing a 2026 CSRD filing and your cloud carbon line item is currently spend-based, or you are reconciling multiple methodologies and cloud bills from a monthly hyperscaler dashboard, the part of ESRS E1 to watch is the disclosure of the methodology and underlying data alongside the gross Scope 3, Cat 1 figure. A spend-multiplied-by-sector-factor estimate is harder to evidence under that requirement than a utilization-based figure anchored to the cloud provider's own monitoring APIs and a per-region, time-resolved grid intensity.
Spectrum produces a cloud carbon report from your cloud environment that an external audit team can trace back to source. Delta layers on once measurement is in place and surfaces where the footprint, and the bill, can come down.
