Michael JohnsonVoiko pilvilaskennan kuluja rajoittaa vaarantamatta toimivan sovelluksen käyttöä? Cloudflare tarjoaa nyt molemmat vaihtoehdot, mutta tiukka raja toimii koko tilin tuotekohtaisena katkaisijana: rajan ylittyessä se estää uudet tuetut toiminnot. Raja ei silti takaa laskun enimmäissummaa.
Cloudflare ilmoitti 13. marraskuuta 2026 Spend Managementin käyttöönotosta Pay-as-you-go-asiakkaille. Aluksi rajat ja ilmoitukset ovat käytettävissä Workersille ja Durable Objectseille. Ominaisuus on automaattinen suoja odottamattomalta kulutuksen kasvulta – kunhan tiimi ymmärtää, mitkä palvelut pysähtyvät samalla kertaa, kuten Cloudflare kertoo.
Mitä muuttuu kuluilmoitukseen verrattuna?
Ilmoitus kertoo, että kulut ovat saavuttaneet valitun tason, mutta tuote jatkaa toimintaansa. Tiukka raja estää tuetut toiminnot. Spend Managementissa kullekin tuotteelle määritetään oma käytäntö: rajan summa, ilmoituskynnykset ja haluttaessa sähköpostiosoite. Workersin ja Durable Objectsin rajat ovat toisistaan riippumattomia, ja kumpikin kattaa kyseisen tuotteen koko tilillä. Rajaa ei voi asettaa yhdelle Workerille, yksittäiselle Durable Objects -nimitilalle tai yhdelle mittarille, kuten Cloudflaren dokumentaatiossa kerrotaan.
Käytännön valinta on yksinkertainen: ilmoitus sopii silloin, kun saatavuus on tärkeintä; estävä raja puolestaan silloin, kun tiimi on valmis pysäyttämään tuotteen tuetut toiminnot kulutuksen kasvun hillitsemiseksi.
Miksi raja ei laukea täsmälleen asetetussa summassa?
Kulujen laskenta ja eston välittäminen eivät tapahdu välittömästi. Cloudflaren mukaan hallintapaneeli näyttää kulut lähes reaaliajassa, alle 10 minuutin viiveellä, mutta hinnoittelujärjestelmä ei ole jokaisen pyynnön käsittelypolulla. Käytäntö välitetään verkon solmuihin asynkronisesti, ja suoritusympäristö ottaa sen käyttöön paikallisen tilan säännöllisen päivityksen yhteydessä. Näin Cloudflare selittää Spend Managementin toimintaperiaatetta.
Asetettu raja on siis kynnys, jonka jälkeen eston pitäisi käynnistyä, ei laskun ehdoton yläraja. Toiminnot voivat jatkua kulujen laskennan ja säännön välittymisen ajan. Kaikki veloitukset eivät myöskään kuulu rajan piiriin: esimerkiksi Workers Paid -tilausmaksu on rajattu pois, ja Durable Objectsin tallennetusta datasta voi kertyä kuluja myös tauon aikana. Cloudflare muistuttaa, että lopullinen summa näkyy laskussa.
Mitkä sovelluksen osat Workers-raja pysäyttää?
Workers-rajaan lasketaan tilin kaikkien Workerien pyyntö- ja suoritinaikakulut sisällytetyn käyttömäärän vähentämisen jälkeen. Kun esto tulee voimaan, Cloudflare hylkää uudet koodikutsut, joista syntyisi kuluja. Staattiset resurssit, jotka toimitetaan ilman Worker-koodin suorittamista, toimivat edelleen. Rajan soveltamisala kuvataan Workers-dokumentaatiossa.
Kuvitellaan tili, jolla on tuotantosovellus ja testikäyttöön tarkoitettu Worker. Jos testikuormitus nostaa Workers-kulut yhteisrajaan, esto voi vaikuttaa myös saman tilin tuotantokoodiin. Sovelluskohtaisia rajoja ei ole; vaikutusten eristämiseksi tiimi voi jakaa kyseiset kuormat eri tileille tai valita ilmoitukset, jos Workerin pysäyttäminen ei ole hyväksyttävää.
Durable Objectsin erilliseen rajaan lasketaan pyynnöt, suorituksen kesto, SQLite-rivien luku ja kirjoitus sekä avain-arvovaraston luku-, kirjoitus- ja poistotoiminnot. Se ei kata Workersia, Workers AI:ta, KV:tä, R2:ta eikä muita tuotteita. Jos sovellus riippuu useista palveluista, yksi raja suojaa vain vastaavaa osaa kuluista, ja yhden osan pysäyttäminen voi silti häiritä sovelluksen toimintaa.
Mitä kannattaa tarkistaa ennen eston käyttöönottoa?
Kartoita tilin riippuvuudet: mitkä sovellukset käyttävät Workersia, mitkä taustatehtävät käynnistävät ajastuksia tai jonoja ja mitkä palvelut kutsuvat Durable Objectseja. Päätä sitten, minkä tuotteiden automaattinen pysäytys on hyväksyttävää. Jos käyttökatko olisi kulujen ylittymistä pahempi, aseta ilmoituskynnys ilman estoa. Jos esto sopii tilanteeseen, valitse summa käsittelyviive, sisältyvät kiintiöt ja rajan ulkopuolelle jäävät kulut huomioiden.
Cloudflaren mukaan asetukset voi tehdä hallintapaneelissa, cf CLI:llä ja REST API:lla. API-käytäntöä luotaessa käytetään esimerkiksi kenttää threshold_cents senttimäärälle, kenttää product_id tuotteelle, kenttää action toiminnolle ja kenttää notification_email ilmoituksille; esimerkki on yrityksen julkistuksessa. Asetusten automatisointi ei muuta soveltamisalaa: raja koskee edelleen koko tuotetta tilillä.
Määritä myös palautumismenettely etukäteen. Jos esto halutaan poistaa ennen seuraavaa laskutuskautta, Cloudflare neuvoo nostamaan rajan kertyneitä kuluja suuremmaksi, poistamaan sen käytöstä tai poistamaan käytännön. Muutosten voimaantulossa voi kestää muutama minuutti; saman rajan käyttöönotto uudelleen ei nollaa kuluvan kauden kuluja.
Milloin tästä mekanismista on hyötyä?
Spend Management lisää automaattisen reaktion kulutuksen kasvuun: pelkän sähköpostin sijaan järjestelmä voi pysäyttää valitun tuotteen uudet tuetut toiminnot. Tilillä, jolla on testitehtäviä, se voi toimia suojana hallitsemattomalta kuormitukselta. Jos tilillä on useita kriittisiä palveluja, yhteinen raja kytkee budjettiin kaikkien tilin Workereiden tai Durable Objectsin saatavuuden.
Valinta riippuu siitä, kuinka suuri pysäytyksen haitta on. Jos toiminnan jatkuvuus on tärkeämpää, aloita ilmoituksista ja kulujen seurannasta. Jos tärkeämpää on rajoittaa käytön jatkumista, ota esto käyttöön riippuvuuksien tarkistamisen ja palautumissuunnitelman laatimisen jälkeen. Raja kannattaa nähdä tuotteen pysäytyskäytäntönä, ei lupauksena laskun täsmällisestä loppusummasta.
