Bulut bilişim harcamalarını, çalışan bir uygulamayı durdurma riski almadan sınırlamak mümkün mü? Cloudflare artık iki yapılandırma seçeneğini de sunuyor; ancak katı sınır, hesap düzeyinde ürün için bir kapatma düğmesi gibi çalışıyor: eşiğe ulaşıldığında desteklenen yeni işlemleri engelliyor. Buna rağmen belirlenen eşik, faturadaki azami tutarı garanti etmiyor.

13 Kasım 2026’da Cloudflare, Pay-as-you-go müşterileri için Spend Management’ı kullanıma sunduğunu duyurdu. Başlangıçta Workers ve Durable Objects için sınırlar ve bildirimler kullanılabiliyor. Bu, ekibin hangi hizmetlerin tek bir ortak durdurma kapsamına gireceğini anlaması koşuluyla, tüketimde beklenmedik bir artışa karşı otomatik bir önlem sunuyor; Cloudflare’ın açıklaması da bunu belirtiyor.
Harcama bildirimiyle karşılaştırıldığında ne değişti?
Bildirim, harcamaların seçilen düzeye ulaştığını bildirir; ürün çalışmaya devam eder. Katı sınır ise desteklenen işlemleri engeller. Spend Management’ta her ürün için ayrı bir politika belirlenir: sınır tutarı, bildirim eşikleri ve yapılandırılmışsa bir e-posta adresi. Workers ve Durable Objects sınırları birbirinden bağımsızdır ve hesaptaki ilgili ürünün tamamını kapsar. Cloudflare belgelerine göre tek bir Worker, ayrı bir Durable Objects ad alanı ya da tek bir ölçüm için eşik belirlenemez.
Pratikte tercih basit: kullanılabilirlik daha önemliyse bildirimleri; ekip tüketimin daha fazla artmasını önlemek için üründeki desteklenen işlemleri durdurmaya hazırsa engelleyici sınırı seçin.
Sınır neden belirlenen tutarda tam olarak devreye girmiyor?
Harcamaların izlenmesi ve engellemenin yayılması anında gerçekleşmez. Cloudflare, panelde harcamaların neredeyse gerçek zamanlı, yani 10 dakikadan kısa gecikmeyle görüntülendiğini belirtiyor; ancak fiyatlandırma motoru her isteğin işlenme yolunda yer almıyor. Politika ağ düğümlerine eşzamansız biçimde yayılıyor ve çalışma ortamı bu politikayı yerel durumu periyodik olarak güncellediğinde uyguluyor. Cloudflare, Spend Management’ın çalışma mekanizmasını böyle açıklıyor.

Bu nedenle belirlenen eşik, nihai faturanın katı üst sınırı değil, engellemenin başlaması gereken noktadır. Harcamalar izlenirken ve kural yayılırken işlemler devam edebilir. Ayrıca bazı ücretler sınıra dahil değildir: örneğin Workers Paid abonelik ücreti kapsam dışıdır ve Durable Objects’te saklanan veriler duraklatmadan sonra da ücret oluşturmaya devam edebilir. Cloudflare, nihai tutarı faturanın gösterdiği konusunda uyarıyor.
Workers sınırı uygulamanın hangi bölümünü durdurur?
Workers sınırı, dahil edilen kullanım miktarı düşüldükten sonra hesaptaki tüm Workers’ın istek ve CPU süresi harcamalarını bir araya getirir. Engelleme yürürlüğe girdiğinde Cloudflare, maliyet oluşturan kodun yeni çağrılarını reddeder. Worker kodu çalıştırılmadan sunulan statik kaynaklar çalışmaya devam eder. Workers belgeleri kapsamı böyle tanımlıyor.
Üretim uygulaması ve test amaçlı bir Worker içeren bir hesap düşünün. Test yükü toplam Workers harcamasını eşiğe çıkarırsa engelleme aynı hesaptaki üretim kodunu da etkileyebilir. Sınırı ayrı uygulamalara göre bölmek mümkün değildir; etkileri yalıtmak için ekip ilgili yükleri farklı hesaplara ayırabilir veya Workers’ın durması kabul edilemezse bildirimleri tercih edebilir.
Durable Objects için ayrı sınır; istekleri, çalışma süresini, SQLite satırlarının okunup yazılmasını ve key-value depolama alanındaki okuma, yazma ve silme işlemlerini hesaba katar. Workers, Workers AI, KV, R2 ve diğer ürünleri kapsamaz. Uygulama birden fazla hizmete bağlıysa tek bir sınır harcamaların yalnızca ilgili bölümünü korur; buna rağmen bir bileşenin durması uygulamanın çalışmasını aksatabilir.
Engellemeyi etkinleştirmeden önce neleri kontrol etmeli?
Hesabınızdaki bağımlılıkların haritasını çıkarın: Hangi uygulamalar Workers kullanıyor, hangi arka plan işleri zamanlanmış görevleri veya kuyrukları başlatıyor ve hangi hizmetler Durable Objects’i çağırıyor? Ardından hangi ürünlerin otomatik olarak durdurulmasının kabul edilebilir olduğuna karar verin. Kesinti, fazla harcamadan daha kötüyse engelleme olmadan bildirim eşiği ayarlayın. Engelleme kabul edilebilirse gecikmeyi, dahil edilen kotaları ve sınırın kapsam dışı bıraktığı harcamaları hesaba katarak bir tutar belirleyin.
Cloudflare, yapılandırmanın kontrol paneli, cf CLI ve REST API üzerinden yapılabildiğini belirtiyor. Örneğin API’de politika oluştururken tutar için threshold_cents, ürün için product_id, yapılacak işlem için action ve bildirimler için notification_email alanları kullanılıyor; örnek şirketin duyurusunda yer alıyor. Yapılandırmayı otomatikleştirmek kapsamı değiştirmez: sınır, hesap genelinde ürünün tamamına uygulanmaya devam eder.
Önceden bir kurtarma prosedürü de belirleyin. Bir sonraki faturalandırma dönemini beklemeden durdurmayı kaldırmak için Cloudflare, sınırı birikmiş harcamaların üzerine çıkarmayı, sınırı devre dışı bırakmayı veya politikayı silmeyi öneriyor. Değişikliklerin yürürlüğe girmesi birkaç dakika sürebilir; aynı sınırın yeniden etkinleştirilmesi mevcut dönemdeki harcamaları sıfırlamaz.
Bu mekanizma ne zaman işe yarar?
Spend Management, tüketim artışına otomatik bir tepki ekliyor: sistem yalnızca e-posta göndermek yerine, seçilen üründeki desteklenen yeni işlemleri durdurabiliyor. Test işleri bulunan bir hesap için bu, kontrolsüz yük artışına karşı bir önlem olabilir. Birden fazla kritik hizmetin bulunduğu hesapta ise ortak sınır, bütçeyi ve kullanılabilirliği hesaptaki tüm Workers’lara ya da tüm Durable Objects’lere bağlar.
Karar, durdurmanın kabul edilebilir maliyetine bağlıdır. Hizmet sürekliliği daha önemliyse bildirimlerle başlayıp harcamaları izleyin. Daha fazla kullanımı sınırlamak öncelikliyse bağımlılıkları kontrol ettikten sonra engellemeyi etkinleştirin ve kurtarma hazırlığı yapın. Eşik, faturada kesin bir tutar vaadi olarak değil, ürünü durdurma politikası olarak planlanmalıdır.