How GreenOps calculates
cloud carbon emissions

Every other tool in this space is a dashboard built for sustainability officers. They pull three-month-old billing data and produce a PDF. By the time that data reaches you, the architecture is locked in and the carbon is already burnt.

The only intervention point that changes what gets deployed is the pull request. GreenOps posts carbon impact on the PR — before infrastructure is provisioned — so engineers can act before the decision is made.

Scope 2 emissions arise from the electricity consumed by cloud compute instances. GreenOps uses a linear interpolation power model extended with memory power draw, following the Cloud Carbon Footprint (CCF) v3 methodology:

W_cpu    = W_idle + (W_max − W_idle) × utilisation
W_memory = memory_gb × 0.392 W/GB        ← CCF standard constant
W_total  = W_cpu + W_memory

energy_kwh = W_total × PUE × 730h / 1000
co2e_g     = energy_kwh × grid_intensity_gco2e_per_kwh

Memory power draw is constant — DRAM draws near-constant power regardless of CPU utilisation. This is why memory-optimised instances (r5, Standard_E, n2-highmem) carry proportionally higher Scope 2 than general-purpose instances with similar CPU profiles.

Instance:    m5.large (AWS, x86_64, 2 vCPU, 8GB RAM)
W_idle:      6.8W   W_max: 20.4W

Step 1 — CPU:    6.8 + (20.4 − 6.8) × 0.50 = 13.6W
Step 2 — Memory: 8GB × 0.392              =  3.136W
Step 3 — Total:  13.6 + 3.136             = 16.736W
Step 4 — Energy: 16.736 × 1.13 × 730/1000 = 13.816 kWh/mo
Step 5 — CO₂e:  13.816 × 384.5           = 5,308.2 gCO₂e/mo

Asserted in engine.test.ts — verifiable in under 5 minutes.

Scope 3 covers the carbon emitted manufacturing the physical server hardware, prorated to the fraction of the server lifecycle used by the instance:

embodied_g/month = (1,200,000g / 35,040h / 48 vCPUs) × vcpus × 730h

Where:
  1,200,000g = estimated server lifetime emissions (CCF baseline)
  35,040h    = 4-year server lifecycle
  48 vCPUs   = reference server baseline
  ARM discount: × 0.80 (Graviton, Ampere Altra, T2A)

ARM instances receive a 20% Scope 3 discount reflecting lower manufacturing energy per transistor at equivalent process nodes.

water_litres = (W_total × 730h / 1000) × WUE_litres_per_kwh

Water Usage Effectiveness (WUE) varies by region. High-renewable regions such as eu-north-1 and swedencentral typically have lower WUE because less cooling is required in cooler climates.

GreenOps only applies emission formulas to instance types explicitly present in factors.json. When a resource is not in the ledger it is classified as LOW_ASSUMED_DEFAULT — shown as ⚠ UNKNOWN in output.

Current ledger coverage: 71 instance types — 40 AWS, 16 Azure, 15 GCP. All gaps are tracked as open issues. Coverage PRs are the fastest to merge.

The entire emission ledger is a single factors.json file you can read in ten minutes. Every formula is asserted in engine.test.ts. No network calls are made during analysis. The binary works in air-gapped and SOC 2 environments where SaaS carbon tools cannot be deployed.

If you disagree with an assumption — a grid intensity figure, a PUE value, an embodied carbon estimate — open a PR to factors.json and change it. The maths is MIT-licensed.