Ha olyan Google Cloud számlázási fiókért felelsz, amelyben bárkinek van API kulcsa egy AI-szolgáltatáshoz, ez a cikk neked szól. A Google nemrég bevezette a Cloud Billingben a költési korlátokat (spend caps), amelyek automatikusan felfüggesztik a lefedett szolgáltatás használatát, ha a költés átlép egy megadott összeget. A FOTC által fejlesztett költséganomália-detektorral (Cloud Anomaly Detector) együtt teljes rálátást ad a fiók pénzügyeire – a korlát a megadott összeget őrzi, a detektor pedig megmutatja, normális-e a költés, és mi okozta a változást.
Arról, hogyan segített a Cloud Anomaly Detector órákon belül megállítani egy LLMjacking-incidenst, a sorozat előző cikkében írtunk. Ma mélyebbre megyünk – megtudod, mit ad valójában a spend cap, hol vannak a határai, és hogyan oszd el a korlátokat több tucat projektre a termelés leállításának kockázata nélkül. Kapsz három parancsot is, amellyel még ma ellenőrizheted a saját fiókodat.
Az első cikk megjelenése óta a rendszer egy teljes hónapot dolgozott több száz számlázási fiókon, Cloud Anomaly Detector lett a neve, és a dashboardján új, a spend capeknek szentelt nézetet kapott: egy térképet, amely megmutatja, mely projekteken van már cap, és melyek állnak még nélküle. A capekkel kezdünk, mert ezek változtatják meg az erőviszonyokat.
Spend cap – hogyan működik a mechanizmus
Költségkeretek régóta léteznek a Cloud Billingben, de csak értesítettek. A spend cap egy végrehajtással ellátott költségkeret: amikor egy adott szolgáltatás becsült költsége egy adott projektben túllépi az összeget, a Google leállítja az új kéréseket a szolgáltatás felé. Senkinek nem kell kattintania. Aki látott már számlát három napi ellenőrizetlen inferenciáról, annak ez minőségi változás. Egy cap egy szolgáltatást fed le egy projektben, és a támogatott szolgáltatások listája egyelőre rövid: Gemini API, Gemini Enterprise Agent Platform (korábban Vertex AI), Cloud Run és Cloud Run functions. A cap kizárólag havi időszakkal működik, és az egész funkció 2026. október 13. óta általánosan elérhető (GA). Ez a dokumentáció 2026. október 23-i állapota. A Google azt ígéri, hogy a következő kiadásokban további szolgáltatásokat von a capek alá, és mindegyik egy újabb terület, amelyet így meg lehet állítani.
A Cloud Anomaly Detector egy általunk épített rendszer, amely félóránként összeveti minden számlázási fiók költését a fiók saját előzményével, és riaszt, ha valami eltér tőle. Önmagában semmit nem állít le. Ehelyett arra a kérdésre válaszol, amelyet a cap sosem tesz fel: normális-e ez a költés, és honnan jött.
Mit blokkol a cap
- Az adott szolgáltatás új API-hívásai ebben a projektben
- A következő hónap elejéig vagy a költségkeret kézi szerkesztéséig
Mi megy tovább
- Compute, storage és más állandó erőforrások
- Más projektek és más szolgáltatások
- A folyamatban lévő kérések költsége, a végrehajtás nem azonnali
Mindenkinek, akinek a szervezetében legalább egy AI-szolgáltatáshoz van API kulcsa, ugyanazt mondjuk: ahol a Spend Caps elérhető, tegyél capet minden projektre, ahol a szolgáltatás be van kapcsolva, és mindenre, ahol nincs. A második eset a fontosabb. Az első cikkben leírt májusi incidens arról szólt, hogy egy támadó olyan projektben kapcsolt be egy AI-szolgáltatást, amely soha nem használta. Egy száz eurós cap egy olyan projekten, amelynek egy centet sem szabadna AI-ra költenie, segít korlátozni az ilyen visszaélés költségét. Az összeget tudatosan kell megválasztani, számolva a végrehajtás késésével.
Korlát a projekten és az egész fiók monitorozása
A spend cap egy projekt × szolgáltatás párt véd. Az egész fiók monitorozása az újonnan hozzákötött projektek költségét is lefedi. A Google Cloud alapértelmezett beállítása a Project Creator szerepkört a domain minden felhasználójának megadja, a Billing Account User pedig szélesebb körben van kiosztva, mint bárki emlékezne rá. Ilyen jogosultságokkal egy szkript új projektet hozhat létre, hozzákötheti a számlázást és elindíthat egy AI-szolgáltatást. Minden caped és projektkerete a régi projektekben áll.
Az egyik betörésnél, amelynél segítettünk, a támadó új projektet hozott létre, és az áldozat számlázási fiókjához kötötte. Az ügyfél olyan számlát látott, amelyet nem tudott megmagyarázni, és a segítségünket kérte. Az első kérdés nem az volt, hogy „ki”, hanem hogy „melyik projekt”. Amíg a költségnek nincs címe, a naplókban nincs mit keresni.
Amikor a cím megvolt, a többit az auditnaplók mondták el. A környezet, amelyben a költség nőtt, semmihez nem tartozott, amit az ügyfél ismert, mert valaki a semmiből hozta létre, és az ügyfél számlázási fiókjához kötötte. Ezért érdemes az egész fiók változásait figyelni, nem csak az ismert projektekét. Az olyan új költségtétel, amely az első órájától költ, a detektor számára külön anomáliatípus.
Innen a szabály, amelyet az egész portfólióra elfogadtunk: a spend cap kikényszeríti a megadott összeget, a számlázási fiók szintű észlelés pedig felismeri a szokatlan változásokat, az új projektekben is. Ehhez két olcsó IAM-lépés: az alapértelmezett Project Creator szerepkör elvétele a domaintől, és annak átnézése, kinek van valóban Billing Account User jogosultsága.
Amikor elég a korlát és a kézi átnézés
Nem minden környezetnek kell detektor. Ha néhány projekted van, egy csapatod, és a domaintől elvetted a Project Creator szerepkört, akkor a capek a támogatott projekt × AI-szolgáltatás párokon, egy költségkeret az egész fiókra és a költések rendszeres átnézése a konzolban elég a napi költségkontrollhoz. A projektlista elfér egy képernyőn, és a számlán minden új tételt felismer valaki a nevéről. Ez a tanács akkor szűnik meg működni, amikor több tucat projekt van, és a projektet létrehozni jogosultak listája hosszabb, mint azoké, akik erről tudnak. Akkor már senki nem tartja fejben az egész fiókot, és kell egy rendszer, amely az emberek helyett emlékszik rá. Erről szól a cikk többi része.
Hogyan közelítettük meg a capeket nagy léptékben
Több száz fióknál és több ezer projektnél térkép kell. A detektor dashboardjának második lapjaként építettük meg. Néhány akkor hozott döntésünk nem függ a léptéktől, és ugyanúgy működik néhány projektnél, mint több ezernél.
Először a nevezőre összpontosítottunk, vagyis arra, mi kerül egyáltalán a lefedettség számításába. Minden, a fiókhoz kötött projektet beleszámolunk, azt is, amelyik soha nem nyúlt AI-hoz. Ha csak az AI-t már használó projekteket néznénk, a térkép zölden világítana, és semmit nem mondana a kockázatról. Azt véded, amit a támadó majd bekapcsol.
Másodszor úgy döntöttünk, hogy a szolgáltatásszűrő nélküli költségkeret nem korlát, hanem riasztás, és nem szabad a lefedettségbe számolni. Amikor naivan számoltuk, a lefedettség több tucatszor jobbnak tűnt a valóságosnál.
Harmadszor megállapodtunk, honnan jön az összeg. A fiók saját előzménye javasolja: a teljes hónapok átlaga és az utolsó teljes hónap közül a nagyobb. A folyó hónap kimarad, mert a hónap közepén számolt korlát a forgalom feléből számolt korlát. Mindig felfelé kerekítünk, mert a lefelé kerekített korlát az alá a forgalom alá kerül, amelyre méretezték. A költés nélküli projekt szimbolikus összeget kap.
Negyedszer rögzítettük a sorrendet. A listát a legkisebb környezetektől kezdjük, mert ott a legolcsóbb a hiba, és ott van a legtöbb előzmény nélküli projekt. A valós AI-forgalmú nagy környezetek csak az összegről folytatott beszélgetés után kapnak capet. A rosszul megválasztott korlát ugyanolyan hatékonyan állítja le az ügyfél termelését, mint egy támadás.
És a szabály, amelyet nem szegünk meg: amit az API igazolt, és amit ember jelölt be kézzel a konzolban, külön színt kap a térképen, és soha nem összegződik egy százalékba. A bejelentés értékes, mert nevet és dátumot hordoz. Bizonyíték csak az olvasat.
Egy hónap élesben: a „kiugrik” és az „érdemes felkelteni valakit” között
A detektor minden fiókot kizárólag a saját előzményéhez hasonlít, ezért minden futásban tucatnyi vagy több fiók tér el a normájától, és ez így van rendjén. A rendszer teljes értéke abban rejlik, hogyan választja ki ezekből a megfigyelésekből azt a havi tucatnyit, amelyeknél joga van megszakítani valakinek a napját.
Egy konkrét eset szeptember 3-áról. Egy fiók, amely általában napi tizenvalahány eurót költ, egyetlen nap alatt 500-at költött. ×23-as szorzó, 2200 százalékos növekedés, gyakorlatilag az egész egyetlen térképszolgáltatáson. A detektor 3:00-kor látta meg, és a következő 21 órában 42-szer erősítette meg. Senkit nem ébresztett fel, mert az 500 euró nem lépi át azt az összeghatárt, amelynél valakinek meg szabad szakítani a napját.
A riasztás másnap reggel mégis kiment, csak egy másik detektorból. A hónap végi előrejelzés 6000 euróig kúszott az előző hónapok 900-ával szemben. Egy nap léptékében az összeg túl kicsi volt ahhoz, hogy bárkit felébresszen. Egy hónap léptékében már nem.
Nem támadás volt. Az ügyfélnél a térképes rész elromlott, a forgalom átkapcsolt egy tartalék projektre, és ott kezdett költséget termelni, ahol senki nem figyelte. Üzemzavar, nem betörés, de a számla ugyanúgy nőtt volna, amíg senki bele nem néz.
A riasztásnak rá kell mutatnia
A tizenhat riasztásból kettő az ügyféllel közös munkamenettel végződött. Mindkettő ugyanúgy nézett ki: a kártya azt mondta, hogy a fiók a szokásos többszörösét költi, a másik oldalon pedig senki nem tudta megmondani, melyik projektből származik ez a költség, és melyik kulcs áll mögötte. A számlázási fiók túl durva cím ahhoz, hogy bármit kezdjünk vele.
Az észlelés ezért lejjebb ment, egyetlen projektre és egyetlen SKU-ra, vagyis a legapróbb tételre, amelyet a Google a számlán feltüntet. A kártyán a szolgáltatásokat aszerint rendezzük, mekkora összeggel nőttek valójában, nem százalék szerint. Az a szolgáltatás, amely egy centről hét euróra ugrott, hétszáz százalékkal nőtt, és semmit nem jelent. Az, amely hétezer euróval nőtt, maga az esemény.
A bontás ugyanabban a futásban készül, mint a kártya többi része, és ez nem megvalósítási részlet. A számlázási export még órákkal a riasztás után is tölti az ablakot, így a kártya megnyitásakor számolt szolgáltatások az adatok későbbi állapotából származnának, mint a fejlécben lévő összeg. A kártyának egyetlen pillanat felvételének kell lennie, még ha az a pillanat hiányos is.
Alapvonal, amely kibírja, amit mér
Először matematika nélkül. A detektor minden nap egy kérdésre válaszol: normális-e a mai költség ennél a fióknál? Ehhez két számra van szüksége: mi a norma, és mennyire tér el tőle egy nap általában. A gond akkor kezdődik, amikor az elmúlt héten már volt egy rossz nap.
Egy példa. A fiók naponta körülbelül 20 eurót költ. Hétfőn valaki 900-ért futtat inferenciát, kedden 640-ért. A hétfőt bármelyik módszer elkapja, mert a 900 a 20-hoz képest más világ. A kedd az érdekes.
Átlaggal. Az utolsó hét nap átlaga, a hétfői 900-zal együtt, 146. A szokásos szórás, ugyanezekből a napokból számolva, 2-ről 300 fölé nőtt, mert a hétfő felfelé húzta. A keddi 640 az új normától kevesebb mint két ilyen szórásra van. A statisztika számára közönséges nap. A riasztás az incidens közepén elhal.
Mediánnal. A medián a rendezés utáni középső érték. A hét nap: 17, 19, 20, 21, 22, 23 és 900, a középső 21. A hétfő a lista végén áll, és nincs szava. A szórást ugyanezzel a trükkel számoljuk: minden nap távolságát vesszük a 21-től, és megint a középsőt, ami 2. Ez a MAD, az eltérések mediánja. A keddi 640 több száz ilyen szórásra van a normától. A riasztás megmarad, ahogy kell.
| Átlag | Medián | |
|---|---|---|
| Norma hétfő után | 146 | 21 |
| Szokásos szórás | 300 felett | 2 |
| Kedd 640-nel | szinte közönséges nap | riasztás |
A szórásnak van alsó határa, mert egy pontosan 20, 20, 20-at költő fiók szórása nulla lenne, és minden cent katasztrófának látszana. Az exportban sor nélküli nap pedig nulla költségnek számít, hogy egy csendes hét ne tűnjön el az előzményből. A diagram alatti csúszkák ugyanazon a sorozaton mutatják a két vonalat.
Két szomszédos csapda. A folyó nap: reggel hatkor a fióknak hat órája van a háta mögött, így teljes napokhoz mérve mindig csökkenésnek látszik. Ezért a mai hat órát az előző napok ugyanazon hat órájával hasonlítjuk. Az óránkénti észlelés: ha a vizsgált óra ugyanabban a mintában ül, amelyből a normát számolod, akkor maga emeli a normát, és soha nem tér el tőle annyira, hogy átlépje a küszöböt. Egy félmilliós óra ekkor enyhén emelkedettnek látszik. A vizsgált órát ki kell hagyni a mintából.
A rendszernek tudnia kell, mit nem lát
Az anomáliadetektor legveszélyesebb állapota a csend, amely nyugalomnak látszik.
Augusztus 25-én a számlázási export abbahagyta az írást. Nem egy forrás, hanem mind, egymás után, néhány tíz perc különbséggel. A detektor félóránként tovább futott, reggel óta változatlan táblákat olvasott, és minden alkalommal azt jelentette, hogy nincs anomália. Hat órán át senki nem nézte a flottát, és ennek az állapotnak az egyetlen nyoma egy sáv volt a dashboardon, amelyre valakinek magától rá kellett néznie.
Még aznap kijavítottuk, és rögtön túl is lőttünk a célon: a halott forrás elkezdte felébreszteni az ügyeletest. Azon az éjszakán, nem sokkal éjfél után, az ügyeletes hívást kapott egy befagyott exporttábláról, amellyel reggelig úgysem tudott mit kezdeni. Másnap ezt az utat visszavontuk. A pager ma a költségnek van fenntartva, a forráshiba pedig külön csatornát kapott, csendben töltött órákban mért küszöbbel, mert a negyedórán át villódzó forrás nem incidens, a fél napig hallgató viszont igen.
Négy állapot, amelyet a naiv kód egyformán „nincs anomália”-ként jelent:
Az export órák óta nem ír
A detektor befagyott táblákat szkennel, és sikert jelent. Külön mérőszám kell: mikor írt a forrás bármit is, csendben töltött órákban mért küszöbbel.
A lekérdezés elhasalt
Az üres lista, mert a lekérdezés elhasalt, és az üres lista, mert nem találtunk semmit, két különböző tény, és a kódnak meg kell különböztetnie őket. A futás, amely nem látta a flottát, hibával végződik, nem jelentéssel.
Fiók egy teljes hónap előzmény nélkül
Előrejelzés nem készül, és ez így helyes, mert nincs miből. De a fiók számít, és „nem értékelt”-ként látszik, azzal a dátummal, amelytől értékelni kezdik.
Nulla fiók több száz helyett
Az üres eredmény a futás hibáját jelenti. Üres flotta csak első telepítéskor fordul elő, és olyankor ezt kifejezetten deklarálni kell.
A hiányzó adat nem nulla. Minden út, amely nem tudja bizonyítani, hogy adatot nézett, a futást a monitoringban látható hibával zárja. Az alternatíva egy zöld dashboard egy flotta fölött, amelyet senki nem néz.
Hogyan ellenőrizd magadnál
Három parancs válaszol a cikk kérdésére: megjelenhet-e a számlázási fiókod alatt olyan projekt, amelyről senki nem tud? Az első felsorolja a fiókhoz kötött projekteket létrehozási dátummal, a legújabbal az élen. A második megmutatja, ki hozhat létre projektet a szervezetben. A harmadik, ki kötheti őket a számlázáshoz.
$ gcloud billing projects list --billing-account=0A1B2C-3D4E5F-6A7B8C --format="value(projectId)" \ | xargs -I{} gcloud projects describe {} --format="csv[no-heading](projectId,createTime.date('%Y-%m-%d'))" \ | sort -t, -k2 -rgen-ai-tmp-4471,2026-09-10 ← tegnap létrehozva, nulla költségelőzményshop-prod,2023-04-12shop-staging,2023-04-12data-warehouse,2022-11-03mobile-backend,2021-06-30 $ gcloud organizations get-iam-policy 123456789012 --flatten="bindings[].members" \ --filter="bindings.role:roles/resourcemanager.projectCreator" --format="value(bindings.members)"domain:example.com ← az egész domain hozhat létre projektet (alapértelmezés)group:cloud-admins@example.com $ gcloud billing accounts get-iam-policy 0A1B2C-3D4E5F-6A7B8C --flatten="bindings[].members" \ --filter="bindings.role:roles/billing.user" --format="value(bindings.members)"group:cloud-admins@example.comuser:dev-2019-contractor@example.com ← évekkel ezelőtti kulcs, senki nem tudja, miértserviceAccount:ci-legacy@shop-prod.iam.gserviceaccount.com
domain: bejegyzés a Project Creator alatt a Google Cloud alapértelmezését jelenti: a cégben bárki létrehozhat projektet.Ugyanez a három parancs, beillesztésre készen. Töltsd ki a két változót felül, a többit változtatás nélkül illeszd be. A fiókazonosítót a gcloud billing accounts list, a szervezet számát a gcloud organizations list adja.
export BILLING_ACCOUNT_ID="0X0X0X-0X0X0X-0X0X0X" # gcloud billing accounts list
export ORG_ID="123456789012" # gcloud organizations list
echo "== 1. A $BILLING_ACCOUNT_ID fiókhoz kötött projektek, legújabb elöl =="
gcloud billing projects list --billing-account="$BILLING_ACCOUNT_ID" --format="value(projectId)" \
| xargs -I{} gcloud projects describe {} --format="csv[no-heading](projectId,createTime.date('%Y-%m-%d'))" \
| sort -t, -k2 -r
echo; echo "== 2. Ki hozhat létre projektet a $ORG_ID szervezetben =="
gcloud organizations get-iam-policy "$ORG_ID" --flatten="bindings[].members" \
--filter="bindings.role:roles/resourcemanager.projectCreator" --format="value(bindings.members)"
echo; echo "== 3. Ki köthet projektet a $BILLING_ACCOUNT_ID fiókhoz =="
gcloud billing accounts get-iam-policy "$BILLING_ACCOUNT_ID" --flatten="bindings[].members" \
--filter="bindings.role:roles/billing.user" --format="value(bindings.members)"Nézd át a projektlistát
Minden projekt, amelyet nem ismersz fel, tulajdonost kap vagy törlődik. Ismételd hetente, legjobb ütemezésből, e-maillel.
Szűkítsd a Project Creator és Billing Account User körét
Vedd el a domaintől az alapértelmezett szerepkört, tartsd meg az admin csoportot. A számlázást hozzákötni jogosultak listája férjen el egy kézen.
Cap minden projekt × AI-szolgáltatás páron
Ott is, ahol nem használnak AI-t. Ott szimbolikus összeg; ahol valós a forgalom, az előzményből származó, felfelé kerekített összeg.
Költségkeret az egész fiókra
A valós költéshez igazított küszöbbel, ne kerek számmal. Az ehhez a fiókhoz kötött új projektek költését is lefedi.
Ez a négy lépés egy délutánt vesz igénybe, és a konzolon kívül semmi nem kell hozzá. Kis környezetben lezárja a cikk szcenárióját, nagyban jelentősen megnehezíti.
Összefoglalás
A Google Cloud Spend Capjei automatikusan kikényszerítik a megadott összeget az általuk lefedett szolgáltatásokra. Tedd fel mindenhová, ahol lehet, különös figyelemmel az AI-t nem használó projektekre. A Cloud Anomaly Detector egy második kontrollréteget tesz mellé: összeveti a költést a fiók előzményével, megmutatja, mi változott, és felébreszt valakit, aki reagálni tud. A szokatlan költés akkor is figyelmet érdemelhet, ha belefér a havi korlátba.
A Spend Caps a megadott összeget őrzi. A Cloud Anomaly Detector segít felismerni a szokatlan költséget és eldönteni, mi legyen vele.
A fenti négy lépés elég az induláshoz. Ahogy a környezet nő, ellenőrizd, hogy a capek még mindig azt fedik-e, amit kell. A határ ott van, ahol elkezdődik a kérdés: „ez támadás vagy új funkció?”, több tucat projektnél és évek alatt kiosztott kulcsoknál. A FOTC-nál ezt Cloud Anomaly Detector néven csináljuk: a számlázási fiók félóránkénti monitorozása, riasztásokkal a te csapatodnak és a miénknek, és amikor a riasztás már megjött, és nem tudod, mit kezdj vele, óradíjas mérnöki támogatásként is, hosszú szerződés nélkül. Ha inkább magad csinálnád, a fentiek elegendők az induláshoz.
GYIK
Megvéd a spend cap az LLMjackingtől?
Korlátozza a számlát azokban a projektekben, amelyeket lefedtél. A támadást nem állítja meg: a végrehajtás nem azonnali, a folyamatban lévő kérések számlázódnak, és a projektet létrehozni jogosult támadó újat hoz létre. A cap, a fiókszintű észlelés és a Project Creator, valamint Billing Account User szerepkörök átnézése három különböző rést zár be. Egyik sem helyettesíti a másikat.
Minek a Cloud Anomaly Detector, ha van Spend Caps?
A Spend Caps felfüggeszti a megnevezett szolgáltatás használatát a megadott összeg átlépése után. A detektor a fiók normális költésétől való eltéréseket keresi, és segít megmutatni a változásért felelős projektet és szolgáltatást. Jelezhet olyan anomáliát is, amely belefér a korlátba, ha teljesíti a riasztási feltételeket. A számlázási exportból dolgozik, így az észlelés ideje az adatok beérkezésétől függ. Nincs garancia arra, hogy a riasztás a Spend Caps működése előtt érkezik.
Mekkora összeget állítsak be egy AI-t nem használó projekten?
Szimbolikusat, havi százegynéhány euró nagyságrendűt. Annyit, hogy egy jogos tesztnél senki ne vegye észre, és annyira keveset, hogy a visszaélést megállítsa, mielőtt megnő. Amikor a projekt valóban elkezd AI-t használni, tudatosan emeled a korlátot.
Leállíthatja a cap a termelésemet?
Igen, és ez a dolga. Egy valós forgalmú projekten rosszul megválasztott összeg leállítja a jogos inferenciát, a korlát pedig csak a következő hónap elején oldódik fel magától. Előtte embernek kell feloldania, és a helyreállás akár egy órát is igénybe vehet. Ezért a termelési projekteken az összeg az előzményből jön és felfelé kerekít, és valakinek, aki hozzáfér a költségkerethez, hétvégén is elérhetőnek kell lennie.
Mi van, ha a BigQuery-be irányuló számlázási export leáll?
Ez az egyetlen állapot, amelyet egy költséganomália-detektor magától nem vesz észre, mert a hiányzó adat úgy néz ki, mint a költés hiánya. A forrás frissességének külön mérőszámnak kell lennie külön riasztással, és a dashboardnak más színnel kell mondania, hogy „nem látok”, mint azt, hogy „nem történik semmi”.
A spend capek leírása a Google Cloud nyilvános dokumentációjából származik, 2026. október 23-án ellenőrizve. A Cloud Billing Spend Caps 2026. október 13. óta általánosan elérhető (GA), a dokumentáció pedig bővülő szolgáltatáslistát ígér. A detektor munkájáról szóló számok valósak, a naplóiból származnak. A lefedettségi térkép és az alapvonal-diagram a mechanizmust szemlélteti, nem éles képernyőkép. A cikk a rendszer 6.x verzióját (2026) írja le.