Michael JohnsonCzy można ograniczyć wydatki na obliczenia w chmurze, nie ryzykując zatrzymania działającej aplikacji? Cloudflare udostępnia teraz oba warianty konfiguracji, ale twardy limit działa jak wyłącznik dla produktu na poziomie konta: po osiągnięciu progu blokuje nowe obsługiwane operacje. Sam próg nie gwarantuje przy tym maksymalnej kwoty na rachunku.
13 listopada 2026 roku Cloudflare ogłosił uruchomienie Spend Management dla klientów korzystających z planu Pay-as-you-go. Na początku limity i powiadomienia są dostępne dla Workers i Durable Objects. To automatyczne zabezpieczenie przed nieoczekiwanym wzrostem wykorzystania — pod warunkiem, że zespół rozumie, które usługi obejmie wspólne zatrzymanie, jak wyjaśnia Cloudflare.
Co się zmieniło w porównaniu z powiadomieniem o wydatkach?
Powiadomienie informuje, że wydatki osiągnęły wybrany poziom, ale produkt nadal działa. Twardy limit blokuje obsługiwane operacje. W Spend Management dla każdego produktu ustawia się osobną politykę: kwotę limitu, progi powiadomień oraz — opcjonalnie — adres e-mail. Limity Workers i Durable Objects są od siebie niezależne i obejmują cały dany produkt na koncie. Nie można ustawić progu dla pojedynczego Workera, osobnej przestrzeni nazw Durable Objects ani jednej metryki, zgodnie z dokumentacją Cloudflare.
Praktyczny wybór jest prosty: powiadomienie sprawdzi się wtedy, gdy ważniejsza jest dostępność, a limit blokujący — gdy zespół jest gotowy zatrzymać obsługiwane operacje produktu, by ograniczyć dalsze wykorzystanie.
Dlaczego limit nie uruchamia się dokładnie przy ustawionej kwocie?
Rozliczanie wydatków i rozpropagowanie blokady nie następują natychmiast. Cloudflare opisuje panel jako prezentujący wydatki niemal w czasie rzeczywistym — z opóźnieniem krótszym niż 10 minut; silnik naliczania kosztów nie znajduje się jednak na ścieżce każdego żądania. Polityka jest asynchronicznie rozsyłana do węzłów sieci, a środowisko uruchomieniowe stosuje ją podczas okresowego odświeżania lokalnego stanu. Tak Cloudflare opisuje działanie Spend Management.
Ustawiony próg jest więc punktem, od którego blokada powinna zacząć działać, a nie twardą górną granicą końcowego rachunku. Zanim wydatki zostaną rozliczone, a reguła rozpropagowana, operacje mogą być nadal wykonywane. Niektóre opłaty również nie są objęte limitem: na przykład abonament Workers Paid jest wyłączony, a przechowywane dane Durable Objects mogą generować koszty także po wstrzymaniu. Cloudflare ostrzega, że ostateczną kwotę pokazuje rachunek.
Jaką część aplikacji zatrzyma limit Workers?
Limit Workers obejmuje wydatki na żądania i czas CPU wszystkich Workers na koncie, po odjęciu uwzględnionego pakietu. Gdy blokada zacznie działać, Cloudflare odrzuca nowe wywołania kodu generujące koszty. Zasoby statyczne obsługiwane bez uruchamiania kodu Workera nadal działają. Zakres działania opisano w dokumentacji Workers.
Wyobraźmy sobie konto z aplikacją produkcyjną i testowym Workerem. Jeśli obciążenie testowe podniesie łączne wydatki na Workers do progu, blokada może objąć także kod produkcyjny na tym samym koncie. Nie da się ustawić osobnych limitów dla poszczególnych aplikacji; aby odizolować skutki, zespół może rozdzielić odpowiednie obciążenia między konta albo wybrać powiadomienia, jeśli zatrzymanie Workers jest niedopuszczalne.
Osobny limit Durable Objects obejmuje żądania, czas działania, odczyt i zapis wierszy SQLite oraz operacje odczytu, zapisu i usuwania w magazynie klucz-wartość. Nie obejmuje Workers, Workers AI, KV, R2 ani innych produktów. Jeśli aplikacja zależy od kilku usług, jeden limit chroni tylko odpowiadającą mu część wydatków, a zatrzymanie jednego elementu nadal może zakłócić działanie aplikacji.
Co sprawdzić przed włączeniem blokady?
Przygotuj mapę zależności na koncie: które aplikacje korzystają z Workers, które zadania w tle uruchamiają harmonogramy lub kolejki i które usługi wywołują Durable Objects. Następnie zdecyduj, w przypadku których produktów automatyczne zatrzymanie jest dopuszczalne. Jeśli awaria jest gorsza niż przekroczenie budżetu, ustaw próg powiadomienia bez blokady. Jeśli blokada jest akceptowalna, wybierz kwotę z uwzględnieniem opóźnienia przetwarzania, uwzględnionych limitów i kosztów wyłączonych z naliczania.
Cloudflare opisuje konfigurację za pomocą panelu sterowania, cf CLI i REST API. Na przykład przy tworzeniu polityki w API używa się pola threshold_cents dla kwoty w centach, product_id dla produktu, action dla działania i notification_email dla powiadomień; przykład znajduje się w ogłoszeniu firmy. Automatyzacja konfiguracji nie zmienia zakresu działania: limit pozostaje wspólny dla danego produktu na koncie.
Z góry ustal również procedurę przywracania działania. Aby zdjąć blokadę przed rozpoczęciem kolejnego okresu rozliczeniowego, Cloudflare zaleca podniesienie limitu powyżej skumulowanych wydatków, wyłączenie go albo usunięcie polityki. Zmiany mogą zacząć obowiązywać po kilku minutach; ponowne włączenie tego samego limitu nie zeruje wydatków z bieżącego okresu.
Kiedy ten mechanizm jest przydatny?
Spend Management dodaje automatyczną reakcję na wzrost wykorzystania: zamiast samej wiadomości e-mail system może zatrzymać nowe obsługiwane operacje wybranego produktu. Dla konta z zadaniami testowymi może to być zabezpieczenie przed niekontrolowanym obciążeniem. Na koncie z kilkoma krytycznymi usługami wspólny limit wiąże budżet z dostępnością wszystkich Workers albo wszystkich Durable Objects na koncie.
Decyzja zależy od tego, jaki koszt zatrzymania jest akceptowalny. Jeśli ważniejsza jest ciągłość działania, zacznij od powiadomień i monitorowania wydatków. Jeśli ważniejsze jest ograniczenie dalszego wykorzystania, włącz blokadę po sprawdzeniu zależności i przygotuj procedurę przywracania. Próg należy planować jako politykę zatrzymania produktu, a nie obietnicę dokładnej kwoty na rachunku.
