Sådan laver du CO₂-bevidst jobplanlægning i skyen

Forestil dig, at din næste batchkørsel eller ML-træning ikke blot leverer forretningsværdi, men samtidig sparer tonsvis af CO₂ - helt uden at du behøver skifte cloud-udbyder eller omskrive al din kode.

I takt med at elnettets CO₂-intensitet svinger dramatisk fra time til time og fra region til region, åbner der sig et nyt, grønt spillerum for alle, der driver workloads i skyen

Ved at flytte de fleksible jobs, der kan vente, til de tidspunkter og steder hvor strømmen er grønnest, kan du skære dybt i både udledninger og omkostninger - uden at gå på kompromis med SLA’er eller compliance.

I denne artikel på IT Forum Danmark guider vi dig gennem de konkrete strategier, værktøjer og best-practices, der gør CO₂-bevidst jobplanlægning til mere end et buzzword. Fra power-prognoser og Kubernetes-plugins til politikker, dashboarding og FinOps-synergi: Du får trin-for-trin-planen, der bringer din sky-drift ind i den grønne fremtid.

Klar til at optimere kloden - og budgettet - én cronjob ad gangen? Så læs med!

Sådan laver du CO₂-bevidst jobplanlægning i skyen

Hvorfor CO₂-bevidst jobplanlægning i skyen?

Elektricitet er ikke lige “grøn” på alle tidspunkter eller i alle regioner: CO₂-intensiteten kan svinge 5-10× i løbet af et døgn, og naboregioner kan være drevet af alt fra vind til kul. Når din infrastruktur allerede kører i en public cloud med datacentre spredt over hele kloden, kan du derfor virtuel flytte arbejdslaster i tid (udsætte eller fremrykke) og sted (skifte cloud-region) for at ramme de såkaldte “grønne vinduer”. Med strømprognoser fra fx ElectricityMaps eller WattTime kan du i realtid måle, hvornår et job vil udlede færrest gram CO₂ per kWh - og automatisere scheduler-beslutningen derefter. Resultatet er ikke bare bedre klimatal, men også forbedret kapacitetsudnyttelse, fordi du udnytter de perioder, hvor cloud-udbyderen har billig, overskydende og ofte grønnere energi til rådighed.

Ikke alle workloads er lige fleksible. Velegnede kandidater omfatter batch-behandling, ETL-pipelines, maskinlærings-træning, videorendering og natlige rapport-kørsler, som kan vente minutter eller timer på grønnere strøm. Mindre egnede er latency-følsomme API’er, finansielle handler i realtid og andre 24/7-tjenester med stramme SLA’er. Gevinsterne tæller: klima (op til 30-60 % lavere CO₂-fodaftryk), omkostninger (udnyt spot-priser og lav belastning), samt kapacitet (smoothing af peak-loads). Begrænsningerne er til gengæld vigtige at kortlægge: netværkslatency ved regionsskift, dataresidency og compliance-krav (GDPR, finanslovgivning), drifts-SLA’er, samt usikkerheder i strømprognoser. En succesfuld CO₂-bevidst strategi balancerer derfor forretningskrav med klima-ambitioner gennem klare politikker, måltal og automatiseret orkestrering.

Metoder og værktøjer: fra strømprognoser til carbon-aware orkestrering

For at gøre jobplanlægningen carbon-aware skal udviklere først have adgang til pålidelige data om elnettets aktuelle og forventede CO₂-intensitet. Her er to hovedkilder:

  • ElectricityMaps - leverer både real-time og day-ahead prognoser i g CO₂/kWh for 180+ geografier via API og streaming-webhooks.
  • WattTime - specialiserer sig i marginal-emissionsdata og giver ”signal-kald”, der angiver de grønneste 15-, 30- eller 60-minutters vinduer.
I skyen kan du koble disse data sammen med de indbyggede emissions-dashboards: Google Cloud Carbon Footprint, Azure Emissions Impact Dashboard og AWS Customer Carbon Footprint Tool. Denne kombination giver både prognoser (hvor bør vi køre?) og telemetry (hvor kørte vi faktisk?). Når du har transparens, kan du anvende arkitekturmønstre som tids- og lokationsfleksibel planlægning (udskyd jobs til et grønt interval i samme region), grønne vinduer (start ved fastlagt CO₂-tærskel) eller multi-region fail-over (vælg den region med lavest udledning, sekundært den næstbedste ved kapacitetsmangel). Kombineres dette med spot/preemptible instanser, høster man ofte både CO₂- og omkostningsbesparelser, fordi spot-kapacitet typisk frigives samtidig med lav belastning og høj andel vedvarende energi.

Selve orkestreringen kan implementeres i de fleste pipelines:

  • Airflow / Cloud Composer - brug et custom TriggerRule eller et BranchOperator der kalder CO₂-API’et og vælger region/ventetid dynamisk.
  • Kubernetes - udvid kube-scheduler med et plugin eller admission-controller, der injicerer nodeSelector/taint baseret på et eksternt emissions-webhook.
  • Serverless & køtjenester - sæt f.eks. Cloud Tasks, SQS eller Pub/Sub til først at release meddelelser, når emissionsværdien er under en tærskel.
Politikkerne bør være deklarative, så de kan versionstyres i GitOps:
Parameter Eksempel
CO₂-tærskel < 200 g CO₂/kWh
Maks. ventetid 4 timer
Fallback-regioner europe-north1 → europe-west4 → on-prem
Prioritet High = kør altid, Medium = vent hvis muligt, Low = kun under grønne vinduer
Ved at koble disse regler til jeres CI/CD-flow (feature flags, progressive roll-outs) kan I gradvist indføre CO₂-bevidst jobplanlægning uden at kompromittere SLA’er - og samtidig synliggøre besparelser i jeres FinOps/GreenOps rapporter.

Trin-for-trin implementering og best practices i produktion

1) Definér mål og KPI’er: Start med at fastlægge et baseline-år og udvælg måltal som gCO₂e pr. job, kgCO₂e pr. måned eller % workloads kørt i grønne vinduer. Sæt både absolutte (tons CO₂) og relative (intensity per compute-hour) mål, så I kan sammenligne på tværs af clouds og teams.
2) Kortlæg workloads: Lav en matrix med forretningsværdi på den ene akse og tids-/lokationsfleksibilitet på den anden. Batch-jobs uden hårde SLA’er ryger i “grøn spand”; realtids-API’er i “rød”. Tilføj kolonner for datavolumen, compliance-krav og nuværende cost.
3) Vælg datakilder, regioner & governance: Sammenlign ElectricityMaps (global; ~5 min opløsning) og WattTime (North America; marginal CO₂). Kryds med jeres mulige cloud-regioner i et simpelt

Region CO₂-spænd Data-sovereignty Latency ms
europe-north1 (Finland) 18-90 g/kWh GDPR 35
us-west4 (Oregon) 40-600 g/kWh CCPA 140
og filtrér dem, der bryder DORA, PCI-DSS eller lokale persondatalove.

4) Design politikker: Definér tærskler som max 200 gCO₂/kWh, max ventetid 6 t og fallback-region, plus vægte (CO₂, pris, latency). Brug

  • grønne vinduer (schedule-tags i Airflow)
  • kø-prioritet (priority_weight i Kubernetes-Job)
  • preemptible/spot for lave intensiteter og priser.

5) Implementér i scheduler/CI-CD: Tilføj feature flags så hvert team kan togg­le “carbon aware mode”. I GitOps-repoet lægger I en policy.yaml; en admission-controller i K8s afviser pods, hvis co2_now > threshold. Rul ud med canary-jobs (f.eks. 10 % af batchkøen) og øg til 100 %, når SLA’er holdes. Log “scheduling-reason” i job-metadata, så DataOps kan lave A/B-analyse mod baseline.

6) Observability & rapportering: Saml CO₂-data i Prometheus og vis i Grafana-dashboard (sum(co2_grams_total) by (team)). Udløs alarmer ved afvigelser >20 % fra mål. Eksportér månedlige CSV’er til ESG-/CSRD-rapporteringen, og indlæs dem i jeres FinOps-portal for at vise CO₂-pris pr. krone spend.
7) Drift & sikkerhed: Hav graceful degradation: hvis prognosedata mangler, falder systemet tilbage til normal scheduler. Sæt kvoter på spot-instanser for at undgå udgiftseksplosioner ved annullerede jobs. Test failovers med chaos engineering; verificér at kritiske jobs flyttes tilbage til primær region inden for SLA. Dokumentér processen i runbooks og tilknyt den eksisterende incident-severity-matrix, så grøn planlægning aldrig kompromitterer availability eller security posture.

Indholdsfortegnelse