Buluta geçiş, altyapı esnekliği ve hızlı ölçeklenme açısından önemli avantajlar sağlar. Ancak bu esneklik, kontrol mekanizmaları kurulmadığında maliyetlerin fark edilmeden büyümesine de neden olabilir. Bir sanal makinenin gece kapatılmaması, kullanılmayan disklerin aylarca elde tutulması, test ortamlarının üretim kadar büyük açılması ya da veri çıkış trafiğinin gözden kaçması; ay sonu faturasında ciddi fark yaratır. Bulut maliyet optimizasyonu, yalnızca daha az harcamak demek değildir. Asıl hedef, iş yüküne uygun kaynak kullanmak, israfı azaltmak ve teknoloji yatırımlarını ölçülebilir hale getirmektir.

FinOps yaklaşımı bu noktada kritik bir rol üstlenir. FinOps, finans, operasyon ve mühendislik ekiplerini ortak bir görünürlük ve karar çerçevesinde bir araya getirir. Mesele sadece satın alma değildir; kim, hangi kaynağı, ne kadar süreyle, hangi iş çıktısı için kullanıyor sorusunu netleştirmektir. İyi kurgulanmış bir modelde ekipler günlük ya da haftalık düzeyde tüketimi izler, etiketleme standartlarıyla maliyetleri iş birimlerine dağıtır ve otomatik politikalar sayesinde gereksiz harcamaları daha oluşmadan sınırlar.

Pratikte en büyük kazanım, tek seferlik indirimlerin peşinden koşmaktan değil, sürekli çalışan kontrol sistemlerinden gelir. Örneğin 30 gün boyunca CPU kullanımı yüzde 10'un altında kalan örnekleri küçültmek, mesai dışı saatlerde geliştirme ortamlarını durdurmak veya 90 gündür erişilmeyen nesneleri daha düşük maliyetli depolama sınıfına taşımak; tekrar eden ve doğrudan ölçülebilen tasarruf sağlar. Etkili bir strateji için teknoloji, süreç ve sorumluluk tanımları birlikte ele alınmalıdır.

Bulut faturası neden beklenenden hızlı büyür?

Bulut ortamlarında maliyet artışı çoğu zaman tek bir büyük hatadan değil, zaman içinde biriken küçük kararlardan doğar. En sık karşılaşılan örneklerden biri aşırı boyutlandırmadır. Uygulama ilk kurulumda 8 vCPU ve 32 GB RAM ile açılır, trafik artmaz ama kaynak aynı kalır. 24 saat çalışan bu örnek, ihtiyaç duyulan kapasitenin 2 katı olabilir. Benzer biçimde kullanılmayan snapshot'lar, sahipsiz IP'ler, boşa bekleyen yük dengeleyiciler ve eski log arşivleri de görünmeyen maliyet kalemleridir.

Bir başka kritik alan veri transferidir. Aynı sağlayıcı içinde bile bölgeler arası trafik ya da internet çıkışı ücretli olabilir. Özellikle medya, e-ticaret ya da API yoğun sistemlerde aylık birkaç terabayt çıkış trafiği sürpriz faturalar yaratır. Örnek bir senaryoda, günlük 100 GB dış trafik üreten bir uygulama ay sonunda yaklaşık 3 TB veri çıkışı oluşturur. Bu hacim, hesaplama maliyetinden daha pahalı hale gelebilir. Bu yüzden maliyet analizinde yalnızca sunucu fiyatına bakmak yeterli olmaz.

Test ve geçici ortamlar da sık gözden kaçan başlıklardan biridir. Geliştirme ekibi yeni sürüm denemeleri için 6 farklı ortam açar, iş biter ama ortamlar silinmez. 7/24 çalışan bu kaynaklar üretime değer katmaz. FinOps yaklaşımında bu tür iş yükleri için yaşam döngüsü kuralları tanımlanır: örneğin 14 gün sonunda otomatik silme, hafta içi 08:00-20:00 arası otomatik açma gibi.

FinOps odaklı görünürlük: İlk 30 günde neyi ölçmelisiniz?

Maliyet optimizasyonunun ilk adımı, neyin neden harcandığını görünür hale getirmektir. İlk 30 gün içinde kurulması gereken temel yapı; hesap, proje, ortam ve uygulama bazında maliyet ayrıştırmasıdır. Bunun için etiketleme standardı şarttır. En az şu alanlar çoğu kurum için yeterli olur: team, application, environment, owner, cost-center. Etiketsiz kaynak oranı yüzde 5'in üstündeyse raporlama güvenilirliğini kaybeder.

Somut bir kontrol listesi şöyle olabilir:

  • İlk 7 günde tüm hesaplar için birleşik maliyet görünümünü açın.
  • İlk 14 günde zorunlu etiket politikasını tanımlayın.
  • İlk 21 günde günlük maliyet artış eşiğini belirleyin. Örneğin yüzde 15 üstü sapmada uyarı üretin.
  • İlk 30 günde en pahalı 20 kaynağı ve son 30 günün kullanım desenini inceleyin.

Bu görünürlük olmadan yapılan iyileştirmeler çoğu zaman sezgisel kalır. Oysa ekiplerin aynı panele bakması, finans ile mühendisliğin aynı dili konuşmasını mümkün kılar. Hedef, “fatura neden arttı” sorusunu ay sonunda sormak değil, artışı ertesi gün fark etmektir.

Maliyet dağıtımı için etiket standardı örneği

Aşağıdaki gibi basit bir yaklaşım, raporlama disiplinini ciddi biçimde güçlendirir:

team=crm
application=customer-portal
environment=prod
owner=platform-team
cost-center=TR-145

Politika motoru üzerinden bu etiketler yoksa kaynak oluşturmayı reddetmek mümkündür. Böylece süreç, sonradan temizlik yapmaya değil, en baştan doğru kurguya dayanır.

Gereksiz kaynak tüketimini azaltan temel kontrol yöntemleri

En hızlı sonuç veren alan, atıl kaynakların temizlenmesidir. Bunun için son 30 veya 60 günün kullanım verisi izlenir. CPU, bellek, disk IOPS ya da ağ trafiği belirli eşiklerin altında seyrediyorsa küçültme ya da kapatma adayları işaretlenir. Örneğin 45 gün boyunca ortalama CPU kullanımı yüzde 8 olan bir uygulama sunucusunun bir alt boyuta çekilmesi çoğu durumda performansı etkilemez. Burada karar tek bir metriğe göre verilmez; tepe kullanım saatleri de dikkate alınır.

İkinci kontrol alanı, zamanlama otomasyonudur. Geliştirme, test ve eğitim ortamları birçok işletmede 7/24 açık kalır. Oysa mesai dışı kapanma politikasıyla haftalık çalışma süresi 168 saatten 60 saate kadar indirilebilir. Bu da teorik olarak yaklaşık yüzde 64 daha az çalışma süresi anlamına gelir. Her iş yükü için birebir aynı oran oluşmaz; ancak potansiyel tasarruf alanını açık biçimde gösterir.

Üçüncü alan, depolama yaşam döngüsüdür. Sık erişilmeyen log, yedek ve medya dosyaları daha düşük maliyetli katmanlara taşınabilir. Örnek bir kural seti şu şekilde kurgulanabilir: 30 gün sonra standart katmandan soğuk katmana geçiş, 90 gün sonra arşiv sınıfına taşıma, 365 gün sonra silme ya da yalnızca yasal saklama kapsamındakileri tutma. Özellikle nesne depolama kullanan sistemlerde bu politikalar otomatik çalıştığında kalıcı etki yaratır.

Rightsizing tekniği nasıl uygulanır?

Rightsizing, kaynağı gerçek iş yüküne uygun boyuta çekmektir. Uygulama performansını riske atmamak için en az 2 haftalık, tercihen 30 günlük veri incelenir. Yalnızca ortalama değil, yüzde 95'lik kullanım dilimi de değerlendirilir. Mesela bellek kullanımı sürekli yüksek ama CPU düşükse sadece örneği küçültmek yerine uygulama mimarisine bakmak gerekir. Java servisleri, önbellek ayarları veya veritabanı bağlantı havuzları burada belirleyici olabilir.

Kritik sistemlerde önce gölge test yapılır. Trafiğin küçük bir kısmı daha düşük boyutlu örneğe yönlendirilir, yanıt süresi ve hata oranı izlenir. 200 ms altında sabit kalan API gecikmesi ve hata oranında anlamlı bir artış olmaması, küçültme kararını destekler. Bu yaklaşım, tahmine dayalı değil, ölçüme dayalı optimizasyon sağlar.

Satın alma modeli ve rezervasyon stratejisi

Sürekli çalışan yükler için yalnızca anlık ödeme modeline bağlı kalmak maliyetli olabilir. Üretim veritabanı, çekirdek ERP servisleri veya her gün çalışan entegrasyon işçileri gibi öngörülebilir iş yüklerinde uzun dönemli rezervasyon ya da tasarruf planları değerlendirilebilir. Burada kritik nokta, önce kullanım desenini doğrulamaktır. 12 ay boyunca düzenli çalışan bir kaynak ile 3 ay sonra mimarisi değişecek bir servis aynı yöntemle ele alınmamalıdır.

Riskli yaklaşım, ekibin henüz yeterince tanımadığı bir iş yükü için peşin kapasite bağlamasıdır. Daha sağlıklı yöntem ise son 90 gün kullanımını baz almak, taban kapasiteyi rezervasyonla güvence altına almak ve dalgalı kısmı esnek modelde bırakmaktır. Örneğin toplam ihtiyacın yüzde 50-60'ı sabitse bu dilim için rezervasyon mantıklı olabilir. Kalan kısmın otomatik ölçeklenmeyle karşılanması çevikliği korur.

Kesintiye toleranslı işler için spot ya da preemptible kaynaklar da etkili olabilir. Gece çalışan raporlama görevleri, toplu veri işleme veya yeniden başlatılabilir CI iş yükleri buna iyi örnektir. Ancak müşteri yüzü gören kritik servisleri bu modele taşımak, yalnızca maliyet odaklı bir bakışla verilmemesi gereken bir karardır.

Mimari kararların maliyete etkisi

Bulut maliyet optimizasyonu yalnızca altyapı katmanında yapılmaz; mimari tasarım da faturayı doğrudan etkiler. Gereksiz ağ trafiği üreten servis ayrışmaları, çok sık çalışan senkron entegrasyonlar veya küçük veri için ağır analitik altyapı kurmak maliyetleri yukarı çeker. Bazen 5 servisin tek veritabanına yüksek frekansta istek atması, daha büyük örnekler almaya zorlar. Oysa önbellek, kuyruk yapısı veya veri çoğaltma stratejisiyle aynı iş çok daha verimli çözülebilir.

Örnek bir senaryo düşünelim: Her sipariş için dış ERP sistemine gerçek zamanlı 4 API çağrısı yapan bir e-ticaret akışı var. Günde 20 bin siparişte bu sayı 80 bin çağrıya çıkar. Bu çağrıların bir bölümü kuyruklanabilir veya toplu işlenebilir hale gelirse hem API maliyeti hem ağ trafiği düşer. Üstelik hata toleransı da artar. Maliyet optimizasyonu çoğu zaman performans ve dayanıklılık iyileştirmeleriyle birlikte gelir.

Veritabanı katmanında da benzer bir durum görülür. İndeks eksikliği yüzünden gereksiz yüksek CPU kullanımı ortaya çıkabilir. Bu durumda daha büyük veritabanı örneği almak geçici bir çözümdür. Sorgu optimizasyonu, doğru indeksleme ve arşivleme politikası ise çoğu zaman daha kalıcı sonuç verir. 500 ms süren yoğun bir sorgunun 80 ms seviyesine inmesi, aynı anda daha az kaynakla daha fazla yük taşımak anlamına gelir.

Yönetişim, bütçe ve alarm mekanizmaları

Sürdürülebilir tasarruf için yönetişim şarttır. Aylık bütçe tanımlamak tek başına yeterli olmaz; günlük veya haftalık eşikler, servis bazlı alarm kuralları ve sorumluluk matrisi gerekir. İyi kurgulanmış bir modelde her kritik uygulamanın bir maliyet sahibi bulunur. Fatura merkezi ekipte görünse bile karar yetkisi ve açıklama sorumluluğu uygulama sahibindedir.

Alarm yapısı pratik ve ölçülü olmalıdır. Örneğin günlük maliyet bir önceki 7 günlük ortalamanın yüzde 20 üstüne çıkarsa bildirim üretmek anlamlıdır. Her küçük dalgalanmada alarm vermek ekipleri körleştirir. Benzer şekilde, kullanılmayan disk sayısı 10'u geçtiğinde otomatik inceleme kaydı açmak veya etiketsiz kaynaklar için haftalık rapor göndermek gerçekçi kontrollerdir.

Kuralların bir kısmı teknik olarak zorunlu hale getirilebilir. Yeni açılan depolama kovalarında yaşam döngüsü politikası yoksa oluşturmayı engellemek, herkese açık erişimi onaysız biçimde kapatmak ya da belirli boyutun üstündeki kaynaklar için ek onay istemek buna örnektir. FinOps sadece raporlama değil, aynı zamanda politika uygulama disiplinidir.

Bulut maliyet optimizasyonu için uygulanabilir yol haritası

Başlangıç için karmaşık bir dönüşüm programı gerekmez. İlk 90 gün içinde ölçülebilir ilerleme sağlanabilir. İlk ay görünürlük ve etiketleme düzeni kurulur. İkinci ay atıl kaynak temizliği, zamanlama otomasyonu ve depolama yaşam döngüsü devreye alınır. Üçüncü ayda ise rightsizing, satın alma modeli analizi ve mimari iyileştirme adayları ele alınır.

Buradaki başarı ölçütü yalnızca faturanın düşmesi değildir. Kaynak başına iş çıktısı artıyor mu, ekipler maliyeti servis bazında okuyabiliyor mu, yeni kaynak açılırken standartlar otomatik uygulanıyor mu; asıl olgunluk göstergeleri bunlardır. Kurum içi sahiplik netleştiğinde bulut, öngörülemeyen bir gider kalemi olmaktan çıkar ve yönetilebilir bir teknoloji yatırımına dönüşür.

Özetle, bulutta tasarruf en çok görünürlük, otomasyon ve mimari doğruluk bir araya geldiğinde elde edilir. Geçici kampanyalar ya da tek seferlik temizlikler kısa süreli etki yaratır. Kalıcı kazanım için FinOps yaklaşımını süreçlerin doğal bir parçası haline getirmek gerekir. Böylece hem gereksiz kaynak tüketimi azalır hem de büyüme dönemlerinde maliyet kontrolü kaybedilmez.