Carbon-aware computing

EXAMPLES:
  Run ML training overnight when grid is wind/solar-heavy
  Defer batch jobs to renewable-energy windows
  Geographic load balancing toward cleaner grids during dirty hours

TYPICAL daily pattern (most grids):
  Morning (6-9 AM): high carbon (peaker plants firing for ramp-up)
  Mid-day (11 AM - 2 PM): lower carbon (solar peak)
  Afternoon (3-6 PM): rising carbon (peakers + solar declining)
  Evening (7-10 PM): high carbon (peakers + no solar)
  Night (11 PM - 5 AM): variable (wind in some regions; cleaner)

WORKLOAD                              CARBON-AWARE?
──────────────────────────────────────────────────────────────────
Real-time customer-facing               No (latency-critical)
Synchronous API (response < 1 sec)     No
Batch ML training                       Yes: defer to clean windows
Data pipeline (overnight ETL)           Yes: already async
Report generation                        Yes: flexible timing
Backup operations                       Yes: async by nature
CI/CD workloads                         Yes: async, restartable
Webhook fan-out                          Sometimes: queue tolerance
Background processing                    Yes: definitionally async

PATTERN A: Daily batch time-shift
  Move daily ML training from 2 AM to 11 AM (solar peak)
  Same compute hours; different timing
  Lower carbon footprint

  Example: 50 GPU instances × 4 hours (~250W/GPU = 12.5 kW = 50 kWh)
  At 2 AM (350 gCO2/kWh): 17.5 kg CO2
  At 11 AM (250 gCO2/kWh during solar peak): 12.5 kg CO2
  Savings: ~29% (5 kg per run: 17.5 - 12.5; ~1,800 kg annually)

PATTERN B: Geographic shift for batch
  Route batch jobs to lower-carbon regions
  Example: from us-east-1 (350) to eu-north-1 (50)
  Even with data transfer overhead, total carbon drops significantly

PATTERN C: Pause-resume during dirty hours
  Critical batch resumes when grid cleans up
  Useful for very large training jobs (multi-day runs)
  Implementation: checkpoint/restart logic + grid-aware orchestrator

TOOL                              PROVIDER
──────────────────────────────────────────────────────────────────
Azure Sustainability Calculator    Microsoft
Google Cloud Carbon Footprint     Google
AWS Customer Carbon Footprint      AWS
Carbon Aware SDK (open-source)     .NET Foundation
electricitymaps.com                Public API for grid intensity
WattTime                           Real-time carbon signal API
                                  (research org; commercial API)

TYPICALLY: cost and carbon are LOOSELY positively correlated

  Off-peak times: often cheaper AND cleaner
    - Spot prices drop overnight
    - Renewables generate at off-peak hours (solar, wind)
    - Both factors align in some regions

  But not always:
    - Some regions have constant grid mix
    - Some workloads' cost is dominated by storage or egress, not compute time
    - Latency constraints constrain timing flexibility

SCENARIO 1: Different optimal regions
  Cheapest region for compute: us-east-1 (mature market)
  Cleanest region for carbon:  eu-north-1 (hydro)
  These are different choices. Pick based on which constraint
  matters more.

SCENARIO 2: On-demand vs Spot
  Spot is cheaper but evicts; if eviction causes restart,
  the restart consumes more total energy
  Spot is still usually cleaner per useful compute work
  Edge cases exist for very interrupt-heavy workloads

SCENARIO 3: Right-sizing
  Cost optimization: scale down to minimum instance
  Carbon optimization: same scale-down often applies
  But: some smaller instances are less efficient per watt
  (rarely matters; most efficient is also smallest)

PER-WORKLOAD CARBON REPORTING:
  Annual carbon impact
  Per-team attribution (same as cost allocation)
  Trends over time
  Effects of carbon-aware decisions

DECISION DRIVERS:
  Sustainability goals (corporate, division-level)
  ESG reporting requirements
  Customer / investor sustainability pressure
  Regulatory (some jurisdictions require carbon reporting)

MISTAKE                                   FIX
──────────────────────────────────────────────────────────────────
Applying carbon-aware to                   Real-time means latency-
real-time workloads                       sensitive; can't reschedule

Ignoring data-transfer carbon when         Geographic shifts that move
moving regions                            data create transfer carbon;
                                          measure end-to-end

Optimizing the small workloads first      Carbon (like cost) Pareto-
                                          distributed; optimize the
                                          biggest workloads first

Over-engineering the orchestration         Start with simple time-shifts
                                          (cron jobs); advanced
                                          orchestration is rarely
                                          worth the complexity

Conflating carbon-aware with               Carbon-aware is timing;
energy-efficient                          efficiency is architecture
                                          (Graviton, right-sizing).
                                          Both reduce carbon but
                                          differently

WORKLOAD: nightly ML training pipeline
  Currently scheduled: cron at 2 AM UTC
  Compute: 50 GPU instances for 4 hours = 200 GPU-hours

CURRENT carbon footprint (us-east-1, 350 g/kWh average):
  GPU power: ~250W per GPU × 50 GPUs = 12.5 kW
    (250W is a mid-range assumption; A100/H100 training GPUs draw
     400-700W, so scale the kWh and kg proportionally)
  4 hours × 12.5 kW = 50 kWh
  At 2 AM: 350 g/kWh × 50 kWh = 17.5 kg CO2 per run
  Daily: 17.5 kg
  Annual: ~6.4 tons CO2/year

OPTIMIZATION: shift to 11 AM (midday, cleaner on solar-heavy grids)
  Carbon intensity: ~250 g/kWh (illustrative)
  (CAVEAT: us-east-1 sits on the PJM grid, which is gas- and
   nuclear-heavy with limited solar, so its real midday dip is
   small. A ~100 g/kWh swing like this is representative of a
   genuinely solar-heavy grid such as us-west-1 (California), not
   us-east-1. Time-shifting pays off most on solar- or wind-heavy
   grids; on us-east-1 the intraday profile is closer to flat.)
  Same 50 kWh × 250 g/kWh = 12.5 kg CO2 per run
  Daily: 12.5 kg (saved 5 kg/day)
  Annual: 4.6 tons CO2/year

  Reduction: 28% (~1.8 tons CO2/year saved)

DECISION: shift the cron job timing
EFFORT: trivial (one cron expression change)
COST IMPACT: neutral (same compute hours)
CARBON IMPACT: 28% reduction; meaningful for ESG

ADDITIONAL OPTIONS to layer:
  Move to eu-north-1: another ~80% reduction on the new baseline
  Switch to Graviton equivalents (GPUs limited; some inference
    workloads can use Trainium or similar): ~30% efficiency gain

WORKLOAD candidate:    __________
  Type:    batch / async / scheduled (carbon-aware eligible)
  Currently runs:    __________  (timing or trigger)

CARBON CALCULATION:
  Current compute: __________ kWh/period
  Current region: __________ at __________ gCO2/kWh
  Current carbon: __________ kg CO2/period

OPTIMIZATION OPTIONS:
  □ Time-shift to clean-grid hours
    Estimated reduction: __________ %
  □ Geographic shift to cleaner region
    Estimated reduction: __________ %
  □ Pause-resume during dirty hours (advanced)
    Estimated reduction: __________ %

CHOSEN approach:    __________
EFFORT:    __________ days
ANNUAL CARBON SAVINGS:    __________ tons

If trivial (cron change): do it now.
If meaningful (region migration): include in next quarter plan.