Bevezetés: a FinOps és a GreenOps összefonódása 2026-ban
2026-ban a felhőszámítástechnika világában egy alapvető változás zajlik: a pénztárcakímélő és a klímakímélő felhőműveletek már nem kezelhetők külön. A FinOps (felhőpénzügyi menedzsment) és a GreenOps (fenntartható felhőműveletek) közötti határ eltűnik, és megszületik egy új, integrált megközelítés: a Green FinOps.
Ez a paradigma felismeri, hogy minden feleslegesen futó virtuális gép, minden túlméretezett instancia és minden elfeledett tároló-kötet nem csak felesleges költség — hanem felesleges szén-dioxid-kibocsátás is. Őszintén szólva, ez olyan egyszerű összefüggés, amit meglepő, hogy eddig nem kezeltünk egységesen.
A logika tényleg egyszerű: a felhőszolgáltatások energiát fogyasztanak. Az energia egy része fosszilis forrásokból származik. Ha csökkentjük a felhasznált felhőerőforrást, csökkentjük az energiafogyasztást, és ezzel arányosan csökkentjük a szénlábnyomot. A költséghatékonyság és a karbonhatékonyság tehát matematikailag összefügg.
De miért pont 2026-ban vált ez kritikussá? Három fő okból:
- A szabályozási környezet szigorodik. Az Európai Unió CSRD (Corporate Sustainability Reporting Directive) irányelvei értelmében egyre több vállalatnak kell jelentenie a Scope 3 kibocsátásait, amelybe a felhőhasználat is beletartozik.
- A felhőköltségek soha nem látott magasságba emelkedtek. A Gartner és az IDC előrejelzései szerint a nyilvános felhőköltés 2026-ban meghaladja a 850 milliárd dollárt, és 2027-re eléri az 1 billiót. Ennek 28–35%-a tiszta pazarlás.
- Az AI-munkaterhelések robbanásszerű növekedése. A GPU-alapú instanciák 5–10-szer több energiát fogyasztanak, mint a hagyományos számítási kapacitások, és az AI/ML költségkövetése még gyerekcipőben jár.
Ebben a cikkben átfogó képet adunk arról, hogyan építhető fel egy Green FinOps stratégia 2026-ban: a definícióktól a gyakorlati megvalósításon át a konkrét eszközökig és kódpéldákig. Szóval, vágjunk bele.
Mi az a Green FinOps? Definíció és kettős haszon
A Green FinOps a felhőpénzügyi menedzsment (FinOps) és a fenntartható számítástechnika (GreenOps) integrált megközelítése. Célja, hogy a felhőerőforrások optimalizálásakor egyidejűleg csökkentse a költségeket és a szénlábnyomot, felismerve, hogy e két cél természetszerűleg összehangolható.
A kettős haszon harmonizálása
A hagyományos FinOps-szemlélet kizárólag a költségcsökkentésre összpontosít: jobbméretezés, lefoglalt kapacitás, kihasználatlanság felszámolása. A Green FinOps ezekhez a gyakorlatokhoz hozzáadja a karbon-dimenziót:
- Jobbméretezés → kevesebb számítási kapacitás → kevesebb energia → kevesebb CO2
- Kihasználatlan erőforrások leállítása → nulla költség → nulla kibocsátás
- Régióválasztás → olcsóbb régiók gyakran több megújuló energiát használnak
- Munkaterhelések ütemezése → olcsóbb időszakok gyakran egybeesnek a megújuló energia csúcsidejével
A kulcsfontosságú felismerés: a felhőpazarlás nem csak pénzt éget el, hanem szenet is. Minden feleslegesen futó szerver, minden túlméretezett instancia és minden elfeledett erőforrás felesleges szén-dioxidot termel.
A Scope 3 kibocsátási probléma
A vállalati szén-dioxid-kibocsátás három kategóriára oszlik:
- Scope 1: Közvetlen kibocsátás (pl. vállalati járművek, helyi fűtés)
- Scope 2: Közvetett kibocsátás a megvásárolt energiából
- Scope 3: Minden egyéb közvetett kibocsátás az értékláncban
A nagy vállalatok esetén a Scope 3 kibocsátás a teljes kibocsátás 80–97%-át teszi ki. És ezen belül a felhőszámítástechnika használata egyre jelentősebb tétel. Amikor egy vállalat AWS-en, Azure-on vagy Google Cloud-on futtatja a munkaterheléseit, a felhőszolgáltató adatközpontjainak energiafogyasztása a vállalat Scope 3 kibocsátásaként jelenik meg.
Ez konkrétan azt jelenti, hogy a felhőoptimalizálás közvetlenül csökkenti a vállalat jelentendő szénlábnyomát. Nem egy elméleti összefüggés — valódi, mérhető hatás.
Számok, amelyek számítanak: 2026-os statisztikák
A Green FinOps szükségességét néhány kiemelkedő statisztika támasztja alá:
- Globális felhőköltés 2026-ban: Az IDC és Gartner előrejelzései szerint a nyilvános felhőszolgáltatásokra fordított összeg megközelíti, majd 2027-re meghaladja az 1 billió (1 000 milliárd) US dollárt. A 2025-ös 723 milliárd dollárról ~20%-os növekedést prognosztizálnak.
- Felhőpazarlás mértéke: Az iparági kutatások szerint a vállalatok átlagosan 28–35%-ot pazarolnak felhőköltségükből — kihasználatlan erőforrások, túlméretezett instanciák és rossz konfiguráció miatt. Formális FinOps programmal ez 20–25%-ra csökkenthető; anélkül akár 40% is lehet.
- Jobbméretezés hatása: Rendszeres jobbméretezési gyakorlatokkal 25–40%-os költség- és szénlábnyom-csökkenés érhető el, pusztán az erőforrások valós használatához igazításával.
- AI/ML költségkövetés: A FinOps Foundation 2025-ös felmérése szerint a szervezetek 63%-a már követi az AI/ML költségeit — szemben a 2024-es 31%-kal. Ez rohamos növekedést mutat, de a legtöbb szervezet még mindig az alapvető láthatóságnál tart, nem az optimalizálásnál.
- Tétlenül álló erőforrások: A havi számlák 10–15%-át az üresen futó instanciák, el nem ért tárolási kötetek és használaton kívüli IP-címek teszik ki. További 10–12%-ot adnak hozzá a túlméretezett számítási kapacitások.
Gondoljunk bele: Ha a teljes felhőköltés megközelíti az 1 billió dollárt, és ennek 30%-a pazarlás, az évi ~300 milliárd dollárnyi felesleges költség — és az ehhez tartozó szénlábnyom is megtakarítható lenne. Ez nem kis összeg.
Karbon-tudatos számítástechnika: hogyan működik a gyakorlatban
A karbon-tudatos számítástechnika (carbon-aware computing) lényege, hogy a számítási munkaterheléseket úgy ütemezzük és helyezzük el, hogy maximalizáljuk a megújuló energia kihasználását és minimalizáljuk a fosszilis energiahasználatot.
Időalapú eltolás (temporal shifting)
Nem minden munkaterhelést kell azonnal végrehajtani. A batch-feldolgozások, AI-modell-tanítás, adatcsomagolási feladatok, ETL-pipeline-ok és CI/CD-építések rugalmasan ütemezhetőek. Ha ezeket a feladatokat a megújuló energia csúcsidejére (nappal napelemek, szeles időszakok) ütemezzük, jelentősen csökkenthető a karbonintenzitás.
Például Európában a napelemek teljesítménye délután 12–15 óra között éri el a csúcsát. Ha a nehéz batch-munkaterheléseket erre az időszakra ütemezzük, a villamos hálózat karbonintenzitása alacsonyabb, tehát a számítási munkánk kevesebb szén-dioxidot termel. Logikus, nem?
Területi eltolás (spatial shifting)
Különböző felhőrégiók radikálisan eltérő karbonintenzitással rendelkeznek. Egy Skandináviában (vízenergia) vagy Franciaországban (atomenergia) lévő régió sokkal alacsonyabb karbonintenzitású, mint egy szénipar-függő régió.
A területi eltolás lényege: a munkaterhelést odairányítjuk, ahol éppen a legtisztább az energia.
Intelligens VM-elhelyezés és megújuló energia kihasználás
Tudományos kutatások igazolták, hogy intelligens VM-elhelyezési algoritmusokkal a megújuló energia kihasználás 73,11%-os javulása érhető el a hagyományos elhelyezéshez képest, miközben az SLA-sértés mértéke mindössze 0,2% marad. Ez a megközelítés elosztott felhős adatközpontokban kombinálja a terhelés-kiegyenlítést a megújuló energia előrejelzésekkel.
Szép eredmény, nem igaz?
A karbonintenzitás mérőszámai
A karbonintenzitást általában gCO2eq/kWh (gramm szén-dioxid-egyenérték per kilowattóra) mértékegységben mérik. A WattTime API által biztosított MOER (Marginal Operating Emissions Rate) érték azt mutatja, hogy a hálózatba éppen belépő következő energiaegység mennyi szén-dioxidot termel. Ez a marginális számítás pontosabban tükrözi az egyes döntések valódi hatását, mint az átlagos karbonintenzitás.
Felhőszolgáltatói eszközök a szénlábnyom mérésére
AWS Customer Carbon Footprint Tool
Az Amazon Web Services 2025 októbere óta kibővítette a Customer Carbon Footprint Tool-t (CCFT) a Scope 3 kibocsátási adatokkal. Ez azt jelenti, hogy az ügyfelek már nem csak az energiafogyasztásból eredő kibocsátást (Scope 2) látják, hanem a hardvergyártás, épületek, berendezések és szállítás közvetett kibocsátását is.
A legfontosabb funkciók:
- Scope 1, 2 és 3 kibocsátási adatok — 2022 januárjáig visszamenőleges adatokkal
- Regionális bontású adatok — láthatjuk, hogy melyik AWS-régió mennyi kibocsátást generál
- Helyi és piaci alapú számítási módszer (location-based és market-based) — mindkettő elérhető a pontosabb jelentés érdekében
- 2026-os frissítés: A hardver életciklus-végi kezelése (end-of-life) adatokat is beépítették a modellbe
Az eszköz a Billing console-on keresztül érhető el, és lehetővé teszi a felhőhasználati szénlábnyom integrálását a vállalati ESG-jelentésekbe.
Google Cloud Carbon Footprint
A Google Cloud Carbon Footprint eszköz az egyik legrészletesebb megoldás a felhőkibocsátások mérésére:
- Bontás projekt, régió és termék szintjén — pontosan láthatjuk, melyik projekt és melyik szolgáltatás mennyi szén-dioxidot termel
- BigQuery export — a karbon-adatokat közvetlenül BigQuery-be exportálhatjuk, ahol tetszőleges analízist, egyedi dashboardot vagy automatizált riportot építhetünk rá
- Automatikus havi frissítés — minden hónap 15-én automatikusan exportálódnak az előző havi adatok
- Carbon model v14 (2025 július) — frissített Scope 1 és Scope 3 kibocsátási tényezők a legújabb Google környezeti jelentés alapján
- 2026 februári metodológia-frissítés — tovább finomodott számítási módszer
A BigQuery export különösen értékes, mert lehetővé teszi az egyedi Green FinOps dashboardok felépítését és a karbon-adatok integrálását a meglévő FinOps-eszközökbe.
Azure Emissions Impact Dashboard
A Microsoft Azure Emissions Impact Dashboard a Power BI platform tetejére épül, és a következő képességeket kínálja:
- Kibocsátás mérése hónapok, szolgáltatások és adatközpont-régiók szerint
- Scope 3 kibocsátás számítása a Microsoft-felhőhasználat teljes értékláncára
- Migrációs becslés: a még nem migrált munkaterhelések adatainak megadásával megbecsülhető a migráció által elérhető kibocsátás-megtakarítás
- Integráció a Microsoft Cloud for Sustainability API-val
- Granuláris karbon-attribútum minden egyes Azure-erőforráshoz és előfizetéshez
Cloud Carbon Footprint — nyílt forráskódú, felhőszolgáltatókon átívelő eszköz
A Cloud Carbon Footprint (CCF) egy nyílt forráskódú eszköz, amelyet a Thoughtworks fejlesztett ki, és amely egységes módszertannal méri az AWS, Google Cloud és Azure kibocsátásait. Előnyei:
- Több felhőszolgáltatón átívelő kép — konzisztens mérési módszer minden platformra
- Átlátható metodológia — nyílt forráskódú, auditálható számítási modell
- Számítási, tárolási és hálózati kibocsátás — lefedi a fogyasztás minden dimenzióját
- Optimalizációs javaslatok — nem csak mér, hanem konkrét csökkentési javaslatokat is tesz
Fontos megjegyzés: 2025 végén a projekt aktivitása lelassult, de a közösség és a metodológia továbbra is értékes alapot nyújt a saját mérési framework kiépítéséhez.
Gyakorlati megvalósítási stratégiák
1. Jobbméretezés: a költség- és karboncsökkentés leghatékonyabb módja
A jobbméretezés (rightsizing) a legegyszerűbb és leghatékonyabb módszer mind a költségek, mind a szénlábnyom csökkentésére. A lényege: a virtuális gépek, konténerek és adatbázisok méretének igazítása a valós használati mintákhoz.
A tipikus vállalati környezetben a CPU-kihasználás átlagosan 20–30% körül mozog. Ez azt jelenti, hogy a kapacitás 70–80%-a feleslegesen van kiosztva — és feleslegesen fogyaszt energiát. (Igen, ez elég sok pazarlás.)
Gyakorlati lépések:
- Gyűjtsünk legalább 14 napnyi erőforrás-kihasználtsági adatot (CPU, memória, hálózat, lemez I/O)
- Használjunk automatizált jobbméretezési javaslatokat (AWS Compute Optimizer, Google Cloud Recommender, Azure Advisor)
- Vezessünk be folyamatos jobbméretezési ciklust: heti automatikus elemzés, havi felülvizsgálat, negyedéves stratégiai áttekintés
- Mérjük a hatást dollárban és CO2-ban is
2. Tétlenül álló erőforrások felszámolása
A tétlenül álló erőforrások a legkönnyebben megtakarítható tétel. Tipikus példák:
- Fejlesztői és tesztkörnyezetek, amelyek éjjel-nappal futnak, holott csak munkaidőben kellene (havi 730 órából csak 200-at használnak)
- Árva (orphaned) tárolási kötetek, amelyek már egyetlen instanciához sem kapcsolódnak
- Használaton kívüli Elastic IP-címek, amelyekért az AWS díjat számít
- Régi pillanatfelvételek (snapshots), amelyekből soha nem lesz visszaállítás
- Elfeledett load balancerek, amelyek mögött már nincs élő szerver
Egyszerű automatizációval (pl. Lambda-függvények, amelyek éjjel leállítják a fejlesztői környezeteket) 60–70%-os megtakarítás érhető el ezeken a környezeteken, a szénlábnyom arányos csökkenésével együtt.
3. Karbon-tudatos Kubernetes-ütemezés
A Kubernetes orkesztrációs környezet alkalmas arra, hogy karbon-tudatos döntéseket hozzon a munkaterhelések elhelyezésekor. Ennek kulcseleme a Green Software Foundation Carbon Aware SDK-ja és a WattTime API.
A megközelítés lényege:
- A WattTime API megadja a MOER (Marginal Operating Emissions Rate) értéket minden egyes villamos hálózati régió számára
- A Carbon Aware SDK ezt az adatot egy egységes WebAPI-n keresztül teszi elérhetővé
- A Kubernetes scheduler (vagy KEDA-alapú autoscaler) ez alapján dönti el, mikor és hol futtassa a munkaterhelést
Két fő stratégia:
- Temporális eltolás: A nem időkritikus munkaterheléseket (batch, AI-tanítás, CI/CD) akkor futtatjuk, amikor a hálózat karbonintenzitása a legalacsonyabb
- Szpációlis eltolás: A munkaterhelést abba a Kubernetes-clusterbe vagy régióba irányítjuk, ahol a hálózat éppen a legtisztább
4. Régióválasztás karbonintenzitás alapján
A felhős régiók karbonintenzitása több nagyságrenddel is eltérhet. Néhány példa:
- AWS eu-north-1 (Stockholm): Svédország villamos energiájának ~98%-a megújuló vagy atomenergia → nagyon alacsony karbonintenzitás
- AWS eu-central-1 (Frankfurt): Németország még jelentős szénenergia-függőséggel rendelkezik → magasabb karbonintenzitás
- GCP us-central1 (Iowa): A Google szélenergia-beruházásai miatt viszonylag alacsony karbonintenzitás
- Azure West US (Washington): Jelentős vízenergia-kapacitás → tisztább energia
A régióválasztás nem csak a karbon szempontjából fontos: az alacsony karbonintenzitású régiók gyakran olcsóbbak is, mert a megújuló energia többlet-ellátást teremt. Ez a Green FinOps kettős haszna a gyakorlatban — és talán a legmeggyőzőbb érv a menedzsment számára.
A FinOps Foundation fenntarthatósági érettségi modellje
A FinOps Foundation a Crawl/Walk/Run (Mászás/Járás/Futás) érettségi modellt alkalmazza, amelyet a fenntarthatóságra is kiterjesztett. Ez a modell segít a szervezeteknek megérteni, hol tartanak, és mi a következő lépés.
Crawl (Mászás) — alapvető láthatóság
- A felhőkibocsátási adatok első láthatóvá tétele a felhőszolgáltatói eszközök segítségével
- Alapvető riportok elkészítése a teljes kibocsátásról
- A FinOps és a fenntarthatósági csapatok első találkozója és közös nyelv kialakítása
- A felhőköltség- és karboncsökkentés közös előnyeinek felismerése
- Az eszközök beállítása: AWS CCFT, Google Carbon Footprint, Azure Emissions Dashboard
Walk (Járás) — aktív optimalizálás
- Karbon-metrika integrálása a meglévő FinOps dashboardokba és riportokba
- Régióválasztási irányelvek kidolgozása karbonintenzitás alapján
- Jobbméretezési és erőforrás-tisztítási kampányok indítása karbon-hatással
- Csapat-szintű karbon-mutatószámok bevezetése a költség-mutatószámok mellé
- Automatizált riportok és riasztások beállítása a karbonintenzitás-küszöbre reagálva
Run (Futás) — teljes körben automatizált, karbon-tudatos működés
- Automatizált karbon-tudatos ütemezés — a rendszer automatikusan a legalacsonyabb karbonintenzitású időszakokra és régiókra irányítja a munkaterhelést
- Karbon-költségvetés (carbon budget) bevezetése csapat- és projekt-szinten
- Unit economics integráció: minden tranzakcióra, felhasználói kérésre és API-hívásra költség- és karbonköltséget rendelünk
- ESG-jelentés automatikus generálása a felhős karbon-adatokból
- A szénlábnyom-csökkentés beépítése a fejlesztői KPI-kba és a csapatcélok közé
Egységgazdaságtan-integráció: költség ÉS karbon tranzakciónként
A Green FinOps egyik legfontosabb érettségi mutatója, amikor a szervezet képes egységgazdaságtani szinten mérni a költségeket és a karbonkibocsátást. Ez azt jelenti, hogy nem csak a teljes havi felhőszámlát nézzük, hanem megértjük:
- Mennyibe kerül egy felhasználói kérés (dollárban és gCO2eq-ban)?
- Mennyibe kerül egy tranzakció a webshopban?
- Mennyibe kerül egy API-hívás a partnereinknek?
- Mennyibe kerül egy AI-inference kérés?
Ezt a megközelítést unit economics-nek nevezzük, és két dimenzióba bővítjük:
- Cost per unit: Dollárköltség per tranzakció / per felhasználó / per kérés
- Carbon per unit: gCO2eq per tranzakció / per felhasználó / per kérés
A unit economics integráció lehetővé teszi, hogy:
- Felismerjük a karbon-intenzív üzleti folyamatokat és célzottan optimalizáljuk őket
- Összehasonlítsuk a különböző szolgáltatások karbon-hatékonyságát
- Reális karbon-költségvetést állítsunk fel és kövessük azt
- Az üzleti növekedést a szénlábnyom növekedésétől szétválasszuk (decoupling)
Példa: Egy e-kereskedelmi platform megtudja, hogy átlagosan egy vásárlási tranzakció 0,8 cent költség és 0,12 gCO2eq kibocsátás. Ezt a számot aztán optimalizálják — ha egy architektúrális változás után 0,5 centre és 0,08 gCO2eq-ra csökkent, az mind pénzügyi, mind karbon-szempontból mérhető javulás.
AI-munkaterhelések: a GPU-korszak különleges kihívásai
Az AI és a gépi tanulás (ML) munkaterhelések különleges kihívást jelentenek a Green FinOps számára, és 2026-ban ez az egyik legaktuálisabb téma. Beszéljünk róla őszintén.
Miért más az AI?
- A GPU-instanciák költsége 5–10-szerese a hagyományos CPU-alapú instanciáknak. Egy p5.48xlarge (NVIDIA H100) instancia listaára kb. $98/óra — szemben egy hasonló CPU-instancia $5–10/óra árával.
- Az energiafogyasztás arányosan magasabb. Egy NVIDIA H100 GPU 700W csúcsteljesítményt vesz fel — egyetlen GPU-szerver akár 10 kW-ot is fogyaszthat.
- A tanítás napokig vagy hetekig tart. Egy nagy nyelvi modell (LLM) tanítása hetekig futhat százas nagyságrendű GPU-kon, aminek összesített energiafogyasztása és szénlábnyoma gigantikus.
- Az inferencia folyamatos és növekvő. Ahogy egyre több alkalmazás használ AI-t, az inferencia-költség és -kibocsátás exponenciálisan nő.
AI-specifikus Green FinOps stratégiák
- Tanítási ütemezés karbontudatos módon: Az AI-modell tanítás tipikusan rugalmasan ütemezhető — kiválóan alkalmas a temporális eltolásra. A tanítást úgy ütemezzük, hogy a megújuló energia csúcsidején fusson.
- Modell-optimalizálás: A kvantálás (quantization), pruning (ritkítás) és a FlashAttention-féle algoritmikus javítások 50–75%-kal csökkenthetik az energiaszükségletet a modellek pontosságának minimális romlása mellett.
- Spot/preemptible instanciák: A GPU-spot instanciák 60–90%-kal olcsóbbak és ugyanannyi karbont termelnek, tehát a Green FinOps szempontjából is ideálisak — ha a munkaterhelés képes kezelni a megszakításokat.
- Inferencia optimalizálása: Modell-serving frameworkök (vLLM, TensorRT-LLM) használata a GPU-kihasználás maximalizálására, ezzel csökkentve a szükséges instanciák számát.
- AI-költség és karbon láthatósága: Különítsük el az AI-munkaterhelések költségeit és kibocsátását a hagyományos munkaterhelésektől. Használjunk dedikált tag-eket, névtereket és költségcsoportokat.
Gyakorlati kódpéldák
Terraform konfiguráció karbon-tudatos régióválasztáshoz
Az alábbi Terraform példa bemutatja, hogyan válasszuk ki automatikusan az alacsonyabb karbonintenzitású AWS-régiót a munkaterheinkhez. A példában egy egyszerű karbon-intenzitás térképet használunk, és a legalacsonyabb értékű régiót választjuk:
# green-finops-region-selection/main.tf
# Karbon-intenzitás térkép (gCO2eq/kWh) az AWS régiókhoz
# Forrás: WattTime, ElectricityMaps, 2026 Q1 adatok
variable "carbon_intensity_map" {
type = map(number)
default = {
"eu-north-1" = 8 # Stockholm - vízenergia + szélenergia
"eu-west-1" = 295 # Írország - vegyes
"eu-central-1" = 338 # Frankfurt - szénenergia
"us-west-2" = 78 # Oregon - vízenergia
"us-east-1" = 379 # Virginia - vegyes
"ap-southeast-2" = 530 # Sydney - szénenergia
"ca-central-1" = 26 # Kanada - vízenergia
}
}
# Engedélyezett régiók listája (latencia és compliance alapján)
variable "allowed_regions" {
type = list(string)
default = ["eu-north-1", "eu-west-1", "eu-central-1", "ca-central-1"]
}
# A legalacsonyabb karbon-intenzitású régió kiválasztása
# az engedélyezett régiók közül
locals {
# Szűrjük az engedélyezett régiókra
allowed_carbon = {
for region, intensity in var.carbon_intensity_map :
region => intensity
if contains(var.allowed_regions, region)
}
# Kiválasztjuk a legalacsonyabb intenzitásút
sorted_regions = sort([
for region, intensity in local.allowed_carbon :
"${format("%04d", intensity)}_${region}"
])
# A legalacsonyabb karbon-intenzitású régió
greenest_region = split("_", local.sorted_regions[0])[1]
}
provider "aws" {
region = local.greenest_region
}
# Példa: EC2 instancia a legzöldebb régióban
resource "aws_instance" "green_workload" {
ami = data.aws_ami.latest_amazon_linux.id
instance_type = "m7g.large" # Graviton - 60%-kal energiahatékonyabb
tags = {
Name = "green-finops-workload"
CarbonIntensity = var.carbon_intensity_map[local.greenest_region]
SelectedRegion = local.greenest_region
OptimizationGoal = "low-carbon"
ManagedBy = "green-finops-terraform"
}
}
data "aws_ami" "latest_amazon_linux" {
most_recent = true
owners = ["amazon"]
filter {
name = "name"
values = ["al2023-ami-*-arm64"] # ARM (Graviton) AMI
}
}
output "selected_region" {
value = local.greenest_region
description = "A legalacsonyabb karbon-intenzitású régiót választottuk"
}
output "carbon_intensity" {
value = var.carbon_intensity_map[local.greenest_region]
description = "A kiválasztott régió karbonintenzitása (gCO2eq/kWh)"
}Figyeljük meg a Graviton (ARM) instancia használatát: a Graviton processzorok akár 60%-kal kevesebb energiát fogyasztanak az azonos teljesítményű x86 instanciákhoz képest, ami mind költség-, mind karbon-előnyt jelent.
Python script: WattTime API lekérdezése karbonintenzitás-adatokhoz
Az alábbi Python példa bemutatja, hogyan kérdezhetjük le a WattTime API-t, hogy valós idejű karbonintenzitási adatokat kapjunk, és ez alapján döntsünk a munkaterhelés futtatásának időpontjáról:
"""
Green FinOps: WattTime API karbon-intenzitás lekérdező
A script valós idejű karbonintenzitás-adatokat kér le,
és javasolja az optimális futtatási időpontot.
"""
import requests
import json
from datetime import datetime, timedelta, timezone
from typing import Optional
class CarbonIntensityMonitor:
"""WattTime API kliens a karbonintenzitás mérésére."""
BASE_URL = "https://api.watttime.org"
def __init__(self, username: str, password: str):
self.username = username
self.password = password
self.token: Optional[str] = None
def authenticate(self) -> None:
"""Bejelentkezés a WattTime API-ba és token lekérése."""
response = requests.get(
f"{self.BASE_URL}/login",
auth=(self.username, self.password)
)
response.raise_for_status()
self.token = response.json().get("token")
print(f"[OK] Sikeres azonosítás a WattTime API-ban.")
def get_current_intensity(self, region: str) -> dict:
"""
Aktuális karbonintenzitás lekérése egy adott hálózati régióhoz.
A MOER (Marginal Operating Emissions Rate) értéket adja vissza.
"""
headers = {"Authorization": f"Bearer {self.token}"}
params = {"region": region, "signal_type": "co2_moer"}
response = requests.get(
f"{self.BASE_URL}/v3/signal-index",
headers=headers,
params=params
)
response.raise_for_status()
return response.json()
def get_forecast(self, region: str, hours_ahead: int = 24) -> list:
"""
Karbonintenzitás-előrejelzés lekérése a következő X órára.
Ez az adat hasznos a temporális eltolás tervezéséhez.
"""
headers = {"Authorization": f"Bearer {self.token}"}
params = {
"region": region,
"signal_type": "co2_moer",
"horizon_hours": hours_ahead
}
response = requests.get(
f"{self.BASE_URL}/v3/forecast",
headers=headers,
params=params
)
response.raise_for_status()
return response.json().get("data", [])
def find_optimal_window(
self,
region: str,
duration_hours: int = 4,
lookahead_hours: int = 24
) -> dict:
"""
Megkeresi az optimális (legalacsonyabb karbonintenzitású)
időablakot egy adott munkaterhelés futtatásához.
Args:
region: WattTime hálózati régió azonosító
duration_hours: A munkaterhelés becsült futási ideje órában
lookahead_hours: Hány órán belül keresünk ablakot
Returns:
dict az optimális kezdési időponttal és az átlagos MOER-rel
"""
forecast = self.get_forecast(region, lookahead_hours)
if not forecast:
return {"error": "Nincs elérhető előrejelzési adat."}
# Gördülő ablak: keressük a legkisebb átlagú időszakot
best_start = None
best_avg_moer = float("inf")
window_size = duration_hours * 12 # 5 perces intervallumonként
for i in range(len(forecast) - window_size + 1):
window = forecast[i:i + window_size]
avg_moer = sum(d["value"] for d in window) / len(window)
if avg_moer < best_avg_moer:
best_avg_moer = avg_moer
best_start = window[0]["point_time"]
return {
"optimalis_kezdes": best_start,
"atlagos_moer": round(best_avg_moer, 2),
"idotartam_ora": duration_hours,
"regio": region,
"csokkendes_szazalek": self._calculate_savings(
forecast, best_avg_moer
)
}
def _calculate_savings(self, forecast: list, best_moer: float) -> float:
"""Kiszámítja a megtakarítást az azonnali futtatáshoz képest."""
current_moer = forecast[0]["value"] if forecast else best_moer
if current_moer == 0:
return 0.0
savings = ((current_moer - best_moer) / current_moer) * 100
return round(max(0, savings), 1)
# --- Használati példa ---
def main():
# WattTime fiók adatai (regisztráció: https://watttime.org)
monitor = CarbonIntensityMonitor(
username="az_on_felhasznaloneve",
password="az_on_jelszava"
)
# Azonosítás
monitor.authenticate()
# Példák különböző régiókra
regions = {
"CAISO_NORTH": "Kalifornia (Észak)",
"PJM_DC": "Virginia / Washington DC",
"SE": "Svédország",
"DE": "Németország"
}
print("\n--- Aktuális karbonintenzitás régiónként ---")
for region_code, region_name in regions.items():
try:
intensity = monitor.get_current_intensity(region_code)
print(
f" {region_name} ({region_code}): "
f"MOER index = {intensity.get('data', [{}])[0].get('value', 'N/A')}"
)
except Exception as e:
print(f" {region_name}: Hiba - {e}")
# Optimális futtatás kiszámítása egy 4 órás batch munkaterheléshez
print("\n--- Optimális futtatási idő (4 órás batch munkaterhelés) ---")
result = monitor.find_optimal_window(
region="PJM_DC",
duration_hours=4,
lookahead_hours=24
)
print(f" Optimális kezdési időpont: {result.get('optimalis_kezdes')}")
print(f" Átlagos MOER az ablakban: {result.get('atlagos_moer')}")
print(
f" Becsült karbon-megtakarítás: "
f"{result.get('csokkendes_szazalek')}% az azonnalihoz képest"
)
if __name__ == "__main__":
main()Ez a script valós időben lekérdi a karbonintenzitást, majd megkeresi az optimális futtatási időablakot egy batch munkaterheléshez. Az eredményt integrálhatjuk CI/CD pipeline-okba, cron ütemezőbe vagy Kubernetes CronJob-okba.
Kubernetes karbon-tudatos ütemező konfiguráció (YAML)
Az alábbi konfiguráció bemutatja, hogyan állíthatunk be karbon-tudatos ütemezést egy Kubernetes-klaszterben a Green Software Foundation Carbon Aware SDK-val és KEDA-val (Kubernetes Event-Driven Autoscaling):
# carbon-aware-scheduler-config.yaml
# Green FinOps: Karbon-tudatos Kubernetes ütemező konfiguráció
---
# 1. Carbon Aware SDK telepítése (Deployment)
apiVersion: apps/v1
kind: Deployment
metadata:
name: carbon-aware-sdk
namespace: green-finops
labels:
app: carbon-aware-sdk
purpose: carbon-intensity-data
spec:
replicas: 2
selector:
matchLabels:
app: carbon-aware-sdk
template:
metadata:
labels:
app: carbon-aware-sdk
spec:
containers:
- name: carbon-aware-sdk
image: ghcr.io/green-software-foundation/carbon-aware-sdk:latest
ports:
- containerPort: 8080
env:
- name: CarbonAwareVars__CarbonIntensityDataSource
value: "WattTime"
- name: WattTimeClient__Username
valueFrom:
secretKeyRef:
name: watttime-credentials
key: username
- name: WattTimeClient__Password
valueFrom:
secretKeyRef:
name: watttime-credentials
key: password
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "250m"
memory: "256Mi"
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 10
periodSeconds: 30
---
# 2. Carbon Aware SDK Service
apiVersion: v1
kind: Service
metadata:
name: carbon-aware-sdk-svc
namespace: green-finops
spec:
selector:
app: carbon-aware-sdk
ports:
- port: 80
targetPort: 8080
type: ClusterIP
---
# 3. KEDA ScaledJob - karbon-tudatos batch munkaterhelés
# A munkaterhelés csak akkor indul el, ha a karbonintenzitás
# a küszöb érték alá esik
apiVersion: keda.sh/v1alpha1
kind: ScaledJob
metadata:
name: carbon-aware-batch-job
namespace: green-finops
labels:
app: batch-processor
optimization: carbon-aware
spec:
jobTargetRef:
parallelism: 1
completions: 1
backoffLimit: 3
template:
metadata:
labels:
app: batch-processor
carbon-aware: "true"
annotations:
carbon-aware.greensoftware.foundation/priority: "low-carbon"
spec:
restartPolicy: OnFailure
nodeSelector:
# A legzöldebb node-pool-ra ütemezzük
node-pool: green-compute
tolerations:
- key: "carbon-optimized"
operator: "Equal"
value: "true"
effect: "NoSchedule"
containers:
- name: batch-processor
image: myregistry/batch-processor:latest
env:
- name: CARBON_AWARE_MODE
value: "enabled"
- name: PROCESSING_TYPE
value: "deferred-batch"
resources:
requests:
cpu: "2"
memory: "4Gi"
limits:
cpu: "4"
memory: "8Gi"
# KEDA trigger: külső metrika a Carbon Aware SDK-ból
triggers:
- type: metrics-api
metadata:
# A Carbon Aware SDK endpoint-ja
targetValue: "200" # gCO2eq/kWh küszöb érték
url: "http://carbon-aware-sdk-svc.green-finops.svc.cluster.local/emissions/current?location=westeurope"
valueLocation: "rating"
# Csak akkor indul a job, ha a karbonintenzitás
# 200 gCO2eq/kWh alá esik
minReplicaCount: 0 # Ha magas a karbon, 0 replika (vár)
maxReplicaCount: 5 # Maximum 5 párhuzamos job
pollingInterval: 300 # 5 percenként ellenőrzés
---
# 4. ConfigMap a karbon-küszöbértékekhez
apiVersion: v1
kind: ConfigMap
metadata:
name: carbon-thresholds
namespace: green-finops
data:
# Karbonintenzitás küszöbök különböző prioritásokhoz
threshold-critical: "1000" # Kritikus: mindig fut, bármi a karbon
threshold-high: "500" # Magas: legfeljebb közepes karbon mellett fut
threshold-normal: "200" # Normál: csak alacsony karbon mellett fut
threshold-low: "50" # Alacsony: csak nagyon tiszta energia mellett fut
# Régió-preferencia sorrend (legzöldebbről)
preferred-regions: |
eu-north-1,ca-central-1,us-west-2,eu-west-1,us-east-1
---
# 5. CronJob a napi karbon-riporthoz
apiVersion: batch/v1
kind: CronJob
metadata:
name: daily-carbon-report
namespace: green-finops
spec:
schedule: "0 6 * * *" # Minden nap reggel 6-kor
jobTemplate:
spec:
template:
spec:
restartPolicy: OnFailure
containers:
- name: carbon-reporter
image: myregistry/carbon-reporter:latest
env:
- name: CARBON_SDK_URL
value: "http://carbon-aware-sdk-svc.green-finops.svc.cluster.local"
- name: REPORT_DESTINATION
value: "s3://green-finops-reports/daily/"
- name: SLACK_WEBHOOK
valueFrom:
secretKeyRef:
name: notification-config
key: slack-webhook
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"Ez a konfiguráció a következő elemeket tartalmazza:
- Carbon Aware SDK telepítés: A Green Software Foundation SDK-ja, amely a WattTime API-ból nyeri a valós idejű karbonintenzitás-adatokat
- KEDA ScaledJob: A batch munkaterhelés csak akkor indul el, ha a karbonintenzitás a meghatározott küszöb alá esik (200 gCO2eq/kWh). Ha magas a karbon, a munkaterhelés vár, amíg tisztább lesz az energia.
- Karbon-küszöbök: Különböző prioritási szintek, amelyek lehetővé teszik, hogy a kritikus munkaterhelések mindig fussanak, de az alacsony prioritásúak csak tiszta energia mellett induljanak.
- Napi riport: Automatikus karbon-jelentés generálása és kiküldése Slack-en és S3-ra.
Integrált Green FinOps dashboard: amit mérnie kell
Egy hatékony Green FinOps dashboard a következő metrikákat jeleníti meg együtt:
- Teljes havi felhőköltség (USD) és teljes havi kibocsátás (tCO2eq) egymás mellett
- Költség és karbon trendértékek idővonal-diagramon — így látható a kettős optimalizálás hatása
- Régiók szerinti bontás: melyik régió mennyit költ és mennyit bocsát ki
- Szolgáltatás-szintű kibocsátás: számítás, tárolás, hálózat, adatbázis külön-külön
- Csapat-szintű attribútum: melyik csapat vagy projekt hány dollárt és hány kg CO2-t termel
- Unit economics: költség/tranzakció és karbon/tranzakció trendek
- Pazarlási mutató: kihasználatlan erőforrások százaléka és azok becsült karbon-hatása
- AI-munkaterhelések külön szekciója: GPU-kihasználtság, AI-költség, AI-karbon
A Scope 3 jelentés gyakorlati megvalósítása
A Scope 3 felhőalapú kibocsátás jelentése 2026-ban már nem opcionális — sok szervezet számára szabályozási követelmény. Íme a gyakorlati lépések:
- Engedélyezzük a felhőszolgáltatói karbon-eszközöket: AWS CCFT, Google Carbon Footprint, Azure Emissions Dashboard — mindhárom ingyenes és automatikus.
- Exportáljuk az adatokat központi tárba: BigQuery (GCP), S3 + Athena (AWS), vagy Power BI (Azure) — itt tudjuk összevetni a három szolgáltató adatait.
- Harmonizáljuk a metodológiát: Döntsük el, hogy location-based vagy market-based számítási módszert használunk (vagy mindkettőt, ahogy az AWS CCFT engedi).
- Integráljuk a vállalati ESG-rendszerbe: Az adatokat az ESG-jelentési platformba (pl. Salesforce Net Zero Cloud, Persefoni, Watershed) toljuk.
- Állítsunk fel bázisértéket és célokat: Az első negyedév méréseit vegyük bázisnak, és határozzunk meg évi 10–20%-os csökkentési célt.
Cselekvési terv: hogyan indítsuk el a Green FinOps-ot
Összefoglalásként, íme egy 12 hetes cselekvési terv, amellyel bármely szervezet elindíthatja a Green FinOps útját:
1–2. hét: Láthatóság megteremtése
- Aktiváljuk az összes felhőszolgáltatói karbon-eszközt (AWS CCFT, Google Carbon Footprint, Azure Emissions Dashboard)
- Telepítsük a Cloud Carbon Footprint nyílt forráskódú eszközt, ha többfelhős környezetben dolgozunk
- Készítsük el az első bázis-jelentést: jelenlegi felhőköltség és jelenlegi szénlábnyom
3–4. hét: Gyors győzelmek (quick wins)
- Azonosítsuk és szüntessük meg a tétlenül álló erőforrásokat (árva kötetek, nem használt IP-címek, leállított de el nem távolított instanciák)
- Vezessük be az éjszakai/hétvégi automatikus leállítást a fejlesztői és tesztkörnyezetekben
- Becsüljük meg az első költség- és karbon-megtakarítást
5–8. hét: Rendszeres optimalizálás
- Indítsuk el a jobbméretezési programot: heti automatizált elemzés, havi akcióterv
- Integráljuk a karbon-metrikákat a meglévő FinOps dashboardokba
- Vizsgáljuk meg a régióválasztási lehetőségeket a karbonintenzitás alapján
- Vizsgáljuk meg az ARM (Graviton/Axion/Cobalt) instanciák bevezetését — akár 60%-kal energiahatékonyabbak
9–12. hét: Automatizálás és skálázás
- Vezessük be a karbon-tudatos ütemezést a nem időkritikus munkaterhelésekre (Carbon Aware SDK + KEDA)
- Építsük fel az unit economics rendszert — költség és karbon per tranzakció
- Határozzunk meg csapat-szintű karbon-költségvetést
- Készítsük elő az első ESG-integrációt az automatizált karbon-adatokkal
Összefoglalás: a költség- és karbonhatékonyság elválaszthatatlan
2026-ban a Green FinOps nem egy szép bónusz vagy egy PR-fogás — ez egy üzleti szükségesség. A szabályozási környezet, a felhőköltségek rohamos növekedése és az AI-munkaterhelések robbanásszerű terjedése egyaránt ebbe az irányba terelik a szervezeteket.
A jó hír az, hogy a felhőoptimalizálás és a szénlábnyom-csökkentés természetszerűleg összehangolható. Minden dollár, amit megtakarítunk a felhőpazarlás csökkentésével, egyúttal karbon-megtakarítást is jelent.
Az eszközök ma már léteznek: a felhőszolgáltatók beépített karbon-eszközei, a nyílt forráskódú mérési frameworkök, a karbon-tudatos ütemezési technológiák és a FinOps Foundation érettségi modellje mind rendelkezésre állnak.
Ami hiányzik a legtöbb szervezetnél, az nem a technológia, hanem az integrált szemlélet: a költség- és a fenntarthatósági csapatok összefogása, a karbon-metrikák beépítése a mindennapi döntésekbe, és a mérhetőség megteremtése egyszerre dollárban és szén-dioxidban.
Kezdjük el ma: mérjük meg, amit még nem mérünk, optimalizáljuk, amit már mérünk, és automatizáljuk, amit már tudunk optimalizálni. A felhőnk — és a bolygónk — meg fog köszönni.