Bulut faturası neden her ay büyüyor? İsrafı bulma, ölçme ve kalıcı düşürme

Kısa cevap: fatura büyüyor çünkü israf tek bir kalemde toplanmıyor ve sayıyı kimse sahiplenmiyor. Flexera'nın 2026 State of the Cloud raporu IaaS ve PaaS harcamasının yüzde 29'unun boşa gittiğini söylüyor; bu oran beş yıllık düşüşün ardından 2025'teki yüzde 27'den yukarı döndü. Datadog'un ölçümlerinde konteyner harcamasının yüzde 83'ü boş duran kaynaklara gidiyor. Yani mesele genelde "pahalı bir servis seçtik" değil, "ayırdığımız kapasitenin çoğunu kullanmıyoruz ve bunu kimse görmüyor". Doğru sıra da bu yüzden kesintiyle başlamıyor: önce harcamayı ekiplere ve ürünlere bölün, sonra en büyük üç kalemi düzeltin, taahhüt indirimini en sona bırakın. Ters sırada çalışan ekipler israfı üç yıllık sözleşmeyle kilitliyor.

Sayı kimin sorumluluğunda

Maliyeti düşüren ilk adım teknik değil, muhasebe. Her kaynağın bir sahibi yoksa raporda gördüğünüz şey tek bir büyük sayıdır ve tek bir büyük sayı üzerinden karar verilemez. Etiketleme (tagging) sıkıcı iş olduğu için hep sonraya kalıyor, oysa geri kalan her şeyin ön koşulu.

Pratikte işe yarayan kural şu: etiket zorunluluğunu altyapı kodunun içine koyun, elle açılan kaynağı reddedin, etiketsiz harcamayı da bir ekibe değil doğrudan platform ekibine yazın. O rakam görünür olduğu an temizlenir. FinOps Foundation'ın 2026 State of FinOps raporu, 1.192 katılımcı ve 83 milyar doların üzerinde yıllık bulut harcamasıyla, bu işi yapan ekiplerin yüzde 78'inin CTO ya da CIO'ya bağlı olduğunu gösteriyor; 2023'e göre 18 puanlık artış. Maliyet finans departmanının değil, mühendisliğin metriği haline geldi.

En büyük kalem genelde boş duran kapasite

Datadog'un verisinde Kubernetes kümeleri ortalama yüzde 10 CPU ve yüzde 20 bellek kullanımıyla çalışıyor. Konteyner harcamasının yüzde 83'ü boşa giderken bunun yüzde 54'ü küme boşluğu (fazla ayrılmış düğüm kapasitesi), yüzde 29'u iş yükü boşluğu (ihtiyaçtan büyük kaynak talepleri). Konteynerler aynı ölçümde EC2 harcamasının yüzde 35'ini oluşturuyor.

Mekanizma basit ve tam da bu yüzden sinsi. Kubernetes düğüm ayırırken gerçek kullanımınıza değil, requests alanında yazdığınız sayıya bakar. O sayı çoğu ekipte bir kez, üretime çıkarken, görülmüş en yüksek tepe değerinin üzerine biraz pay eklenerek yazılır ve bir daha açılmaz. Sonuçta hiç kullanılmayan kapasite için düğüm satın alıyorsunuz. Düzeltme yolu da aynı yerden geçiyor: birkaç haftalık gerçek kullanım verisinden p95 değerini alın, CPU taleplerini ona yakınsatın, bellek tarafında limiti korumaya devam edin çünkü bellek sıkışması sürecin öldürülmesiyle sonuçlanır. CPU tarafını fazla kısarsanız kısıtlamaya (throttling) girersiniz, o yüzden değişiklikten önce ve sonra gecikme grafiğine bakın. Otomatik ölçekleme, kapasiteyi talebe göre büyütüp küçültme işini üstlenir, ama yanlış requests değerini düzeltmez; yanlış sayıyı daha hızlı çoğaltır.

Taahhüt indirimi ucuz para, ama yanlış sırada pahalı

Rakamlar cazip. AWS'in Compute Savings Plans ürünü talep üzerine fiyatlara göre yüzde 66'ya, belirli bir örnek ailesine bağlanan EC2 Instance Savings Plans yüzde 72'ye kadar indirim veriyor; kesintiye dayanabilen iş yükleri için Spot fiyatlarında indirim yüzde 90'a kadar çıkıyor (karşılığında iki dakikalık kesinti uyarısını kabul ediyorsunuz).

Sorun indirimde değil, sırada. Fazla boyutlandırılmış bir filoyu üç yıllık taahhütle satın aldığınızda israfı sabitlemiş oluyorsunuz. Doğru sıra: önce boyutlandırmayı düzeltin, iki üç hafta oturmasını bekleyin, sonra taban yükünüzü taahhüde bağlayın, dalgalanan kısmı talep üzerine ve Spot'ta bırakın. Aynı Datadog verisinde kuruluşların yüzde 67'si taahhüt bazlı indirim kullanıyor (bir önceki yıl yüzde 72) ve yalnızca yüzde 29'unun taahhüdü uygun harcamanın yarısından fazlasını kapsıyor. İkinci tuzak mimari yönlü: Arm tarafına geçmeyi düşünüyorsanız x86 örnek ailesine üç yıllık bağlanmak o geçişi pahalılaştırır. AWS, Graviton tabanlı örneklerin benzer x86 örneklerinden yüzde 20'ye kadar daha düşük maliyetli olduğunu ve aynı performans için yüzde 60'a kadar daha az enerji harcadığını söylüyor. Datadog'un ölçümünde Arm örnekleri EC2 hesaplama harcamasının yüzde 18'ine ulaşmış, bir yılda iki katına çıkmış.

Ağ trafiği, faturanın kimsenin okumadığı yarısı

Veri transferi kalemi hesap özetinde tek satır göründüğü için genelde atlanıyor. İçini açtığınızda mimari kararların bedelini görüyorsunuz. AWS'te internete çıkan trafiğin ilk 100 GB'ı tüm servisler ve bölgeler toplamında ücretsiz, sonrasında yaklaşık 10 TB'a kadar GB başına 0,09 dolar, sonraki 40 TB'ta 0,085 dolar. Bölgeler arası değil, aynı bölgedeki erişilebilirlik alanları (AZ) arasındaki trafik ise her iki yönde GB başına 0,01 dolar. Küçük bir sayı gibi duruyor. Datadog'un verisinde kuruluşların yüzde 98'i bu kalemi ödüyor ve AZ'ler arası trafik toplam veri transferi maliyetinin neredeyse yarısını oluşturuyor.

Üstüne NAT Gateway ekleniyor: her erişilebilirlik alanında saatlik 0,045 dolar, artı işlenen her GB için 0,045 dolar. Yani özel alt ağdaki bir servis paket deposundan bağımlılık indirdiğinde bunun bir fiyatı var. Somut düzeltmeler şunlar: konuşkan servisler arası trafiği ve veritabanı replika trafiğini mümkün olduğunca tek AZ içinde tutun (erişilebilirlik takasını bilerek yapın), S3 ve DynamoDB için gateway tipi VPC uç noktası tanımlayın çünkü bu uç noktalarda saatlik ya da veri işleme ücreti yok, statik içeriği CDN arkasına alın. Bunların hiçbiri fatura ekranındaki bir ayar değil, hepsi mimari değişikliği.

Depolamada karar fiyat sınıfı değil, yaşam döngüsü

Nesne depolamada ucuz sınıfa geçmek her zaman kazanç değildir. Standard-IA ve One Zone-IA en az 30 gün, Glacier Instant ve Flexible Retrieval 90 gün, Deep Archive 180 gün üzerinden ücretlendirilir. Yedi gün sonra silinen milyonlarca küçük nesneyi arşiv sınıfına taşıyan bir yaşam döngüsü kuralı, geçiş isteklerinin ve asgari süre ücretinin toplamıyla faturayı yükseltir. Kural yazmadan önce nesne boyutu dağılımına ve gerçek saklama süresine bakmak gerekiyor.

Blok depolamada ise bedava para masada duruyor. gp3 birim fiyatı gp2'den yaklaşık yüzde 20 düşük ve dönüşüm kesintisiz yapılabiliyor, buna rağmen Datadog'un ölçümünde gp2 hâlâ EBS harcamasının yüzde 58'i. Bir de sahipsiz kalanlar var: silinen sunucunun arkasında kalan bağlanmamış diskler, projesi kapanmış ortamların anlık görüntüleri, kimsenin bakmadığı 400 günlük log saklama politikası. Hepsi tam fiyattan faturalanmaya devam ediyor.

Kimsenin sahiplenmediği küçük kalemler

1 Şubat 2024'ten beri AWS her genel IPv4 adresi için saatte 0,005 dolar alıyor ve bu ücret adres bir servise bağlı olsun ya da boşta dursun işliyor. Tek adres için ayda yaklaşık 3,65 dolar. Eski projelerden kalma 200 adresiniz varsa yılda 8.700 dolar civarı, karşılığında hiçbir şey almadan.

Aynı sepette duran diğer kalemler: arkasında hedef kalmamış yük dengeleyiciler, kapatılmamış test kümeleri ve hafta sonu da çalışan geliştirme ortamları. Bir hafta 168 saat; geliştirme ortamı gerçekte 50 saat kullanılıyorsa, mesai dışında kapatmak o kalemin saatlerinin yüzde 70'ini siliyor. Bu tür temizliğin güzel yanı, mimariye dokunmadığı için risksiz olması. Kötü yanı, tek seferlik olması: altı ay sonra liste yeniden dolar, o yüzden aylık bir kontrol işine bağlamak gerekiyor.

Yeni israf kalemi yapay zekâ harcaması

State of FinOps 2026'ya göre katılımcıların yüzde 98'i artık yapay zekâ harcamasını da yönetiyor; bu oran 2025'te yüzde 63, 2024'te yüzde 31'di. Aynı ankette en çok istenen tek yetenek, jeton (token), model istekleri ve GPU kullanımı düzeyinde ayrıntılı harcama görünürlüğü ve rapor bu ihtiyacın ticari araçlarla ölçekte karşılanamadığını söylüyor. Datadog'un ölçümünde GPU örnekleri EC2 hesaplama harcamasının yüzde 14'üne çıkmış durumda.

Pratik sonucu şu: sağlayıcı size özellik bazında dağılım vermeyecek, o yüzden ölçümü uygulamanın içine koyun. Her model çağrısında model adını, girdi ve çıktı jeton sayısını, özelliği ve müşteri kimliğini kendi log kaydınıza yazın; rapor oradan çıkar. Fiyatı düşüren üç hamle bilinen türden: tekrar eden istemleri önbelleğe alın, kolay işi küçük modele yönlendirin, yeniden deneme sayısına üst sınır koyun. Bu, izlenebilirlik ve hata bütçesi yazısında anlattığımız ölçüm probleminin fatura tarafındaki karşılığı.

Mimari kararlar aylık fatura kalemine dönüşür

Maliyet incelemesi bir noktadan sonra mimari incelemesidir. İşe yarayan çerçeve, toplam harcama yerine birim maliyete bakmak: müşteri başına, sipariş başına, bin istek başına kaç para. Bu sayı ürün kararlarını da değiştirir, çünkü hangi müşterinin kârlı olduğunu ilk kez görürsünüz.

Bağlantılar somut. Çok kiracılı SaaS mimarisinde her müşteriye ayrı kurulum vermenin marjinal maliyeti, paylaşılan şemanın marjinal maliyetiyle aynı değil. Veritabanı tarafında eksik bir indeks fatura üzerinde daha büyük bir örnek tipi olarak görünür; sorguyu düzeltmek donanım eklemekten hem ucuz hem kalıcıdır. Monolit ile mikroservis arasındaki kararda her servis sınırı bir ağ sıçraması demek ve o sıçrama AZ'yi geçtiğinde ücretli. Bunlar tasarım aşamasında bedava, üretimde pahalı düzeltmeler.

Çıkış maliyeti artık eskisi kadar bağlayıcı değil

Bulut pazarlığının dengesi son iki yılda değişti. Google Cloud Ocak 2024'te, AWS Mart 2024'te platformdan ayrılan müşteriler için internete veri çıkışı ücretini kaldırdığını duyurdu (belirli koşullar ve onay süreçleriyle); Microsoft da Azure'dan çıkışta benzer bir düzenleme açıkladı.

Düzenleme tarafı daha net. AB Veri Yasası (Regulation (EU) 2023/2854) 12 Eylül 2025'te uygulanmaya başladı ve geçiş dönemi boyunca sağlayıcıların yalnızca fiilen katlandıkları maliyeti yansıtmasına izin veriyor. 12 Ocak 2027'den itibaren veri çıkışı dahil tüm geçiş ücretleri tamamen yasak. Standart hizmet bedelleri ve erken fesih cezaları bunun dışında, ayrıca verinin özel bir biçime dönüştürülmesi gibi asgari yükümlülüğün ötesindeki hizmetler ücretlendirilebiliyor. AB'de hizmet veren ya da AB'li sağlayıcılarla sözleşmesi olan şirketler için pratik okuma şu: taşınabilirliği tasarımda ucuza koruyun, ama "kilitlenme" korkusuyla mimariden ödün vermeyin. Nesne depolamada sıfır çıkış ücretli seçenekler de var; Cloudflare R2 çıkış trafiğini ücretsiz listeliyor ve standart depolamayı GB-ay başına 0,015 dolardan veriyor.

Aynı envanter güvenlik listesinde de duruyor

Maliyet temizliğinin yan ürünü güvenlik. Kimsenin sahiplenmediği sunucu yamalanmıyor, kapanmış projenin anlık görüntüsü üretim verisini erişim denetimi olmayan bir yerde tutuyor, yanlışlıkla açık bırakılmış bir nesne deposu hem sızdırıyor hem çıkış trafiği faturalıyor. İki iş de aynı soruyla başlıyor: elimizde ne var ve kimin? Bu envanteri bir kez çıkardığınızda bulut yanlış yapılandırma ve paylaşılan sorumluluk tarafındaki kontrol listesinin yarısını da doldurmuş oluyorsunuz.

Bu ay yapılabilecek beş şey

Bir: etiket kapsama raporu çıkarın, harcamanın yüzde kaçının sahibi belli. Yüzde 80'in altındaysa diğer adımların hiçbirini ölçemezsiniz. İki: son 30 günün en büyük on kalemini listeleyin ve geri kalanını görmezden gelin; kuyruktaki yüz kalem toplamın küçük bir parçası ve zamanınızı yiyor. Üç: taahhüde dokunmadan önce iki hafta boyunca requests ile gerçek kullanımı yan yana koyun. Dört: bir tek ağ düzeltmesi yapın, ya AZ'ler arası konuşan bir çifti aynı alana alın ya da S3 için gateway uç noktası tanımlayın. Beş: ortam başına aylık harcamayı gecikme ve hata oranıyla aynı panoya koyun.

Bu beş adım faturayı tek başına yarıya indirmez. Yaptıkları şey daha değerli: harcamayı bir mühendislik sayısı haline getirir. Wedevit olarak bu incelemeyi uzaktan yapıyoruz: harcamayı kalem kalem sahibine bağlıyor, boyutlandırma ve ağ tarafındaki düzeltmeleri etki sırasına koyuyor ve taahhüt kararını en sona bırakıyoruz. Hiçbir sağlayıcının satış kanalında olmadığımız için önerinin tek sınavı sizin faturanız. Ondan sonrası teknik borcu ölçüp önceliklendirmekle aynı işleyişe giriyor, çünkü bulut faturasının büyük bölümü aslında geçen yılın ertelenmiş kararlarının aylık taksidi.