Carbon-Aware Scheduling Cheat Sheet [2026 Multi-Cloud]

Carbon-aware scheduling is the practice of placing flexible work where and when electricity is cleaner, while still respecting reliability, latency, sovereignty, and cost constraints. In multi-cloud setups, the two fastest levers are time shifting and region shifting. This cheat sheet focuses on operating patterns you can implement quickly across Kubernetes, CI fleets, batch queues, and internal control planes.

High-Value Takeaway

Treat carbon as one more scheduler input, not a separate platform. Start with flexible workloads, feed the orchestrator a fresh grid-intensity signal, and apply hard guardrails for latency, residency, and cost before you optimize for lower emissions.

Quick Start

Use this sheet when coordinating non-urgent or elastic workloads across AWS, Azure, GCP, or self-managed clusters. The practical loop is simple: read a carbon signal, translate it into placement hints, and let the scheduler choose the least-bad option that still meets delivery constraints.

Target flexible work first: nightly ETL, CI runners, model retraining, backups, report generation, and large data compaction jobs.
Prefer marginal-intensity weighting over static region rankings when you have near-real-time data.
Keep deadline, egress, and residency as hard blocks, not soft preferences.
Roll out in shadow mode before letting automation move production work.

Before publishing policy files internally, run the snippets through Code Formatter so YAML, JSON, and shell examples remain easy to diff and safe to copy.

Live Search Filter

Filter the reference by scheduler, cloud, workload type, or metric. Try terms like kubernetes, batch, terraform, latency, or residency.

Filter This Cheat Sheet

Showing all searchable rows and command cards.

Keyboard Shortcuts

These page-level shortcuts make the cheat sheet usable like a quick terminal reference.

Shortcut	Action	When To Use It
/	Focus the live filter	Jump straight into search without reaching for the mouse.
Esc	Clear the filter	Reset the page after narrowing to one cloud or job type.
g c	Jump to commands	Useful during implementation or incident debugging.
g f	Jump to configuration	Go straight to policy templates and workload metadata.
g a	Jump to advanced usage	Move quickly into scoring, fallback, and rollout patterns.
?	Return to this shortcuts table	Helpful after filtering deep into commands or config.

Commands Grouped By Purpose

The command names and endpoints below are implementation patterns. Wire them to your chosen carbon data provider, placement service, or scheduler extension.

1. Discover Carbon Signals

Fetch the latest forecast and turn it into a placement input for your control loop.

curl -s "$CARBONAPI/forecast?zone=us-west-oregon" -H "Authorization: Bearer $CARBONTOKEN" | jq '.forecast[0] | {zone, datetime, marginalgco2kwh}'

2. Apply Placement Hints

Translate fresh signal data into node or region metadata that workloads can target.

kubectl label nodes ip-10-0-12-41 carbon.zone=us-west-oregon carbon.intensity=low carbon.last_update=2026-04-18 --overwrite

3. Delay Flexible Work

Gate non-urgent jobs behind a carbon threshold instead of starting on the first free slot.

THRESHOLD=180
CURRENT=$(curl -s "$CARBONAPI/current?zone=us-east-1" | jq -r '.marginalgco2_kwh')
if [ "$CURRENT" -le "$THRESHOLD" ]; then
  ./run-batch.sh
else
  ./enqueue-batch.sh --delay-minutes 45
fi

4. Compare Outcomes

Validate the emissions and cost impact of a scheduling policy from run artifacts.

jq -s 'groupby(.window)[] | {window: .[0].window, gco2esaved: (.[0].baselinegco2e - .[0].actualgco2e), costdelta: (.[0].actualcost - .[0].baselinecost), deadlinemissrate: .[0].deadlinemiss_rate}' runs/*.json

Configuration

Configuration is where most teams either overfit or stay too vague. Start with one policy file, one workload tier model, and a short list of allowed regions.

Baseline Policy File

This is the minimum viable policy for a controller that recommends or enforces lower-carbon placement.

carbonPolicy:
  mode: recommend
  signal: marginal
  maxDelayMinutes: 90
  allowedRegions:
    - us-west-oregon
    - europe-west4
  denyIf:
    residency: true
    p95LatencyMsAbove: 250
  weights:
    carbon: 0.55
    cost: 0.25
    latency: 0.20

Terraform Region Metadata

Expose carbon preferences in infrastructure code so the app platform and runtime scheduler share the same intent.

locals {
  carbonregionweights = {
    us-west1     = 0.80
    us-central1  = 0.55
    europe-west4 = 0.72
  }
}

resource "googlecloudrunv2service" "etlapi" {
  name     = "etl-api"
  location = var.primaryregion

  labels = {
    carbonpolicy = "follow-carbon"
    workloadtier = "flexible"
  }
}

Kubernetes Workload Metadata

Attach intent directly to the workload so placement logic remains visible in Git and reviewable by application teams.

apiVersion: batch/v1
kind: Job
metadata:
  name: nightly-etl
  labels:
    workload.tier: flexible
    carbon.policy: follow-carbon
spec:
  template:
    spec:
      nodeSelector:
        carbon.intensity: low
      containers:
        - name: etl
          image: ghcr.io/acme/nightly-etl:2026.04.18
          env:
            - name: CARBONMAXDELAY_MINUTES
              value: "90"
      restartPolicy: Never

Advanced Usage

This is where carbon-aware scheduling becomes credible in production: not by chasing the greenest region blindly, but by ranking viable options under multiple constraints.

Multi-Objective Scoring

Use a weighted score once you have enough signal quality to compare regions and time windows.

score = (carbonweight  normalizedcarbon)
      + (costweight  normalizedcost)
      + (latencyweight  normalizedlatency)
      + (egressweight  normalizedegress)

choose the lowest score that still satisfies:
  - deadline
  - residency
  - capacity
  - service tier

Residency-Safe Region Fallback

Split preference from prohibition. That keeps policy readable and stops carbon logic from bypassing compliance boundaries.

routingRules:
  - name: eu-flex-batch
    match:
      workloadTier: flexible
      dataClass: internal
      residency: eu
    prefer:
      - europe-west4
      - europe-north1
    fallback:
      - europe-west1
    block:
      - us-central1
      - us-west1

Shadow Mode Rollout

Run recommendations beside the current scheduler first, then compare projected savings against operational risk.

./scheduler plan --policy ./carbon-policy.yaml --mode shadow --input ./yesterday-runs.json --emit metrics.json
jq '.summary | {candidatemoves, projectedgco2esaved, projectedcostdelta, deadlinerisk}' metrics.json

Operational Guardrails

The fastest way to make a carbon-aware rollout fail is to optimize only for carbon. Production controllers need hard edges.

Use gCO2e per job, cost delta, queue age, and deadline miss rate as your baseline operating metrics.
Promote recommend mode to enforce mode only after you have at least one clean comparison window for every workload tier you plan to move.
Keep data movement explicit. A cleaner region is not a win if cross-region storage reads or egress erase the carbon or cost benefit.
Segment workloads into strict, flexible, and opportunistic tiers so application teams know what the scheduler is allowed to change.
When exporting scheduler traces for review, scrub tenant names, request IDs, and dataset paths with the Data Masking Tool before sharing logs outside the platform team.

Rule of thumb: if a job cannot tolerate delay, relocation, or short-term quota changes, it probably should not be your first carbon-aware candidate.