5 exercises — Practice green software and sustainable computing vocabulary in English: carbon intensity, carbon-aware workloads, SCI, GreenOps, and Scope emissions.
Tools: Cloud Carbon Footprint, Electricity Maps, CodeCarbon, Green Software Foundation SCI spec, AWS Customer Carbon Footprint Tool
0 / 5 completed
1 / 5
A sustainability engineer explains carbon intensity to the team: "Carbon intensity measures how much CO₂ is emitted per kilowatt-hour of electricity. It varies by grid and by time. In France, nuclear power means the grid has very low carbon intensity — around 50 gCO₂eq/kWh. In Germany, coal means higher intensity — 300–400 gCO₂eq/kWh at peak. The intensity also varies hour by hour as renewable generation fluctuates." What is carbon intensity and why does it matter for software deployment decisions?
Carbon intensity: the amount of greenhouse gas emissions (expressed as CO₂ equivalent, CO₂eq) produced per unit of electricity (gCO₂eq/kWh). It varies by: Grid region — France (nuclear): ~50 gCO₂eq/kWh; Germany: ~300 gCO₂eq/kWh; California: ~200; Poland (coal-heavy): ~700. Time of day — solar peaks midday, wind varies; carbon intensity fluctuates hour by hour. Season — winter often means more gas/coal. Why it matters for software: running the same workload in different regions or at different times can differ by 10× in carbon impact. Tools: Electricity Maps — real-time global carbon intensity by grid region. WattTime — programmatic carbon intensity data with forecasting. gCO₂eq — grams of CO₂ equivalent; accounts for all greenhouse gases (CO₂, CH₄, N₂O) normalised to CO₂ warming potential. In conversation: "We could save 60% of our batch job's carbon footprint just by running it at 2am when the grid is mostly nuclear and wind — same compute, much lower impact."
2 / 5
A cloud architect presents a carbon-aware architecture: "We're making our batch data pipelines carbon-aware. Temporal shifting means we delay non-urgent jobs to run when carbon intensity is lower — say, at night when wind is high. Spatial shifting means we move workloads to a region with lower carbon intensity. Our ML training jobs can wait 4 hours — so we shift them temporally. Our real-time API can't shift temporally, so we don't apply this there." What is the difference between temporal shifting and spatial shifting?
Temporal shifting: delaying a workload to a time when carbon intensity is lower. Requires: the workload to be deferrable (not real-time), carbon intensity forecasting, a scheduling system that can delay and trigger. Example: ML training, batch ETL, video transcoding, backup jobs. Spatial shifting: moving a workload to a geographic region where carbon intensity is currently lower. Requires: multi-region capability, data sovereignty is not a constraint, latency requirements are flexible. Example: global batch jobs, CDN asset processing. Green Software Foundation principles: Demand shaping — designing products to shift user behaviour towards greener times. Example: showing a "lower carbon" option on a download page with a scheduled delivery time. Energy proportionality — a server that's doing 10% of its work should use 10% of its peak power. Most servers are inefficient at low utilisation. Carbon budget — a team's or product's carbon allowance per quarter. Carbon-aware SDK — open-source library (Green Software Foundation) that provides carbon intensity data and shifting logic. In conversation: "Our weekly reports job has an SLA of 'ready by 9am Monday' — we have the whole weekend to find the lowest-carbon 2-hour window. That's temporal shifting."
3 / 5
A developer advocate explains the Software Carbon Intensity specification: "The SCI score measures the carbon emissions of software per functional unit. The formula is: SCI = (E × I + M) per R. E is energy consumed, I is the carbon intensity of that energy, M is the embodied carbon of the hardware used, and R is the functional unit — like per user, per API call, or per GB processed. SCI can't be offset — you have to actually reduce it." What is embodied carbon in the SCI formula?
Embodied carbon (also: embedded carbon): the greenhouse gas emissions generated across a hardware component's full lifecycle — manufacturing (mining raw materials, fabrication), shipping, installation, and end-of-life disposal. For a server, manufacturing accounts for 50–80% of its total lifecycle carbon. Operational carbon: emissions from the electricity consumed while running the hardware. SCI formula: E — Energy consumed by the software (kWh). I — Carbon intensity of the electricity grid (gCO₂eq/kWh). M — Embodied carbon allocated to this software (based on hardware utilisation share × hardware lifecycle carbon). R — Functional unit (per user/call/GB). Why embodied carbon matters: using a smaller instance doesn't just save electricity — it uses less of a server's embodied carbon. Keeping hardware longer amortises its embodied carbon over more use. Cloud has lower embodied carbon per workload due to higher utilisation rates than on-premises. Vocabulary: PUE (Power Usage Effectiveness) — data centre efficiency metric: total facility power / IT equipment power. 1.0 = perfect; typical: 1.1–1.5. GreenOps — applying FinOps principles to carbon: measure, optimise, govern. In conversation: "Our on-premises servers run at 15% utilisation — most of their embodied carbon is wasted. Moving to cloud gets us to 60% utilisation and much lower embodied carbon per unit of computation."
4 / 5
An SRE explains Scope emissions to the sustainability team: "Scope 1 emissions are direct — fuel we burn ourselves, like diesel generators. Scope 2 are indirect from purchased electricity — the biggest category for most tech companies. Scope 3 are all other indirect emissions: our supply chain, the flights our employees take, the devices our customers use to access our product. For most software companies, Scope 3 is 70–90% of total emissions." What are Scope 3 emissions and why are they the hardest to measure?
Scope 3 emissions: all indirect emissions in a company's value chain that are not Scope 1 or 2. The GHG Protocol (greenhouse gas standard) defines 15 Scope 3 categories including: upstream (purchased goods, supplier emissions, capital goods) and downstream (use of sold products, end-of-life treatment). GHG Protocol Scopes: Scope 1 — direct emissions from owned/controlled sources (on-site generators, company vehicles, gas heating). Scope 2 — indirect emissions from purchased electricity, heat, steam, cooling. Location-based vs. market-based accounting. Scope 3 — all other indirect emissions. For a cloud provider: chip manufacturing (supply chain), employee flights, customer energy use. Why hard to measure: data comes from thousands of suppliers and customers; methodologies differ; requires estimation and supplier engagement. For software companies: Use of sold products — the electricity customers use to run your software. Example: streaming video is a major Scope 3 source for Netflix-type services. Employee commuting and business travel. In conversation: "Our product runs on 200 million customer devices — the energy those devices use to run our app is Scope 3. We can influence it through efficiency, but we can't control it."
5 / 5
A cloud cost engineer introduces GreenOps practices: "GreenOps applies FinOps principles to carbon. Just like FinOps makes cloud cost visible and accountable, GreenOps makes carbon emissions visible and actionable. We have zombie instances — servers that are running but doing nothing. Rightsizing for cost also helps carbon. We're adding carbon as a column next to cost in our infrastructure dashboard." What is a zombie instance and why does it matter for both cost and carbon?
Zombie instance: a cloud resource that is running (incurring costs and consuming energy) but performing no useful work. Common zombie types: stopped EC2 instances with attached EBS volumes still charging, unattached load balancers, unused Elastic IPs, development environments left running over weekends, orphaned databases from cancelled projects. Zombie impact: financial waste (direct billing) + operational carbon (idle electricity) + embodied carbon (hardware allocated but unused). GreenOps vocabulary: GreenOps — applying FinOps's Inform → Optimise → Operate cycle to carbon emissions. Cloud Carbon Footprint — open-source tool that calculates carbon emissions from cloud usage data. AWS Customer Carbon Footprint Tool — AWS's built-in carbon dashboard. Rightsizing for carbon — oversized instances waste embodied carbon and electricity. Right-sizing reduces both cost and carbon. Sustainability KPI — e.g., carbon per API request, carbon per active user. AWS Graviton — ARM-based instances with up to 60% better energy efficiency than x86. Choosing Graviton reduces both cost and carbon. In conversation: "Our zombie instance audit found $18K/month in waste and approximately 40 tonnes of CO₂eq per year — the fixes are identical: terminate the unused resources."