Dacă răspunzi de un cont de facturare Google Cloud în care cineva deține o cheie API pentru un serviciu AI, acest text este pentru tine. Google a adăugat recent în Cloud Billing limitele de cheltuieli (spend caps), un mecanism care suspendă automat serviciul acoperit după depășirea unei sume stabilite. Combinat cu detectorul de anomalii de cost construit de FOTC (Cloud Anomaly Detector), oferă o imagine completă asupra finanțelor contului – limita păzește suma stabilită, iar detectorul arată dacă cheltuielile sunt normale și ce a cauzat schimbarea.
Despre cum a ajutat Cloud Anomaly Detector la oprirea unui incident de LLMjacking în câteva ore am scris în articolul anterior din această serie. Azi mergem mai în profunzime – vei afla ce oferă concret un spend cap, unde se termină posibilitățile lui și cum să distribui limitele pe zeci de proiecte fără riscul de a opri producția. Primești și trei comenzi cu care îți verifici contul chiar azi.
De la publicarea primului articol, sistemul a lucrat o lună întreagă pe sute de conturi de facturare, a fost redenumit Cloud Anomaly Detector și a primit în dashboard o vizualizare nouă, dedicată spend cap-urilor: o hartă care arată ce proiecte au deja o limită și care stau încă fără ea. Începem cu limitele, pentru că ele schimbă raportul de forțe.
Spend cap – cum funcționează mecanismul
Bugetele din Cloud Billing există de mult, dar doar notificau. Un spend cap este un buget cu aplicare: când costul estimat al unui serviciu dat, într-un proiect dat, depășește suma, Google oprește cererile noi către acel serviciu. Nimeni nu trebuie să apese nimic. Pentru cine a văzut factura pentru trei zile de inferență scăpată de sub control, este o schimbare calitativă. Un cap acoperă un singur serviciu într-un singur proiect, iar lista serviciilor acceptate este deocamdată scurtă: Gemini API, Gemini Enterprise Agent Platform (fost Vertex AI), Cloud Run și Cloud Run functions. Limita funcționează exclusiv pe perioadă lunară, iar din 13 octombrie 2026 întreaga funcție este disponibilă general (GA). Așa arată documentația la 23 octombrie 2026. Google anunță că versiunile următoare vor aduce alte servicii sub limite, iar fiecare dintre ele este încă o zonă pe care o poți opri în acest fel.
Cloud Anomaly Detector este un sistem construit de noi, care la fiecare jumătate de oră compară cheltuielile fiecărui cont de facturare cu propriul istoric și alarmează când ceva deviază de la el. Singur nu oprește nimic. În schimb, răspunde la întrebarea pe care limita nu o pune niciodată: este normală această cheltuială și de unde a venit?
Ce blochează cap-ul
- Apelurile API noi către serviciul indicat, în acel proiect
- Până la începutul lunii următoare sau până la editarea manuală a bugetului
Ce continuă
- Compute, storage și alte resurse persistente
- Alte proiecte și alte servicii
- Costul cererilor în curs; aplicarea nu este instantanee
Tuturor celor care au în organizație măcar o cheie API pentru un serviciu AI le spunem același lucru: acolo unde Spend Caps sunt disponibile, pune un cap pe fiecare proiect în care serviciul este activat și pe fiecare în care nu este. Al doilea caz este cel mai important. Incidentul din mai, pe care l-am descris în primul articol, a constat în faptul că un atacator a activat un serviciu AI într-un proiect care nu îl folosise niciodată. Un cap de o sută de euro pe un proiect care nu are de ce să cheltuiască un cent pe AI ajută la limitarea costului unui astfel de abuz. Suma trebuie aleasă conștient, ținând cont de întârzierea aplicării.
Limita pe proiect și monitorizarea întregului cont
Un spend cap protejează o pereche proiect × serviciu. Monitorizarea întregului cont acoperă și costurile proiectelor nou atașate. Configurația implicită a Google Cloud acordă rolul Project Creator tuturor utilizatorilor din domeniu, iar Billing Account User este împărțit mai larg decât își amintește cineva. Cu astfel de drepturi, un script poate crea un proiect nou, atașa facturarea și porni un serviciu AI. Toate cap-urile și bugetele tale de proiect stau în proiectele vechi.
Într-una dintre intruziunile la care am fost chemați să ajutăm, atacatorul a creat un proiect nou și l-a atașat contului de facturare al victimei. Clientul a văzut o factură pe care nu și-o putea explica și ne-a cerut ajutorul. Prima întrebare nu a fost „cine”, ci „care proiect”. Până când un cost nu are o adresă, în jurnale nu ai ce căuta.
Odată ce adresa era cunoscută, restul l-au spus jurnalele de audit. Mediul în care creștea costul nu aparținea niciunui lucru pe care clientul să îl recunoască, pentru că cineva îl crease de la zero și îl atașase contului lui de facturare. De aceea merită urmărite schimbările de pe întregul cont, nu doar din proiectele cunoscute. O linie nouă de cost care cheltuiește din prima oră este pentru detector un tip separat de anomalie.
De aici regula adoptată pentru întregul portofoliu: spend cap-ul impune suma stabilită, iar detecția la nivelul contului de facturare recunoaște schimbările neobișnuite, inclusiv în proiecte noi. La acestea se adaugă două schimbări IAM ieftine: retragerea rolului implicit Project Creator de la întregul domeniu și verificarea celor care dețin cu adevărat Billing Account User.
Când sunt de ajuns limitele și o verificare manuală
Nu orice mediu are nevoie de un detector. Dacă ai câteva proiecte, o echipă și ai retras domeniului rolul Project Creator, atunci limitele pe perechile proiect × serviciu AI acceptate, un buget pe întregul cont și o verificare regulată a cheltuielilor în consolă sunt de ajuns pentru controlul zilnic al costurilor. Lista proiectelor încape pe un ecran, iar fiecare linie nouă de pe factură va fi recunoscută de cineva după nume. Sfatul încetează să funcționeze când proiectele sunt zeci, iar lista celor cu drept de a crea proiecte este mai lungă decât lista celor care știu asta. Atunci nimeni nu mai ține întregul cont în minte și e nevoie de un sistem care să îl țină minte în locul oamenilor. Despre asta este restul textului.
Cum am abordat cap-urile la scară
La sute de conturi și mii de proiecte ai nevoie de o hartă. Am construit-o ca a doua filă a dashboard-ului detectorului. Câteva decizii luate atunci nu depind de scară și funcționează la fel cu câteva proiecte ca și cu mii.
În primul rând, ne-am concentrat pe numitor, adică pe ce intră în calculul acoperirii. Numărăm fiecare proiect atașat contului, inclusiv pe cele care nu au atins niciodată AI. Dacă am număra doar proiectele care folosesc deja AI, harta ar lumina verde și nu ar spune nimic despre risc. Protejezi ceea ce atacatorul urmează să activeze.
În al doilea rând, am stabilit că un buget fără filtru de serviciu nu este o limită, ci o alertă, și nu are voie să intre în acoperire. Când am numărat naiv, acoperirea a ieșit de zeci de ori mai bună decât era în realitate.
În al treilea rând, am stabilit de unde vine suma. O propune istoricul contului: cea mai mare dintre două valori, media lunilor complete și ultima lună completă. Luna curentă este exclusă, pentru că o limită calculată la jumătatea lunii este calculată din jumătate de trafic. Rotunjim mereu în sus, fiindcă o limită rotunjită în jos stă sub traficul pentru care a fost dimensionată. Un proiect fără cheltuieli primește o sumă simbolică.
În al patrulea rând, am stabilit ordinea. Lucrăm lista de la cele mai mici medii, pentru că acolo o greșeală costă cel mai puțin și acolo sunt cele mai multe proiecte fără istoric. Mediile mari, cu trafic real pe AI, primesc limită doar după o discuție despre sumă. O limită aleasă greșit oprește producția clientului la fel de eficient ca un atac.
Și regula pe care nu o încălcăm: ce a confirmat API-ul și ce a bifat un om manual în consolă au culori separate pe hartă și nu se însumează niciodată într-un singur procent. Declarația este valoroasă pentru că poartă un nume și o dată. Dovadă este doar citirea.
O lună în producție: între „deviază” și „merită să trezim pe cineva”
Detectorul compară fiecare cont doar cu propriul istoric, așa că în fiecare rulare zeci de conturi deviază de la normă, și așa trebuie să fie. Toată valoarea sistemului stă în felul în care alege, din aceste observații, cele câteva zeci pe lună la care are dreptul să întrerupă ziua cuiva.
Un caz concret din 3 septembrie. Un cont care de obicei cheltuiește vreo zece și ceva de euro pe zi a cheltuit 500 într-o singură zi. Multiplicator ×23, creștere de 2200 la sută, practic totul pe un singur serviciu de hărți. Detectorul l-a văzut la 03:00 și l-a confirmat de 42 de ori în următoarele 21 de ore. Nu a trezit pe nimeni, pentru că 500 de euro nu trec pragul valoric de la care avem voie să întrerupem ziua cuiva.
Alerta a plecat totuși a doua zi dimineața, dar de la alt detector. Prognoza pentru sfârșitul lunii a ajuns la 6000 de euro față de 900 în lunile precedente. La scara unei zile suma era prea mică pentru a trezi pe cineva. La scara unei luni, nu.
Nu a fost un atac. La client se stricase partea de hărți, traficul se comutase pe un proiect de rezervă și începuse să genereze cost acolo unde nu se uita nimeni. O defecțiune, nu o spargere, dar factura ar fi crescut la fel de mult timp cât nu s-ar fi uitat nimeni.
Alerta trebuie să arate cu degetul
Două dintre cele șaisprezece alerte s-au încheiat cu o sesiune comună cu clientul. Amândouă arătau la fel: cardul spunea că acel cont cheltuiește de mai multe ori mai mult decât de obicei, iar de partea cealaltă nimeni nu putea spune din ce proiect provine acest cost și ce cheie stă în spate. Un cont de facturare este o adresă prea grosieră ca să faci ceva cu ea.
Detecția a coborât deci mai jos, la un singur proiect și un singur SKU, adică cea mai măruntă linie pe care Google o trece pe factură. Serviciile de pe card sunt ordonate după suma cu care au crescut efectiv, nu după procente. Un serviciu care a sărit de la un cent la șapte euro a crescut cu șapte sute la sută și nu înseamnă nimic. Unul care a crescut cu șapte mii de euro este întregul eveniment.
Defalcarea se calculează în aceeași rulare ca restul cardului, iar acesta nu este un detaliu de implementare. Exportul de facturare completează fereastra încă ore bune după alertă, așa că serviciile calculate la deschiderea cardului ar veni dintr-o stare mai târzie a datelor decât suma din antet. Cardul trebuie să fie fotografia unui singur moment, chiar dacă acel moment este incomplet.
Un baseline care rezistă la ce măsoară
Întâi fără matematică. Detectorul răspunde zilnic la o singură întrebare: costul de azi este normal pentru acest cont? Are nevoie de două numere: care este norma și cu cât se abate de obicei o zi de la ea. Problema începe când în ultima săptămână a existat deja o zi proastă.
Un exemplu. Un cont cheltuiește cam 20 de euro pe zi. Luni cineva rulează inferență de 900, marți de 640. Lunea o prinde orice metodă, pentru că 900 față de 20 este altă lume. Interesantă este marțea.
Cu media. Media ultimelor șapte zile, inclusiv lunea de 900, este 146. Dispersia obișnuită, calculată din aceleași zile, a crescut de la 2 la peste 300, pentru că lunea a întins-o în sus. Marțea de 640 stă la mai puțin de două astfel de dispersii de noua normă. Pentru statistică este o zi obișnuită. Alarma se stinge în mijlocul incidentului.
Cu mediana. Mediana este valoarea din mijloc după sortare. Cele șapte zile sunt 17, 19, 20, 21, 22, 23 și 900; cea din mijloc este 21. Lunea stă la capătul listei și nu are niciun cuvânt de spus. Dispersia folosește același truc: luăm distanța fiecărei zile față de 21 și din nou pe cea din mijloc, adică 2. Acesta este MAD, mediana abaterilor. Marțea de 640 este la câteva sute de astfel de dispersii de normă. Alarma continuă, așa cum trebuie.
| Medie | Mediană | |
|---|---|---|
| Norma după luni | 146 | 21 |
| Dispersia obișnuită | peste 300 | 2 |
| Marți cu 640 | aproape o zi obișnuită | alarmă |
Dispersia are un minim, pentru că un cont care cheltuiește exact 20, 20, 20 ar avea dispersie zero și fiecare cent ar părea o catastrofă. Iar o zi fără rând în export se numără drept cost zero, ca o săptămână liniștită să nu dispară din istoric. Glisoarele de sub grafic arată ambele linii pe aceeași serie.
Două capcane alături. Ziua curentă: la șase dimineața contul are șase ore în spate, așa că față de zile întregi pare mereu o scădere. Comparăm deci cele șase ore de azi cu aceleași șase ore din zilele precedente. Detecția orară: dacă ora evaluată stă în același eșantion din care îi calculezi norma, ea însăși ridică norma și nu se abate niciodată suficient ca să treacă pragul. O oră de jumătate de milion pare atunci ușor ridicată. Ora evaluată trebuie scoasă din eșantion.
Sistemul trebuie să știe ce nu vede
Cea mai periculoasă stare a unui detector de anomalii este tăcerea care arată ca liniștea.
Pe 25 august exportul de facturare a încetat să scrie. Nu o singură sursă, ci toate, una după alta, la câteva zeci de minute distanță. Detectorul a continuat să ruleze din jumătate în jumătate de oră, a scanat tabele neschimbate de dimineață și a raportat de fiecare dată că nu există anomalii. Timp de șase ore nimeni nu se uita la flotă, iar singura urmă a acestei stări era o bandă pe dashboard la care cineva trebuia să se uite din proprie inițiativă.
Am reparat asta în aceeași zi și am exagerat imediat: o sursă moartă a început să trezească inginerul de gardă. În noaptea aceea, la scurt timp după miezul nopții, cel de gardă a primit un apel despre un tabel de export înghețat, cu care oricum nu putea face nimic până dimineața. A doua zi am scos calea asta. Pagerul este acum rezervat costului, iar defecțiunea unei surse are propriul canal și un prag numărat în ore de tăcere, pentru că o sursă care pâlpâie un sfert de oră nu este un incident, iar una care tace o jumătate de zi este.
Patru stări pe care codul naiv le raportează identic drept „nicio anomalie”:
Exportul nu mai scrie de ore
Detectorul scanează tabele înghețate și raportează succes. E nevoie de o metrică separată: de cât timp nu a mai scris sursa nimic, cu un prag numărat în ore de tăcere.
Interogarea a picat
O listă goală pentru că interogarea a picat și o listă goală pentru că nu s-a găsit nimic sunt două fapte diferite, iar codul trebuie să le deosebească. O rulare care nu a văzut flota se încheie cu eroare, nu cu raport.
Cont fără o lună întreagă de istoric
Prognoza nu se produce, și pe bună dreptate, pentru că nu are din ce. Dar contul este numărat și vizibil ca „neevaluat”, cu data de la care va începe să fie evaluat.
Zero conturi în loc de sute
Un rezultat gol înseamnă eșecul rulării. O flotă goală apare doar la prima implementare, iar atunci trebuie declarată explicit.
Lipsa datelor nu este zero. Fiecare cale care nu poate dovedi că a privit datele încheie rularea cu o eroare vizibilă în monitorizare. Alternativa este un dashboard verde peste o flotă la care nu se uită nimeni.
Cum verifici la tine
Trei comenzi răspund la întrebarea acestui text: poate apărea sub contul tău de facturare un proiect de care nu știe nimeni? Prima listează proiectele atașate contului cu data creării, cele mai noi sus. A doua arată cine poate crea proiecte în organizație. A treia, cine le poate atașa la facturare.
$ 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 ← creat ieri, zero istoric de costurishop-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 ← întregul domeniu poate crea proiecte (implicit)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 ← o cheie de ani buni, nimeni nu mai știe de ceserviceAccount:ci-legacy@shop-prod.iam.gserviceaccount.com
domain: la Project Creator înseamnă configurația implicită Google Cloud: oricine din companie poate crea un proiect.Aceleași trei comenzi, gata de lipit. Completezi cele două variabile de sus și lipești restul neschimbat. Identificatorul contului îl găsești cu gcloud billing accounts list, numărul organizației cu gcloud organizations list.
export BILLING_ACCOUNT_ID="0X0X0X-0X0X0X-0X0X0X" # gcloud billing accounts list
export ORG_ID="123456789012" # gcloud organizations list
echo "== 1. Proiecte atașate contului $BILLING_ACCOUNT_ID, cele mai noi sus =="
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. Cine poate crea proiecte în organizația $ORG_ID =="
gcloud organizations get-iam-policy "$ORG_ID" --flatten="bindings[].members" \
--filter="bindings.role:roles/resourcemanager.projectCreator" --format="value(bindings.members)"
echo; echo "== 3. Cine poate atașa proiecte la contul $BILLING_ACCOUNT_ID =="
gcloud billing accounts get-iam-policy "$BILLING_ACCOUNT_ID" --flatten="bindings[].members" \
--filter="bindings.role:roles/billing.user" --format="value(bindings.members)"Revizuiește lista de proiecte
Fiecare proiect pe care nu îl recunoști primește un proprietar sau dispare. Repetă săptămânal, ideal din program, cu e-mail.
Restrânge Project Creator și Billing Account User
Retrage domeniului rolul implicit, păstrează grupul de administratori. Lista celor care pot atașa facturarea trebuie să încapă pe degetele unei mâini.
Cap pe fiecare pereche proiect × serviciu AI
Inclusiv acolo unde AI nu este folosit. Acolo o sumă simbolică; unde traficul este real, o sumă derivată din istoric și rotunjită în sus.
Buget pe întregul cont
Cu un prag ales după cheltuielile reale, nu după un număr rotund. Acoperă și cheltuielile proiectelor noi atașate acestui cont.
Acești patru pași durează o după-amiază și nu cer nimic în afara consolei. Închid scenariul din acest text într-un mediu mic și îl fac mult mai greu într-unul mare.
Rezumat
Spend Caps din Google Cloud impun automat suma stabilită pentru serviciile acoperite. Pune-le oriunde se poate, cu atenție specială la proiectele care nu folosesc AI. Cloud Anomaly Detector adaugă un al doilea strat de control: compară cheltuielile cu istoricul contului, arată ce s-a schimbat și trezește pe cineva care poate reacționa. O cheltuială neobișnuită poate merita atenție chiar și atunci când încape în limita lunară.
Spend Caps păzesc suma stabilită. Cloud Anomaly Detector ajută să recunoști un cost neobișnuit și să decizi ce faci cu el.
Cei patru pași de mai sus sunt suficienți ca să începi. Pe măsură ce mediul crește, verifică dacă limitele mai acoperă ce trebuie. Limita este acolo unde începe întrebarea „este atac sau o funcție nouă?”, la zeci de proiecte și chei împărțite de-a lungul anilor. La FOTC facem asta sub numele Cloud Anomaly Detector: monitorizarea contului de facturare la fiecare jumătate de oră, cu alerte către echipa ta și a noastră, iar când alerta a venit deja și nu știi ce să faci cu ea, și ca suport de inginerie la oră, fără contract lung. Dacă preferi să o faci singur, tot ce este mai sus este suficient ca să începi.
Întrebări frecvente
Mă protejează spend cap-ul de LLMjacking?
Limitează factura în proiectele pe care le-ai acoperit. Nu oprește atacul: aplicarea nu este instantanee, cererile în curs se facturează, iar un atacator cu drept de a crea proiecte va crea unul nou. Cap-ul, detecția la nivel de cont și verificarea rolurilor Project Creator și Billing Account User închid trei breșe diferite. Niciunul nu îl înlocuiește pe celelalte.
De ce Cloud Anomaly Detector dacă am Spend Caps?
Spend Caps suspendă folosirea serviciului indicat după depășirea sumei stabilite. Detectorul caută abateri de la cheltuielile normale ale contului și ajută să indici proiectul și serviciul responsabile de schimbare. Poate semnala o anomalie care încape în limită, dacă îndeplinește condițiile de alertare. Lucrează din exportul de facturare, așa că timpul de detecție depinde de momentul în care sosesc datele. Nu există garanția că alerta apare înainte ca Spend Caps să acționeze.
Ce sumă setez pe un proiect care nu folosește AI?
Una simbolică, de ordinul a o sută de euro pe lună. Cât să nu o observe nimeni la un test legitim și suficient de mică încât să oprească abuzul înainte să crească. Când proiectul începe cu adevărat să folosească AI, ridici limita în mod conștient.
Poate cap-ul să-mi oprească producția?
Da, și asta e treaba lui. O sumă aleasă greșit pe un proiect cu trafic real va opri inferența legitimă, iar limita se ridică singură abia la începutul lunii următoare. Până atunci trebuie ridicată de un om, iar revenirea durează până la o oră. De aceea pe proiectele de producție suma vine din istoric și se rotunjește în sus, iar cineva cu acces la buget trebuie să fie disponibil și în weekend.
Ce se întâmplă dacă exportul de facturare către BigQuery se oprește?
Este singura stare pe care un detector de anomalii de cost nu o observă singur, pentru că lipsa datelor arată ca lipsa cheltuielilor. Prospețimea sursei trebuie să fie o metrică separată, cu alarmă separată, iar dashboard-ul trebuie să spună „nu văd” într-o altă culoare decât „nu se întâmplă nimic”.
Descrierea spend cap-urilor provine din documentația publică Google Cloud, verificată la 23 octombrie 2026. Din 13 octombrie 2026 Spend Caps din Cloud Billing sunt disponibile general (GA), iar documentația anunță o listă extinsă de servicii. Cifrele despre activitatea detectorului sunt reale și provin din jurnalele lui. Harta acoperirii și graficul baseline-ului ilustrează mecanismul și nu sunt capturi din producție. Articolul descrie sistemul în versiunea 6.x (2026).