Reconciling Bottom-Up Metrics with Top-Down Reporting for Cloud Carbon Accounting

• Workload carbon accounting informs carbon-reduction evaluation, regulatory and investor reporting, and workload scheduling and adaptation.Source: §1 · p. 1
• Bottom-up metrics can guide optimization but miss provider-side overheads, while top-down reports are comprehensive yet coarse and delayed.Provider reports are typically published 14–21 days after month-end.Source: §1 · p. 1
• An improvement to a workload’s bottom-up metric may not appear in provider reporting because the two approaches cover and allocate emissions differently.Source: §1 · p. 1
• The paper proposes rSCI, which anchors a bottom-up energy estimate to the provider report through a residual allocated to workloads.Its contributions also include a survey of 50 providers and recommendations for reporting and standards.Source: §1 · p. 2

• Operational SCI estimates carbon from workload energy and regional carbon intensity per functional unit of work.This signal responds to energy efficiency and carbon-aware timing or placement, but not whether a workload requires less provisioned capacity.Source: §2 · p. 2
• SCI adds an embodied-carbon term M, the workload’s amortized share of hardware embodied carbon, to operational carbon.The specification names energy efficiency, hardware efficiency, and carbon awareness as carbon-reduction actions.Source: §2 · p. 2
• Bashir et al. [9] identify a sunk-carbon fallacy in using past embodied emissions for operational scheduling and recommend oSCI for scheduling and scaling.A lower amortized embodied term can favor a less energy-efficient server even though scheduling cannot undo manufacturing emissions.Source: §2 · p. 2
• oSCI does not reward reserving less hardware beyond the energy it saves, or purchasing less and lower-embodied hardware.Source: §2 · p. 2
• Bottom-up estimates cannot fully attribute provider emissions because tenants lack direct visibility into shared idle capacity and other provider-side overheads.Jacquet et al. estimate up to three times as much carbon for busy VMs as OVHcloud’s VM-size allocation method.Source: §2 · p. 2

• The survey covered 50 providers, and none of the 10 GPU/HPC neocloud providers exposed per-tenant emissions.Source: §3 · p. 2
• None of the surveyed providers responds to all carbon-reduction actions, and providers’ documented methods differ in what they count, allocate, and report.Table 1 classifies provider responses to SCI’s three action categories as supported, partial or proxy, unsupported, or undocumented.Source: §3 · p. 2, Table 1 · p. 3
• AWS and GCP allocate emissions using activity units that include usage measures and economic proxies, such as equivalent revenue or list price.At GCP, a cheaper-but-dirtier SKU can look greener because the per-unit factor tracks list price rather than energy or life-cycle assessment.Source: §3 · p. 3
• When VM allocation depends only on reserved resources or cost, equally sized and long-running VMs receive the same weight despite different utilization.Source: §3 · p. 3
• Most customer dashboards report emissions at the service level, coarser than a bottom-up metric’s per-workload view.Source: §3 · p. 3
• AWS and GCP’s monthly allocation rules erase when a tenant runs, so shifting work to cleaner hours does not lower its usage-based monthly emissions share.Source: §3 · p. 3
• AWS, GCP, and most surveyed providers expose location-based Scope 2 figures, while Azure, T Cloud, and Alibaba Cloud do not expose a separate location-based view.Without that separate view, the grid signal behind choosing a cleaner region is obscured.Source: §3 · p. 3

4 Reconciling Bottom-Up and Top-Down

• rSCI retains the operational term and adds a weighted residual to anchor per-workload carbon attribution to the provider’s top-down report.The residual makes disagreements explicit without treating either estimate as ground truth.Source: §4 · pp. 3–4
• Workload setup treats each billable service or job across reporting slices; measured resource quantities and per-type coefficients can estimate its bottom-up energy.The example energy model optionally applies PUE for facility overhead.Source: §4 · p. 3
• Scaling workload scores back to carbon makes attributions sum to the reported total, both within each slice and across slices.The identity holds for any residual partition and normalized weights.Source: §4 · p. 4
• An equal residual split reconciles but ignores workload differences; the proposed decomposition follows provider scopes, whose residuals capture distinct emissions.Scope 1 includes diesel and refrigerants, Scope 2 unmodeled idle energy and facility overhead, and Scope 3 embodied hardware and other emissions.Source: §4 · p. 4
• The scope residuals are regrouped as energy- or capacity-driven because those drivers better match tenant-controlled activities and provisioning requirements.Tenants estimate each scope’s energy-driven fraction; Scope 1 is initially treated as capacity-driven, while Scope 2 and Scope 3 can mix drivers.Source: §4 · p. 4
• Energy-driven residuals are allocated in proportion to operational emissions, using time-summed emissions when carbon intensity varies.The reporting slice is retained for reconciliation.Source: §4 · p. 4
• Capacity-driven residuals are allocated by provisioning needs such as peak demand, redundancy, and warm instances; existing allocation rules offer starting points, but adapting and evaluating them remains future work.Related approaches include static-energy allocation and peak-demand attribution.Source: §4 · p. 4
• Exact rSCI scores are retrospective because the residual is known only after provider reporting; provisional scores use historical reports and forecasts, then require adjustment.Validating provisional estimates and quantifying their uncertainty remain future work.Source: §4 · p. 4

5 Example

• The illustration models an internal LLM service on an 8×H100 node over three days and reports hourly emissions per million tokens.It uses a 2024 Azure inference trace, California carbon-intensity data, and a synthetic shared-pool load cycle.Source: §5 · p. 4
• oSCI attributes about 58 kg of the 100 kg report, while SCI adds 5.1 kg of embodied emissions and reaches 63.0 kg.oSCI ranges from 52 to 270 gCO2/Mtok; SCI still falls short of the provider’s total.Source: §5 · p. 5
• rSCI retains oSCI’s operational term and adds the provider-report residual, allocating energy residuals by operational emissions and capacity residuals by provisioning needs.The comparison identifies rSCI as the only metric that guarantees attributed workload emissions sum to the provider’s reported total.Source: §5 · p. 5
• The energy-driven residual contributes 11–57 gCO2/Mtok and the capacity-driven residual 16–139 gCO2/Mtok, versus 72 gCO2/Mtok under uniform capacity allocation.By construction, multiplying hourly rSCI scores by token counts and summing yields the reported 100 kg; the rule assigns more capacity emissions per token during shared peaks.Source: §5 · p. 5

6 Barriers to Practical Adoption

• Across six months of production data from an AWS account running a web service in Frankfurt (December 2025–May 2026), “Other” accounted for 67–96 % of reported emissions and combined diverse services.AWS bills individual services separately, but its carbon report provides no resource-level breakdown to validate attribution to individual workloads.Source: §6 · p. 6
• The authors call for resource-level emissions by reporting period, separate energy and capacity components, reproducible reports, and standardized cloud-reporting guidance.Shared-peak allocation also requires demand data for the shared resource pool.Source: §6 · p. 6
• AWS EC2 bottom-up estimates were roughly 2× the reported location-based Scope 2 total at idle and 5× at moderate utilization, yielding a negative residual.Without further information, model error cannot be distinguished from reporting-boundary or allocation differences; peak-based allocation of a negative capacity residual reverses the intended incentive.Source: §6 · p. 6
• Customer-facing reports can be difficult to reproduce or interpret, and Microsoft notes that its customer emissions differ from corporate disclosure.The paper argues that without stable, reproducible totals, reconciliation cannot provide trustworthy workload attribution.Source: §6 · p. 6
• Provider methods differ in reporting boundaries, allocation rules, and Scope 3 coverage, reflecting gaps in GHG Protocol guidance for cloud infrastructure.The paper notes that some providers expose only market-based Scope 2 emissions, while others use differing usage, price, or hardware-based allocation methods.Source: §6 · p. 6

7 Conclusion

• rSCI allocates the residual so workload emissions sum to the provider’s reported total, with energy- and capacity-driven components intended to attribute idle capacity and embodied carbon to workloads driving them.The conclusion says this decomposition can preserve operational incentives.Source: §7 · p. 6
• Current provider reports remain too coarse, opaque, and inconsistent to support credible reconciliation in practice.The paper calls for production evaluation across clouds, validation of allocation weights and incentives under different residual signs, betas, and provider responses, and reproducible reconciliation pipelines.Source: §7 · p. 6
• The authors identify more granular, transparent reporting and clearer cloud standards as conditions for making carbon accountability as operational as cost accountability.They also propose exploring online proxies for residuals and capacity weights while exposing uncertainty until final reports arrive.Source: §7 · p. 6

Survey scope

• The sample covers general-purpose compute, GPU/HPC, CDN/edge, application hosting, and object storage, with a Europe and North America focus.Colocation-only providers, general business SaaS, model-only APIs, and independent carbon-accounting tools were excluded; selection did not depend on disclosure availability.Source: §A.1 · p. 9

Classification limits

• Classification reflects public documentation and claims; the authors did not test every reporting tool or independently verify all reported figures.Official documentation and reports were initially reviewed on 27 September 2026.Source: §A.1 · p. 9

Disclosure categories

• Among 50 providers, 15 offered customer reports, 17 public metrics, 12 claims only, and 6 had no qualifying disclosure identified.Table 3 presents environmental disclosures from the surveyed providers.Source: §A.1 · p. 9, Table 3 · pp. 9–10

Report coverage

• 15 of the 50 surveyed providers offer customer-attributed emissions reports, and Table 4 compares their intervals, breakdowns, emissions sources, and electricity accounting methods.The table entries are based on public documentation cited beside each provider.Source: §A.2 · p. 11, Table 4 · p. 11

Accounting dimensions

• Table 4 distinguishes location-based from market-based Scope 2 electricity accounting and compares selected Scope 3 sources, which do not map one-to-one to GHG Protocol categories.Location-based factors reflect the local grid; market-based factors reflect provider electricity purchases, including contracts and renewable energy certificates.Source: §A.2 · p. 11, Table 4 · p. 11

Caveats

• Reported detail may vary by service and region, listed breakdown dimensions need not be available together, and a checkmark does not establish complete source coverage.The authors did not independently verify reported emissions; daily reporting warrants caution, with Scaleway daily reports appearing unreliable in June 2026 tests.Source: §A.2 · p. 11

Efficient resource

• Most allocation methods use prices or pooled resource weights that need not track hardware efficiency; Scaleway models CPU power but averages GPU consumption estimates.GCP uses list prices [76], Azure normalized costs, AWS normalized instance-hours, and IBM vCPU-hours; T Cloud uses measured power profiles.Source: §A.3 · p. 12

Lower utilization

• Lower CPU activity reduces attributed electricity only in Scaleway’s CPU power model; many methods keep allocation quantities fixed, and several providers do not specify activity sensitivity.Scaleway’s GPU estimates do not follow customer activity; AWS, GCP [76], IBM, Exoscale, and Azure retain fixed allocation quantities, while T Cloud documentation conflicts.Source: §A.3 · p. 12

Right-size

• Smaller reservations reduce allocation quantities in most methods, while the total response can depend on post-resizing utilization or on undocumented allocation details.Scaleway allocates manufacturing impacts by reserved-resource shares; T Cloud does not establish how increased utilization affects its result.Source: §A.3 · p. 12

Region

• Most providers use regional grid factors, so the same electricity use receives fewer attributed emissions in a cleaner region; some expose only market-based results.Azure and T Cloud provide only market-based Scope 2 figures, while IBM’s location-based output is listed as temporarily disabled.Source: §A.3 · p. 12

Time

• None of the reviewed methods documents lower customer-reported emissions from shifting work to cleaner hours.Methods use monthly, yearly, or unspecified electricity factors, and some providers lack separate location-based output for this comparison.Source: §A.3 · p. 12

Operational improvements

• With reports, scope fractions, output, other workloads, and capacity shares fixed, lowering operational emissions cannot raise the score while X remains positive.The score strictly decreases when βS2 < 1 and the workload has less than the full capacity share, or when βS2 = 1 with positive reported Scope 2 emissions and positive operational emissions from other workloads.Source: B Conditions for Allocation Incentives · p. 13
• Across slices, the result requires the assumptions to hold in each slice and operational emissions not to increase in any affected slice; moving work between slices requires comparing combined attributions.Lower total operational emissions alone do not guarantee a lower score when work moves between slices.Source: B Conditions for Allocation Incentives · p. 13

Capacity allocation

• A smaller capacity share lowers the score for a positive capacity residual but raises it for a negative residual; a zero residual makes the share irrelevant.Setting every βk = 1 removes the capacity component.Source: B Conditions for Allocation Incentives · p. 13

Limits

• The fixed-report results concern attribution, not physical emissions savings; actions changing capacity shares, reports, scope fractions, other workloads, or output require those changes to be included.Source: B Conditions for Allocation Incentives · p. 13