Felhőköltség allokáció és tagging stratégia 2026: AWS, Azure, GCP többfiókos környezetekhez

Frissítve: 2026. június 24.

A felhőköltség allokáció az a folyamat, amelynek során minden egyes elköltött forintot vissza tudunk vezetni egy konkrét csapatra, termékre vagy üzleti egységre, és 2026-ban ezt egy szigorú tagging stratégia, hierarchikus számlastruktúra (AWS Organizations, Azure Management Groups, GCP Folders) és egy egységes export (CUR 2.0, Azure Cost Management Export, BigQuery billing export) együttese teszi lehetővé. Ebben az útmutatóban azt mutatom meg, ahogy én építem fel a multi-account, multi-region környezetek allokációs modelljét nulláról: a tag policy-któl a megosztott költségek szétosztásáig és a FOCUS 1.1 spec migrációig.

• A használható allokációhoz legalább 4 kötelező tag kell: cost-center, environment, product, owner. Minden más opcionális.
• A taget aktiválni kell a Billing konzolban (AWS), illetve engedélyezni az allokációs jelentésekben (Azure, GCP), különben nem jelenik meg a CUR-ban.
• A tag enforcement nem opcionális: SCP-k (AWS), Azure Policy deny hatások és GCP Organization Policy nélkül a fegyelem 6 hónap alatt elfolyik.
• Showback (informáljuk a csapatokat) szinte mindig jobb első lépés, mint chargeback (kiszámlázzuk nekik). A kultúrát építse, ne büntessen.
• A megosztott költségek (transit, monitoring, közös ESZ) szétosztásához proporcionális vagy egyenlő allokáció kell, dokumentált képlet alapján.
• A FOCUS 1.1 spec 2026 Q2-re elérhető mindhárom hyperscaleren, és érdemes az új report formátumra migrálni a saját BI pipeline-ban.

Miért bukik el a legtöbb tagging stratégia?

Őszintén szólva, az elmúlt nyolc évben kb. 40 szervezet allokációs modelljét vittem produktívba, és a kudarcoknak mindig ugyanaz a 3-4 oka van. Az első, hogy túl sok kötelező tag van. Láttam már 14 mezőből álló sablont, amit aztán senki sem tartott be. A második, hogy a tagek aktiválása lemarad a Billing oldalon: az erőforrásokon ott a tag, de a CUR-ban (Cost and Usage Report) nem jelenik meg, mert valaki elfelejtette a Billing konzolban bekapcsolni. A harmadik, hogy nincs enforcement. Ha új EC2 instancia indulhat cost-center nélkül, három hónap múlva az erőforrások 30-40%-a "untagged" lesz.

A negyedik, és tapasztalatom szerint a legsúlyosabb: nincs egységes nyelvi konvenció. Az egyik csapat CostCenter-t használ, a másik cost_center-t, a harmadik cc-t. A CUR betöltésekor ezek külön oszlopok lesznek, és a BI réteg nem tudja összevonni őket. Erre még a FOCUS spec sem ad megoldást, ezt nekünk kell már a kezdetekkor szabványosítani, és lowercase kebab-case-t javaslok, mert az AWS, Azure és GCP között is konzisztens marad.

A 4 kötelező tag, amit minden szervezetben bevezetek

A "minimum életképes tagging stratégia" mindössze négy mezőből áll. Ezt a négyet tedd kötelezővé, a többit hagyd opcionálisnak. Ha kényelmesen megy a négy, később bővítheted.

Tag kulcs	Példa érték	Miért kell	Allokációs cél
cost-center	cc-4815	Pénzügyi visszavezetés a GL-hez	Chargeback / showback
environment	prod, staging, dev	Dev/prod arány nyomon követése	Right-sizing célok
product	checkout-api	Termékenkénti P&L	Unit economics
owner	team-payments	Ki kapja az anomáliariasztást?	Felelősség

Az owner nem személy, hanem csapat-azonosító. Ha Anna távozik, ne kelljen 800 erőforrás tagjét átírni (ezt egyszer egy karácsony előtti hétvégén csináltam végig, soha többet). A cost-center-ben pedig ne legyen szabad szöveg: egy zárt listából (a pénzügyi rendszerből szinkronizálva) választható érték legyen, különben a CUR-ban elírások miatt 4000 különböző cost center jelenik meg, ami egy 50 fős szervezetnél matematikailag lehetetlen.

Hasznos opcionális tagek, amiket gyakran bevezetünk: data-classification (public/internal/pii), compliance (pci/hipaa/none), auto-stop (true/false a dev környezetekben az éjszakai leállításhoz), és created-by (a Terraform module neve, hogy IaC-ról vagy click-opsról beszélünk-e). Az automatizálási megfontolásokról bővebben írtam a felhőköltség-optimalizálás automatizálásáról szóló útmutatóban.

AWS cost allocation tagek és aktiválás

AWS-en a tagek létrehozása önmagában semmit nem ér, aktiválni kell őket cost allocation tagként a Billing konzolban (vagy CLI-vel). Ez az egyetlen lépés, amit a legtöbb csapat elfelejt. Egy korábbi projekten ezen pont egy negyedéves jelentés bukott meg, mert három hetet vártunk arra, hogy "miért nincs adat". A művelet a fizető (management) accountban végezhető:

# Cost allocation tag aktiválás CLI-ből (management account)
aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status \
  TagKey=cost-center,Status=Active \
  TagKey=environment,Status=Active \
  TagKey=product,Status=Active \
  TagKey=owner,Status=Active \
  --region us-east-1

# Ellenőrzés
aws ce list-cost-allocation-tags \
  --status Active \
  --region us-east-1 \
  --query 'CostAllocationTags[].TagKey'

Az aktiválás után 24 órát kell várni, mire a tag megjelenik a CUR-ban új oszlopként (resource_tags_user_cost_center stb.). Visszamenőlegesen nem tölti ki: csak az aktiválás után indított erőforrások adatai lesznek tagelve, ezért amint új taget vezetsz be, azonnal aktiváld.

Multi-account környezetben az AWS Organizations tag policy-t használjunk a megengedett kulcsok és értékek kikényszerítésére. Az alábbi tag policy például csak a 4 kötelező tagünket fogadja el, és előírja az environment zárt értéklistáját:

{
  "tags": {
    "cost-center": {
      "tag_key": { "@@assign": "cost-center" },
      "enforced_for": {
        "@@assign": [ "ec2:instance", "s3:bucket", "rds:db" ]
      }
    },
    "environment": {
      "tag_key": { "@@assign": "environment" },
      "tag_value": {
        "@@assign": [ "prod", "staging", "dev", "sandbox" ]
      },
      "enforced_for": {
        "@@assign": [ "ec2:instance", "s3:bucket", "rds:db" ]
      }
    }
  }
}

Részletes hivatkozásként az AWS hivatalos cost allocation tag dokumentációját érdemes használni. Itt naprakészen tartják, mely szolgáltatások támogatják a tageket (még mindig vannak olyanok, mint pl. a Data Transfer egy része, amit nem lehet tagelni; ezekről külön szólok a megosztott költségeknél).

Azure tag öröklés és Management Groups

Az Azure-on a tagging viselkedés más, mint AWS-en: az erőforráscsoport (Resource Group) tagjeit az erőforrások nem öröklik automatikusan. Ez egy klasszikus csapda, minden új cégnél ezzel kezdjük. A megoldás az Azure Policy inherit-tag beépített initiative, ami a Resource Group taget rárakja a benne lévő erőforrásokra:

// Bicep: inherit tag policy assignment a subscription szintjén
targetScope = 'subscription'

resource inheritCostCenter 'Microsoft.Authorization/policyAssignments@2024-04-01' = {
  name: 'inherit-cost-center'
  properties: {
    displayName: 'Inherit cost-center from resource group'
    policyDefinitionId: '/providers/Microsoft.Authorization/policyDefinitions/cd3aa116-8754-49c9-a813-ad46512ece54'
    parameters: {
      tagName: { value: 'cost-center' }
    }
  }
}

Ezt a 4 kötelező tagre mindenképp tedd be. A másik kulcsfontosságú lépés Azure-on a Management Group hierarchia, ami kb. annak felel meg, ami AWS-en az Organizations OU-fa. Én így szoktam felépíteni: a gyökér alatt platform, product, sandbox; a product alatt termékvonalanként egy MG; minden MG-ben egy-egy prod és nonprod subscription. Így a subscription-szinten van egy implicit allokáció (a subscription neve maga is azonosító), és a tagek ezen belül finomítják.

A Cost Management Export-ot napi szinten konfiguráld egy storage account-ba Parquet formátumban, mert a portál UI-jában 13 hónap múlva már nem fogod látni a régebbi adatokat. Az Azure tag dokumentáció részletezi a korlátokat. Figyelj a tag kulcsok 512 karakteres limitjére és a 50 tag/erőforrás maximumra.

GCP labels és billing export BigQuery-be

A GCP-n nem tageknek, hanem labeleknek hívják, és a megengedett karakterkészlet szigorúbb: csak [a-z0-9_-], kis betűkkel, max 63 karakter. Emiatt a kebab-case-em (cost-center) tökéletesen működik mindhárom felhőn. Ha CamelCase-t használnál, GCP-n nem érvényes.

A költségadatok GCP-n a BigQuery billing exporton át érkeznek. Először engedélyezni kell a billing accounton (Billing → Billing export → BigQuery export), majd a labelek külön mezőként jelennek meg az labels oszlopban (ARRAY<STRUCT>). Egy egyszerű cost-center allokációs lekérdezés:

-- Havi költség cost-center szerint, GCP BigQuery billing export
SELECT
  (SELECT value FROM UNNEST(labels) WHERE key = 'cost-center') AS cost_center,
  service.description AS service,
  FORMAT_DATE('%Y-%m', DATE(usage_start_time)) AS month,
  ROUND(SUM(cost), 2) AS cost_usd,
  ROUND(SUM(IFNULL((SELECT SUM(amount)
                    FROM UNNEST(credits)), 0)), 2) AS credits_usd,
  ROUND(SUM(cost) + SUM(IFNULL((SELECT SUM(amount)
                                FROM UNNEST(credits)), 0)), 2) AS net_cost_usd
FROM `your-billing-project.billing_export.gcp_billing_export_v1_XXXXXX`
WHERE _PARTITIONTIME >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 90 DAY)
GROUP BY cost_center, service, month
ORDER BY month DESC, net_cost_usd DESC;

Két részlet, amibe sokan beleesnek: (1) a credits mezőt mindig vond le, különben a sustained use és committed use kedvezmények nélküli "rack rate" árat látod; (2) a _PARTITIONTIME-mal mindig korlátozd a beolvasást, mert a billing export tábla több TB lehet, és a slot consumption komoly. Az allokációs modellt érdemes egy materialized view-ba menteni napi frissítéssel, így a downstream BI dashboardok másodperc alatt válaszolnak. A részletes szintaxis és sémadefiníció megtalálható a Google Cloud Billing export hivatalos referenciájában.

Hogyan kényszerítsük ki a tagelést SCP-vel és Policy-val?

Az enforcement az allokációs modell alapköve. Két filozófia van: prevent (eleve nem indul el erőforrás tag nélkül) vagy detect & remediate (elindulhat, de egy automatizáció vagy tagsource alapján taget kap, vagy 24 óra múlva leáll). Én a prevent-et javaslom prod környezetre, és a detect-et sandbox/dev-re, különben a fejlesztők számára olyan súrlódást okozol, hogy megkerülnek.

AWS-en SCP-vel tudod prevent-tel kikényszeríteni az EC2 instancia indítás idején:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyRunInstancesWithoutCostCenter",
    "Effect": "Deny",
    "Action": "ec2:RunInstances",
    "Resource": "arn:aws:ec2:*:*:instance/*",
    "Condition": {
      "Null": {
        "aws:RequestTag/cost-center": "true"
      }
    }
  }]
}

Azure-on ugyanezt az Azure Policy deny hatásával oldjuk meg, GCP-n pedig az Organization Policy szolgáltatáson belüli constraints/gcp.resourceLocations-szerű constraintekkel (a label-enforcement GCP-n máig gyengébb, mint a másik két felhőn; szabálymotor helyett gyakran Cloud Function alapú remediate-re kényszerülünk).

Showback vs chargeback: melyiket válassza?

A showback és a chargeback a két visszacsatolási modell. Showback esetén egy dashboard megmutatja minden csapatnak, mennyit költ, de a számla nem érkezik meg hozzá belső kontírozással. Chargeback esetén a pénzügy a havi zárlatnál ténylegesen ráterheli az adott cost centerre a felhőszámla rá eső részét. A különbség kulturális és pénzügyi, nem technikai.

Szempont	Showback	Chargeback
Pénzügyi hatás	Nincs	Cost center terhelve
Csapatok motivációja	Mérsékelt	Erős
Bevezetés bonyolultsága	1-2 hónap	4-6 hónap (GL integráció)
Tagging fegyelem igénye	Közepes	Magas (auditálható)
Politikai kockázat	Alacsony	Magas (viták a megosztott költségen)
FinOps érettségi szint	Crawl/Walk	Run

Tapasztalatom szerint mindig showbackkel kezdjünk, és csak akkor lépjünk át chargebackre, ha (a) az allokáció már 6 hónapja stabil 95%+ pontossággal, (b) a megosztott költségek modellje dokumentált és elfogadott, (c) a pénzügy is partnerként van benne. A chargeback bevezetése politikailag mindig véres: a csapatok azonnal vitatni kezdik a "miért én fizetem a transit gatewayt" típusú kérdéseket, és ha nincs előre lerendezve, a FinOps program elveszti a hitelességét. A FinOps Foundation allokációs capability oldala jó kiindulópont az érettségi szintek megértéséhez.

Megosztott költségek szétosztása

A megosztott költségek azok, amiket egy konkrét csapatra nem lehet visszavezetni: NAT Gateway data processing, Transit Gateway, központi log-aggregáció, közös monitoring SaaS, support szerződés, enterprise discount minimum-commit különbözet. Tipikusan a teljes felhőszámla 8-15%-a esik ide. Ezeket szét kell osztani valamilyen szabály szerint, különben "untagged shared" buborékként ott ülnek és senkit nem érdekelnek.

A három leggyakoribb modell:

1. Egyenlő allokáció: a megosztott költséget felosztjuk a csapatok között egyenlő arányban. Egyszerű, de igazságtalan a kis fogyasztókhoz.
2. Proporcionális allokáció: a megosztott költséget a csapatok közvetlen költségei arányában osztjuk fel. Aki többet költ direktben, többet visel a megosztottból is. Ez az iparági standard.
3. Használat-alapú allokáció: pl. a NAT Gateway adatfeldolgozási költségét VPC Flow Logs alapján szétbontjuk forrás-IP / instance ID szerint. Pontos, de drága fenntartani.

Példa proporcionális szétosztásra egy AWS CUR-ra építve, DuckDB-vel (a DuckDB ezekre a havi 50-200 GB-os CUR Parquet fájlokra ideális lokális elemzésre):

-- Proporcionális megosztott költség allokáció
WITH direct_costs AS (
  SELECT
    resource_tags_user_cost_center AS cost_center,
    SUM(line_item_unblended_cost) AS direct_cost
  FROM read_parquet('cur-2026-06/*.parquet')
  WHERE resource_tags_user_cost_center IS NOT NULL
    AND resource_tags_user_cost_center != ''
  GROUP BY 1
),
shared_pool AS (
  SELECT SUM(line_item_unblended_cost) AS shared_cost
  FROM read_parquet('cur-2026-06/*.parquet')
  WHERE resource_tags_user_cost_center IS NULL
     OR resource_tags_user_cost_center = ''
),
total_direct AS (
  SELECT SUM(direct_cost) AS total FROM direct_costs
)
SELECT
  d.cost_center,
  ROUND(d.direct_cost, 2) AS direct_cost,
  ROUND(s.shared_cost * (d.direct_cost / t.total), 2) AS allocated_shared,
  ROUND(d.direct_cost + s.shared_cost * (d.direct_cost / t.total), 2) AS total_chargeback
FROM direct_costs d
CROSS JOIN shared_pool s
CROSS JOIN total_direct t
ORDER BY total_chargeback DESC;

Ha mélyebb képet szeretnél kapni arról, hogyan illeszkedik mindez a kedvezményekkel (RI/Savings Plan/CUD), olvasd el a foglalt instanciák vs. Savings Plans vs. CUD-ok 2026-ban útmutatómat. A kedvezmények allokációja önmagában egy olyan rabbithole, ami megérdemli a saját cikkét. A Kubernetes-szintű allokációhoz pedig a Kubernetes költségoptimalizálás 2026 cikket ajánlom, ott a namespace és label szintű allokáció részleteit fedem.

A FOCUS 1.1 spec és miért érdekel

A FOCUS (FinOps Open Cost and Usage Specification) egy nyílt szabvány, amit a FinOps Foundation kezel, és 2024 óta egységesíti, hogyan néz ki egy "költségadat sor" az AWS, Azure, GCP, Oracle és kisebb felhők kimenetén. A 2026 Q1-ben megjelent FOCUS 1.1 bevezette a kötelező BilledCost, EffectiveCost (kedvezményekkel együtt), ContractedCost és ListCost oszlopokat. Ezek lefedik a 4 alapvető nézetet, amit eddig minden BI csapat saját maga számolt.

A gyakorlati jelentősége: ha a saját adattárházadban a FOCUS-ra építed az alaprétegét (és a hyperscaler-specifikus mezőket csak egy "raw" partitionban tartod meg), akkor a downstream dashboardok és allokációs modelljeid hordozhatóak lesznek a felhők között. Egy új felhő bevezetése nem 3 hónapos adattárház átírás lesz, hanem egy új source ingestion. Az AWS Data Exports szolgáltatás már natívan ad FOCUS 1.0 formátumot a CUR mellé; az Azure-on és GCP-n is open-source mappelő scriptek érhetők el. A részleteket a FOCUS hivatalos specifikációjában találod.

Gyakori kérdések

Mi az a cost allocation tag, és miben különbözik egy sima tagtől?

Egy tag csak kulcs-érték címke az erőforráson. Cost allocation taggé akkor válik, amikor a Billing konzolban (AWS) vagy az allokációs jelentés konfigurációjában (Azure, GCP) aktiválod; ekkor jelenik meg külön oszlopként a CUR-ban / cost exportban. Az aktiválás után indított erőforrások adatai lesznek tagelve, visszamenőlegesen nem.

Hány kötelező taget érdemes bevezetni?

Négyet: cost-center, environment, product, owner. Több kötelező tag a tapasztalatom szerint nem növeli az allokációs pontosságot, viszont a fejlesztők megkerülik. Opcionális tageket bátran adj hozzá, de csak ezt a négyet kényszerítsd ki SCP-vel vagy Azure Policy-val.

Mi a különbség a showback és a chargeback között?

Showback: a csapatok látják, mennyit költenek, de a pénz nem kerül belső kontírozással leterhelésre. Chargeback: a pénzügy a havi zárlatkor ténylegesen ráterheli az adott cost centerre a részét. Showbackkel kezdjünk, és csak 6+ hónapnyi stabil 95%+ allokáció után váltsunk chargebackre.

Hogyan osszuk fel a megosztott felhőköltségeket (transit, monitoring)?

A három alapmodell: egyenlő allokáció, proporcionális allokáció (a csapatok direkt költsége arányában), és használat-alapú (pl. VPC Flow Logs alapján). Az iparági standard a proporcionális modell, egyszerű és érzetre is igazságos. A képletet dokumentáld, és a pénzügy írja alá.

Mit jelent a FOCUS specifikáció és miért érdemes alkalmazni?

A FOCUS (FinOps Open Cost and Usage Specification) a felhők költségadatainak oszlopnévtér-szabványa. A 2026-os 1.1-es verzió kötelezővé teszi a BilledCost, EffectiveCost, ContractedCost és ListCost mezőket. Aki FOCUS-ra építi az adatpipeline-ját, az hordozhatóbb dashboardokat és felhőfüggetlen FinOps modellt kap.