Cloud Faturanız Neden Şişiyor ve Nasıl Kontrol Altına Alınır?

Bir startup veya büyüme aşamasındaki şirket olarak cloud kullanmaya başladığınızda ilk birkaç ay her şey yönetilebilir görünür. Sonra bir gün AWS veya GCP faturasına bakarsınız ve ne zaman bu kadar büyüdüğünü anlayamazsınız. Genellikle bu faturanın büyük bölümü birkaç yaygın hatadan kaynaklanır. İyi haber: bunların büyük kısmı teknik olmayan kararlarla düzeltilebilir.

En Yaygın Cloud Maliyet Sorunları

1. Atıl Kalan Kaynaklar

Cloud’un en sinsi maliyeti, kimsenin kullanmadığı ama çalışmaya devam eden kaynaklardır. Bir test ortamı kurulur, proje biter, ortam kapatılmaz. Bir migration sırasında geçici volume oluşturulur, migration tamamlanır, volume unutulur. Bir load balancer, arkasındaki instance’lardan çok daha uzun süre ayakta kalır.

Bu “orphaned resource” sorunu özellikle ekip büyüdükçe ve hesap sayısı arttıkça görünmez hale gelir. Aylık yüzlerce dolar, kimsenin fark etmediği kaynaklara gidebilir.

2. Fazla Provision Edilmiş Instance’lar

“Bu iş için en büyük instance’ı alalım, sorun çıkmasın” mantığı bulut ortamında pahalıya mal olur. Pek çok şirket, CPU kullanımı sürekli %10-15’te seyreden instance’lar için büyük bütçeler öder. Bu, on-premise dünyadan gelen bir alışkanlıktır — cloud’da esneklik var, instance tipini değiştirmek birkaç dakika alır.

Bir instace’ın doğru boyutu için gereken soru basittir: “Bu makine ortalama olarak kapasitesinin ne kadarını kullanıyor?” Eğer yanıt %20’nin altındaysa, bir küçük instance tipine geçmek genellikle güvenlidir.

3. Tagging Yokluğu — Kim Ne İçin Ne Kadar Harcıyor?

Tagging stratejisi olmayan bir cloud ortamında maliyet dağılımını görmek neredeyse imkânsızdır. “Toplam fatura 8.000 dolar” bilgisi size hiçbir şey söylemez. Hangi ürün özelliği, hangi ortam, hangi ekip ne kadar harcıyor?

Yaygın tagging eksiklikleri:

Kaynakların hangi projeye ait olduğu etiketlenmemiş
Staging, dev, prod ortamları ayrıştırılmamış
Maliyet merkezleri belirsiz

Bu olmadan bir maliyet optimizasyonu çalışması yapmak, kaynağa bakmadan tasarruf etmeye çalışmak gibidir.

4. Dev/Test Ortamları 7/24 Çalışıyor

Üretim ortamının sürekli ayakta olması gerekir. Ama geliştiricilerin hafta sonu kullanmadığı staging ya da test ortamlarının çalışmasının bir gerekçesi yoktur. Buna rağmen çoğu şirkette bu ortamlar hiç kapatılmaz.

Takvim tabanlı bir shutdown politikası — örneğin akşam 20:00’de kapat, sabah 08:00’de başlat — bu ortamların maliyetini %60-70 oranında düşürebilir.

5. Yanlış veya Eksik Auto-Scaling

Auto-scaling doğru yapılandırılmadığında iki yönde de zarar verir: ya yük geldiğinde yetişmez, ya da gereksiz yere büyüyüp küçülmez. Özellikle minimum capacity çok yüksek tutulmuş ortamlarda auto-scaling’in bir faydası yoktur çünkü sistem zaten “büyük” olarak çalışmaya devam eder.

6. Data Transfer Maliyetleri — En Çok Gözden Kaçan Kalem

AWS, GCP ve Azure’un fiyatlandırmasında en az incelenen bölüm data transfer ücretleridir. Aynı region içindeki farklı availability zone’lar arasında bile veri transferi ücretlendirilir. Farklı region’lar arası ya da cloud’dan internete çıkan trafik ise ciddi kalemler oluşturabilir.

Özellikle büyük veri işleyen sistemlerde — analitik pipeline’lar, media işleme, log aggregation — data transfer faturaları beklenmedik boyutlara ulaşabilir.

Pratik Düzeltme Adımları

Tagging Stratejisini Hemen Uygulayın

Minimum tagging seti: project, environment (prod/staging/dev), team, owner. Bu dört etiket bile maliyet görünürlüğünü dramatik biçimde artırır. AWS Cost Explorer, GCP Billing veya Azure Cost Management bu etiketlere göre maliyet breakdown’u gösterir.

Yeni kaynaklarda tagging zorunlu hale getirilmeli, eski kaynaklar ise önceliklendirilmiş bir temizlik planıyla etiketlenmelidir.

Rightsizing ile Başlayın

AWS Compute Optimizer ve benzer araçlar, son 14 günlük kullanım verisine bakarak instance tipini küçültmenin güvenli olup olmadığını söyler. Bu önerileri körü körüne uygulamak risklidir, ama incelemek gerekir. Özellikle büyük instance’larda %20-40 maliyet azaltımı mümkündür.

Dev/Test Kapatma Politikası

Basit bir Lambda + EventBridge kuralı ya da AWS Instance Scheduler ile çalışma saatleri dışında dev ortamlarını otomatik kapatabilirsiniz. Bu, teknik açıdan kolay bir kazanımdır.

Bütçe Alarmları Kurun

Maliyet optimizasyonunun en temel adımı: bütçe tanımlayın ve aşıldığında uyarı alın. AWS Budgets, GCP Budget Alerts veya Azure Cost Alerts ile bu kurulum 15 dakika sürer. Şirketlerin önemli bir bölümü bu basit adımı bile atmamıştır.

Uzun Vadeli İş Yükleri İçin Reserved Instance veya Savings Plans

Eğer bir instance’ın 1-3 yıl boyunca çalışacağından eminseniz, Reserved Instance veya Savings Plans ile %30-60 arası indirim alabilirsiniz. Bu karar taahhüt gerektirdiğinden dikkatli yapılmalıdır, ama tahmin edilebilir iş yükleri için finansal olarak mantıklıdır.

Ne Zaman Obsesif Olmamak Gerekir?

Cloud maliyet optimizasyonu her aşamada öncelik olmamalıdır. Erken stage bir startup için bu konuya fazla zaman harcamak yanlış bir odak noktasıdır. Ürün-pazar uyumu henüz netleşmemişken altyapıyı optimize etmek anlamsızdır.

Ama şu noktada bu konuya eğilmek gerekir: maliyet kalemlerini açıklayamıyorsanız, fatura beklenmedik biçimde büyüyorsa ya da büyüme planlarınızda altyapı maliyetleri ciddi bir yer tutuyorsa. Görünürlük olmadan kontrol mümkün değildir.

Cloud altyapınızın maliyetini anlamlandırmakta zorlanıyorsanız ya da faturanızın hangi kısmının gereksiz olduğunu bilmek istiyorsanız, ücretsiz bir keşif görüşmesinde bunu birlikte inceleyebiliriz. Hangi adımların size en çok değer katabileceğini netleştirelim.