Sustainability

A sustainability lead asks: how much carbon does our Kubernetes infrastructure emit, and which clusters are the worst offenders? Kubeadapt reports kg CO₂e for every workload, every namespace, and every cluster on the same surfaces that show cost — Dashboard, Cost Explorer, Reports — using a published methodology you can audit line by line.

What gets reported

The unit is kilograms of CO₂ equivalent (kg CO₂e). It rolls up the carbon emissions associated with running your workloads' compute and memory, attributed via the same accounting paths Kubeadapt uses for cost. You'll see kg CO₂e wherever you see dollars:

• KPI cards on the Cost Explorer and the Organization Dashboard.
• Per-workload, per-namespace, per-cluster rows in Cost Explorer's grouped tables.
• The Reports archive's monthly and quarterly views.
• The CO₂e column in the GreenOps reports list.

The numbers aren't third-party verified; they're computed with an industry-standard methodology against publicly available emission factors. The Methodology panel in the product (open it from GreenOps → View methodology) documents this in plain language for your stakeholders.

The methodology

Kubeadapt uses the Cloud Carbon Footprint (CCF) methodology by Thoughtworks. CCF is the de facto open-source reference for cloud carbon estimation; we follow its formula and its assumptions.

Calculations run inside Kubeadapt, using your cluster's observed instances and their utilization. The only external inputs are emission factors (region-specific grid intensity, provider PUE, per-instance-family power benchmarks), refreshed periodically as the underlying sources update.

The formula

Energy (kWh) = (Min Watts + Utilization% × (Max Watts − Min Watts)) × PUE ÷ 1000
CO₂e = Energy × Grid Carbon Intensity

Per-line:

• Min Watts and Max Watts come from the SPECPower benchmark database for the CPU model the workload runs on. Memory power adds 0.3725 W/GiB for DDR4. GPU power uses the GPU's TDP rating.
• Utilization% is the observed CPU utilization for the time period.
• PUE (Power Usage Effectiveness) multiplies for data-center overhead. Per-provider values below.
• Grid Carbon Intensity is the region's emissions per kWh of electricity. Values come from Ember Climate's Global Electricity Review 2024.

PUE table

These match the providers' publicly disclosed averages. The default applies to on-prem, bare-metal, or any provider not in the list. To override the default for a self-managed cluster, set the agent's PUE override in the Helm values; otherwise the methodology assumes 1.200.

Grid carbon intensity

Grid intensity measures how much CO₂ comes out per kWh of electricity in a given region. The global average sits around 442 gCO₂e/kWh. The spread by region is enormous:

• Renewables-heavy regions like eu-north-1 (Sweden) sit near 8 gCO₂e/kWh.
• Coal-heavy grids like ap-south-1 (Mumbai) sit near 952 gCO₂e/kWh — a 100× difference.

This means region choice matters more than instance choice for total emissions. Migrating a workload from eu-west-1 to eu-north-1 typically cuts its emissions by an order of magnitude without changing a single Kubernetes manifest.

Data sources

Per the in-product Methodology panel, the calculation uses:

• Cloud Carbon Footprint (CCF) by Thoughtworks — the reference methodology.
• SPECPower benchmark database — per-instance-family CPU power draw curves.
• Ember Climate — Global Electricity Review 2024 — regional grid carbon intensity.
• Cloud provider PUE disclosures — AWS, GCP, and Azure published averages.
• SCI Specification (ISO/IEC 21031:2024) — the Software Carbon Intensity standard from the Green Software Foundation, which CCF aligns to.

Each is cited so a reviewing engineer or sustainability lead can audit the inputs.

What's included and excluded

The Methodology panel splits this explicitly.

Included:

• CPU compute energy
• Memory energy
• GPU compute energy
• PUE overhead (cooling, networking infrastructure)

Excluded:

• Network data transfer energy (the methodology isn't settled yet; including a guess would mislead)
• Embodied carbon (hardware manufacturing)
• Storage device energy (drives spin regardless of your workload; attribution is hard)
• End-user device energy (your customer's laptop is not your scope)

The exclusions are deliberate. Including embodied carbon would require knowing your hardware refresh cadence, which Kubeadapt can't see; including networking energy would require traffic-path data that isn't captured yet. The numbers stay honest by reporting only what can be measured cleanly.

Reports

GreenOps reports are the archive of finalized monthly and quarterly emissions, alongside cost and energy. Open GreenOps → Reports to see the table; each row is a period (a month or a quarter) with CO₂ (kg), Energy (kWh), Cost ($), and CO₂/$1K (a carbon intensity metric per thousand dollars of spend).

Reports export as CSV — monthly and quarterly. There is no PDF report. Use the CSV in a spreadsheet, paste into a slide, or feed it into your sustainability reporting workflow.

How to reduce emissions

Three levers, in order of impact:

1. Region. Move workloads to regions with cleaner grids. eu-north-1, eu-west-3, us-west-2 (Oregon) all carry meaningfully lower intensity than their peers. The architectural change is usually small; the emissions change is large.
2. Right-sizing. Smaller requests mean fewer nodes mean less compute energy. Every right-sizing recommendation Kubeadapt produces is also a sustainability recommendation, and the CO₂e column on Cost Explorer makes that visible.
3. Spot and Graviton. Spot instances reduce idle capacity overhead; Graviton ARM instances draw less power per unit of compute. Spot Migration and the Capacity Planning simulator already model the cost delta — apply the same prioritization to emissions.

Next steps

• How Kubeadapt works — where the methodology inputs come from.
• Reports — the time-anchored archive that exports the monthly and quarterly CSVs.
• Right-sizing — the largest single lever on per-workload emissions.