Cumartesi sabahı saat 02.00. Cuma günü yayına aldığın fotoğraf uygulaması, çok geniş bir kitlesi olan biri tarafından az önce paylaşıldı. Yüklemeler birikiyor, fonksiyonlar milyonlarca kez tetikleniyor, veritabanı şimdiye kadar hiç çalışmadığı kadar yoruluyor. Sen uyuyorsun. Sabah uyandığında Azure maliyet yönetimi kurulumun bunu sana ya haber vermiş ya da vermemiş olacak. Aradaki farkı, on dakikada yapılabilecek birkaç ayar belirliyor.
Örnek olarak serinin ilk yazısındaki hayali fotoğraf paylaşım uygulamasını kullanıyorum. Anlattığım kurgu gerçek bir şirketin altyapısını yansıtmıyor, sadece üzerinden geçeceğimiz bir gece sağlıyor.
Bütçe bir duman alarmıdır, devre kesici değil
Azure bütçesi bildirim gönderir. Kaynakları durdurmaz, dağıtımları engellemez, harcamaya tavan koymaz. Kullandıkça öde aboneliklerinde harcama limiti diye bir özellik de yoktur. Yani 20 dolarlık bir bütçe, e-posta tetikleyen bir rakamdan ibarettir.
Ücretsiz hesap bu konuda ayrıcalıklı. Kredi tutarına eşit yerleşik bir harcama limiti var ve tutarı değiştirilemez. Limite ulaşıldığında dağıtılan kaynaklar üretimden kaldırılır, sanal makineler durdurulur ve serbest bırakılır. Kullandıkça öde planına geçilince bu limit kalkar.
Yani plana geçtiğin gün, sert bir durdurmayı bir alarmla takas etmiş olursun. Bütçenin “sonra” değil, geçişin yapıldığı ana ait olmasının sebebi bu.
Alarm geç çalar
Faturalama verisi gerçek zamanlı akmaz. Pahalı tek bir dakikanın sana haber verilene kadar izlediği yol şöyle.
| Adım | Ne zaman |
|---|---|
| Uygulama bir hizmeti kullanır | Anında |
| Kullanım kaydı Cost Management’a ulaşır | Genellikle 8 ile 24 saat içinde |
| Bütçe bu veriye göre değerlendirilir | Günlük döngüyle |
| Uyarı e-postası gönderilir | Değerlendirmeden sonra |
Bazı kaynaklar kullandıkça öde aboneliklerinde daha uzun gecikmeler bildiriyor, bu yüzden bir günü asgari süre saymak gerekir. Kurgumuzda artış saat 02.00’de başlıyor ve ilk e-posta pazar gününe kalabilir. Harcama bu sürenin tamamında devam eder.
Pratik sonuç şu. İlk uyarı, canını yakacak tutarın epey altına konur. E-posta okunduğunda gerçek rakam çoktan yükselmiştir.
İlk bütçeyi kurmak
Portaldaki yol kısa.
- Cost Management açılır, Budgets ve ardından Add seçilir.
- Kapsam seçilir. Abonelik bütçesi her şeyi kapsar. Kaynak grubu bütçesi, ilk yazıdaki deneme alışkanlığına uyar.
- Aylık sıfırlanma ve biraz can yakacak bir tutar belirlenir. Burada anlatım için 20 dolar kullanıyorum.
- Gerçek maliyet için yüzde 50 ve 90, tahmini maliyet için yüzde 100 uyarı koşulları eklenir.
- E-posta ve istenirse uyandırması için SMS içeren bir eylem grubu (action group) bağlanır.
Gerçek ve tahmini uyarılar farklı sorulara cevap verir. Gerçek uyarı, Azure’ın o ana kadar kaydettiği harcamayı sayar. Tahmini uyarı ise çizgiyi geçeceğini öngörür ve sen geçmeden önce çalabilir.
İlk günle ilgili bir zamanlama detayı var. Yepyeni bir abonelikte Cost Management özelliklerinin kullanılabilir hale gelmesi 48 saate kadar sürebilir. Bu yüzden ayar ikinci ya da üçüncü günde yapılır, hiç yapılmamaz.
Bütçenin kendisi CLI ile de oluşturulabilir. consumption komut grubu hâlâ önizleme (preview) olarak işaretli.
az consumption budget create --budget-name photoapp-monthly --category cost --amount 20 --time-grain monthly --start-date 2026-11-01 --end-date 2027-10-31
Başlangıç tarihi bir ayın ilk günü olmalı. Uyarı kurallarını, eşiklerin ve eylem grubunun tek ekranda durduğu portalda ekliyorum.
Alarmdan tepkiye
Eylem grubu, bildirimi tepkiye dönüştüren parçadır. E-posta ve SMS’in yanı sıra webhook, Logic App, Azure Function ya da Automation runbook çağırabilir. Microsoft’un belgelediği bir senaryoda bütçe yüzde 100’e ulaşınca bir runbook sanal makineleri durduruyor.
Fotoğraf uygulaması için bu, yüzde 90’da bir uyarı ve yüzde 100’de kritik olmayan makineleri serbest bırakan bir fonksiyon olabilir.
Bunu garanti değil, güvenlik ağı olarak görmek gerekir. Hesaplama kaynağını durdurmak her şeyi durdurmaz, çünkü diskler, depolama ve veritabanları faturalanmaya devam eder. Veri geç geldiği için tepki de geç gelir.
Anomali uyarıları bütçenin kaçırdığını yakalar
Bütçe, toplam çizgiyi geçtiğinde çalar. Ayın üçüncü gününde başlayan bir artış, toplam o noktaya gelene kadar bir hafta boyunca fark edilmeden yanabilir.
Anomali uyarıları ise örüntüye bakar. Azure günlük harcamayı olağan eğilimle karşılaştırır ve olağandışı sıçramayı işaretler. Abonelik kapsamında Cost alerts altında oluşturulur, Cost Management Contributor ya da daha yüksek bir rol gerektirir ve e-posta yalnızca bir kez, tespit anında gönderilir.
İki araç birbirini tamamlar. Bütçe aylık toplamı korur, anomali uyarısı da kötü bir günün şeklini.
Tavanı mimariye koymak
Uyarılar tepki verir, tavan önler. İlk yazıda ücretsiz katmanlarla eşleştirdiğimiz hizmetlerden ikisinde tavan koymak mümkün.
- Azure Functions. Consumption ve Elastic Premium planlarında
functionAppScaleLimitayarı, bir uygulamanın en fazla kaç örneğe ölçeklenebileceğini sınırlar. Flex Consumption planında varsayılan sınır 100 örnektir ve değiştirilebilir. - Cosmos DB. Hesap genelinde sağlanan toplam verim (throughput) sınırlanabilir, böylece yavaş yavaş artan bir değer maliyeti seçtiğin sayının üstüne taşıyamaz.
az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP_NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>
Tavanın bir bedeli var. Viral gece geldiğinde sınırlanmış hizmetler yavaşlar ya da işi reddetmeye başlar ve kullanıcılar bunu hisseder. Asıl karar, o gecede neyi kaybetmeyi tercih edeceğindir. Birkaç dakikalık hızı mı, yoksa ayın bir kısmını mı. İki cevap da makul. Karar vermemek ise para kaybettiren seçenek.
Diğer bulutlarda durum
Duman alarmı fikri evrensel. Değişen, platformun bundan sonra neler yapabildiği.
| Sağlayıcı | Uyarılar | Kendi başına harekete geçme |
|---|---|---|
| Azure | Gerçek ve tahmini uyarılı bütçeler, ayrıca anomali uyarıları | Yalnızca eylem grupları ve kendi otomasyonunla |
| AWS | Gerçek ve tahmini uyarılı bütçeler, en fazla 10 e-posta adresine ve bir SNS konusuna | Yerleşik bütçe eylemleri bir IAM politikası ya da SCP uygulayabilir veya belirli EC2 ve RDS örneklerini durdurabilir, otomatik ya da onayla |
| Google Cloud | Eşik uyarılı bütçeler | Pub/Sub ile bir fonksiyon projede faturalamayı kapatabilir ve bu, projedeki tüm hizmetleri sonlandırır. Yeni harcama sınırı (spend cap) bütçeleri de uygun hizmetlerin kullanımını duraklatabilir |
| DigitalOcean | Aylık bütçenin yüzde eşiklerinde harcama uyarıları | E-posta bildirimi, eşik aşıldıktan sonra bir saat içinde gönderilir |
Bütçenin içine yerleşik tepki sunan tek sağlayıcı dört arasında AWS. En hızlı ritim ise DigitalOcean’da, uyarıları bir saat içinde gelirken Azure günlük döngüyle çalışıyor. Bunlara güvenmeden önce her sağlayıcının güncel belgesine bakmak gerekir, çünkü bu özellikler sık değişiyor.
Akılda kalacaklar
Dört alışkanlık riskin büyük kısmını karşılar.
- Plana geçmeden önce aylık bütçe oluşturulur, gerçek uyarılar yüzde 50 ve 90’da, tahmini uyarı yüzde 100’de.
- Abonelik üzerine bir anomali uyarısı eklenir.
- Functions ölçeklenmesi ve Cosmos DB verimi sınırlanır, böylece viral gece fatura yerine yavaşlık olarak yaşanır.
- Her uyarı dünden gelen bir mesaj gibi okunur.
Bir sonraki yazıda aynı fotoğraf yüklemesini Azure Functions içinde takip ediyorum, ölçek sınırının nereye oturduğuyla birlikte.
Tüm projelerim ve üzerinde çalıştığım konuları incelemek istersen https://hub.barisgunduz.com/ adresini ziyaret edebilirsin.
