Michael JohnsonЧи можна обмежити витрати на хмарні обчислення, не ризикуючи зупинити робочий застосунок? У Cloudflare тепер доступні обидва варіанти налаштування, але жорсткий ліміт працює як вимикач для продукту на рівні акаунта: після досягнення порога він блокує нові операції, на які поширюється дія ліміту. Водночас сам поріг не гарантує максимальної суми в рахунку.
13 листопада 2026 року Cloudflare оголосила про запуск Spend Management для клієнтів Pay-as-you-go. На старті ліміти та сповіщення доступні для Workers і Durable Objects. Це автоматичний запобіжник від неочікуваного зростання споживання — за умови, що команда розуміє, які сервіси потраплять під одну спільну зупинку, як пояснює Cloudflare.
Що змінилося порівняно зі сповіщенням про витрати?
Сповіщення повідомляє, що витрати досягли вибраного рівня, а продукт продовжує працювати. Жорсткий ліміт блокує операції, на які він поширюється. У Spend Management для кожного продукту задається окрема політика: сума ліміту, пороги сповіщень і, за потреби, адреса електронної пошти. Ліміти Workers і Durable Objects незалежні один від одного й охоплюють увесь відповідний продукт в акаунті. Налаштувати поріг для одного Worker, окремого простору імен Durable Objects або однієї метрики не можна, згідно з документацією Cloudflare.
Практичний вибір простий: сповіщення доречне, коли важливіша доступність, а блокувальний ліміт — коли команда готова зупинити операції продукту, на які він поширюється, щоб обмежити подальше споживання.
Чому ліміт не спрацьовує точно на заданій сумі?
Облік витрат і поширення блокування не відбуваються миттєво. Cloudflare зазначає, що панель показує витрати майже в реальному часі — із затримкою менш ніж 10 хвилин; водночас механізм розрахунку вартості не перевіряє кожен запит. Політика поширюється на вузли мережі асинхронно, а середовище виконання застосовує її під час періодичного оновлення локального стану. Так Cloudflare пояснює принцип роботи Spend Management.
Отже, встановлений поріг — це точка, після якої має початися блокування, а не жорстка верхня межа підсумкового рахунку. Поки витрати обліковуються, а правило поширюється, операції можуть тривати. Деякі нарахування також не входять до ліміту: наприклад, абонентська плата Workers Paid виключена, а збережені дані Durable Objects можуть і далі створювати витрати після паузи. Cloudflare попереджає, що остаточну суму буде вказано в рахунку.
Яку частину застосунку зупинить ліміт Workers?
Ліміт Workers об’єднує витрати на запити й час CPU усіх Workers акаунта після вирахування включеного обсягу. Коли блокування набуває чинності, Cloudflare відхиляє нові виклики коду, що створюють витрати. Статичні ресурси, які обслуговуються без запуску коду Worker, продовжують працювати. Так сферу дії описано в документації Workers.
Уявіть акаунт із робочим застосунком і тестовим Worker. Якщо тестове навантаження доведе загальні витрати Workers до порога, блокування може зачепити й робочий код у тому самому акаунті. Окремого ліміту для кожного застосунку немає; щоб ізолювати наслідки, команда може розділити відповідні навантаження між акаунтами або вибрати сповіщення, якщо зупинка Workers неприпустима.
Окремий ліміт Durable Objects враховує запити, тривалість виконання, читання та запис рядків SQLite, а також операції читання, запису й видалення у сховищі key-value. Він не охоплює Workers, Workers AI, KV, R2 та інші продукти. Якщо застосунок залежить одразу від кількох сервісів, один ліміт захищає лише відповідну частину витрат, а зупинка однієї ланки все одно може порушити роботу застосунку.
Що перевірити перед увімкненням блокування?
Складіть карту залежностей акаунта: які застосунки використовують Workers, які фонові завдання запускають розклади або черги та які сервіси викликають Durable Objects. Потім визначте, для яких продуктів допустима автоматична зупинка. Якщо збій гірший за перевитрату, налаштуйте поріг сповіщення без блокування. Якщо блокування прийнятне, виберіть суму з урахуванням затримки обробки, включених квот і витрат, які ліміт не охоплює.
Cloudflare описує налаштування через панель керування, cf CLI та REST API. Наприклад, під час створення політики в API використовуються поле threshold_cents для суми в центах, product_id для продукту, action для дії та notification_email для сповіщень; приклад наведено в анонсі компанії. Автоматизація налаштування не змінює сферу дії: ліміт залишається спільним для продукту в акаунті.
Заздалегідь визначте й процедуру відновлення. Щоб скасувати зупинку до наступного платіжного періоду, Cloudflare пропонує підвищити ліміт вище за накопичені витрати, вимкнути його або видалити політику. Зміни можуть набувати чинності протягом кількох хвилин; повторне ввімкнення того самого ліміту не обнуляє витрати поточного періоду.
Коли цей механізм корисний?
Spend Management додає автоматичну реакцію на зростання споживання: замість самого лише листа система може зупинити нові операції вибраного продукту, на які поширюється ліміт. Для акаунта з тестовими завданнями це може стати запобіжником від неконтрольованого навантаження. Для акаунта з кількома критично важливими сервісами спільний поріг пов’язує бюджет і доступність усіх Workers або всіх Durable Objects в акаунті.
Рішення залежить від того, якою ціною обернеться зупинка. Якщо важливіша безперервність роботи, почніть зі сповіщень і спостереження за витратами. Якщо важливіше обмежити подальше використання, вмикайте блокування після перевірки залежностей і підготуйте процедуру відновлення. Поріг варто планувати як політику зупинки продукту, а не як обіцянку точної суми рахунку.
