Bulut maliyet optimizasyonu, bulut kaynaklarının performans hedeflerinden ödün vermeden en düşük toplam maliyetle çalıştırılmasını sağlayan sürekli bir yönetim disiplinidir. Amacı faturayı küçültmek değil, harcanan her birim paranın ürettiği iş değerini artırmaktır. Uygulamada görünürlük, kaynak boyutlandırma, fiyatlandırma modeli seçimi ve mimari kararların birlikte yönetilmesi anlamına gelir.

Bulut harcaması artık kurumsal BT bütçelerinin en hızlı büyüyen ve en zor tahmin edilen kalemi. Sorun bulut kullanımının kendisi değil, harcamanın kim tarafından, hangi iş çıktısı için yapıldığının çoğu kurumda görünmez olması. Türkiye'de bu konuda üretilen içeriklerin neredeyse tamamı "maliyeti azaltmanın sekiz yolu" biçiminde listelerden oluşuyor ve karar vericinin asıl ihtiyacı olan soruyu yanıtsız bırakıyor: elimdeki kaldıraçlardan hangisine, hangi sırayla başvurmalıyım? Bu yazı o soruyu ölçülebilir kriterlerle yanıtlamak için yazıldı.

Bulut maliyet optimizasyonu nedir?

Bulut maliyet optimizasyonu, iş yüklerinin gerektirdiği performans, erişilebilirlik ve uyumluluk eşiklerini karşılarken toplam bulut harcamasını sistematik biçimde düşürmeyi hedefleyen strateji, teknik ve araç bütünüdür. Tek seferlik bir tasarruf projesi değil, kaynak talebi ve sağlayıcı fiyatlandırması değiştikçe tekrar eden bir döngüdür.

Bu kavramı bulut maliyet yönetiminden ayırmak önemlidir. Maliyet yönetimi harcamayı görünür kılar, izler ve raporlar. Optimizasyon ise o görünürlüğü eyleme dönüştürür, yani kaynak yapılandırmasını, satın alma modelini veya mimariyi fiilen değiştirir. Birçok kurum yalnızca birincisini yaptığı halde optimizasyon yaptığını düşünür. Panoların varlığı tasarruf üretmez, panolardan çıkan kararlar üretir.

Optimizasyonun doğru ölçüm birimi de toplam fatura değildir. Karar vericinin izlemesi gereken metrik birim maliyettir: işlenen bin kayıt başına maliyet, aktif kullanıcı başına altyapı maliyeti, tamamlanan sipariş başına bulut gideri. Toplam faturanın artması tek başına kötü bir sinyal değildir. Şirket iki kat büyürken faturanın yüzde altmış artması aslında başarılı bir optimizasyondur. Fatura sabitken birim maliyetin yükselmesi ise, büyüme durmuş olmasa bile, kaynak verimliliğinin bozulduğunu gösterir. Bu ayrım kurulmadan yapılan her tasarruf çalışması, performans riskini görmezden gelen kör bir kesinti hareketine dönüşme eğilimindedir.

Bulut harcamalarının yaklaşık üçte biri neden israfa dönüşüyor?

İsraf, kullanılmayan veya gereğinden büyük yapılandırılmış kaynaklara ödenen tutardır ve sektör genelinde inatçı biçimde yüksek seyreder. Flexera 2026 State of the Cloud raporuna göre boşa giden bulut harcaması, beş yıllık düşüş eğiliminin ardından ilk kez artarak yüzde 29 seviyesine çıktı; raporda bunun nedeni yapay zeka iş yükleri ile yeni IaaS ve PaaS hizmetlerinin getirdiği maliyet karmaşıklığı olarak gösteriliyor. Aynı çalışmada bulut harcamasını yönetmek kurumların yüzde 85'i tarafından en büyük zorluk olarak işaretlendi.

İsrafın birinci kaynağı yapısaldır: kaynağı oluşturan ekip ile faturayı ödeyen ekip aynı değildir. Mühendis bir örneği ölçeklendirirken karşısında bir maliyet göstergesi yoktur, finans ekibi ise faturayı ay kapandıktan sonra, yani müdahale penceresi kapandığında görür. Bu asimetri düzeltilmediği sürece hiçbir araç kalıcı sonuç üretmez.

İkinci kaynak aşırı tahsis alışkanlığıdır. Şirket içi veri merkezi döneminde kapasite peşin satın alınırdı ve fazladan alınan kaynak bir sigortaydı. Bulutta aynı refleks her saat faturalandırılan bir gidere dönüşür. Trafik saatleri dışında tam kapasiteyle çalışan uygulama sunucuları, bağlantısı kesilmiş diskler, unutulmuş anlık görüntüler ve boşta duran statik IP adresleri tipik israf kalemleridir.

Üçüncü kaynak ise etiketleme disiplinsizliğidir. Departman, proje, ortam ve sahip bilgisi taşımayan kaynaklar maliyet muhasebesine dahil edilemez. Hangi harcamanın hangi ürüne ait olduğu bilinmediğinde, tasarruf kararı da veri yerine sezgiyle alınır. Bu nedenle etiketleme, optimizasyonun bir parçası değil ön koşuludur.

Hangi maliyet kaldıracına önce başvurmalısınız?

Kaldıraçları geri dönüş süresine ve geri alınabilirliğine göre sıralamak, rastgele uygulanan onlarca "en iyi uygulama" listesinden çok daha hızlı sonuç verir. Doğru sıra şudur: önce kapat, sonra küçült, sonra satın alma modelini değiştir, en son mimariyi değiştir.

Birinci adım kapatmadır. Hiç kullanılmayan kaynağı silmek tasarrufun en yüksek getirili ve en düşük riskli biçimidir, çünkü performans üzerinde sıfır etkisi vardır ve karar geri alınabilir. Geliştirme ve test ortamlarını mesai dışında ve hafta sonu otomatik olarak durdurmak, bu ortamların aylık maliyetinin üçte ikisine yakınını doğrudan ortadan kaldırır. Çoğu kurumda ilk hafta içinde bulunabilecek en büyük tasarruf kalemi budur.

İkinci adım doğru boyutlandırmadır. Burada kritik kural, kararın anlık zirve değere değil en az iki haftalık kullanım telemetrisine dayanmasıdır. İşlemci kullanımı sürekli yüzde yirminin altında seyreden bir örnek, tek beden küçültüldüğünde tipik olarak maliyetin yarısına iner ve gecikme metriklerinde ölçülebilir bir bozulma yaratmaz. Boyutlandırma kararı da geri alınabilir olduğu için düşük risklidir.

Üçüncü adım satın alma modelidir. Rezerve örnekler ve tasarruf planları, bir veya üç yıllık taahhüt karşılığında talep üzerine fiyatlandırmaya kıyasla belirgin indirim sağlar. Ancak bu kaldıraç ilk ikisinden sonra devreye alınmalıdır, aksi halde optimize edilmemiş, gereğinden büyük bir kapasiteyi üç yıllığına sabitlemiş olursunuz. Kesintiye dayanıklı toplu işleme, model eğitimi ve sürekli entegrasyon süreçleri için spot kapasite ayrıca değerlendirilmelidir.

Dördüncü adım mimaridir. Veri transferi ücretlerini azaltmak için bölgeler arası trafiği yeniden tasarlamak, sıcak veriyi daha ucuz depolama katmanlarına taşımak veya değişken yüklü servisleri sunucusuz modele geçirmek en yüksek tasarrufu üretir. Buna karşılık geliştirme eforu gerektirir ve geri alınması pahalıdır, bu yüzden ilk üç adım tamamlanmadan başlatılmamalıdır.

Rezervasyon ve tasarruf planı taahhütleri ne zaman risk haline gelir?

Taahhütler yanlış kalibre edildiğinde maliyet düşürücü değil maliyet sabitleyici bir yükümlülüğe dönüşür. Riski yönetmenin yolu iki oranı birlikte izlemektir: kapsama oranı ve kullanım oranı.

Kapsama oranı, toplam tüketimin ne kadarının indirimli taahhütle karşılandığını gösterir. Kullanım oranı ise satın alınan taahhüdün ne kadarının fiilen tüketildiğini ifade eder. Kullanım oranının yüzde yüze yakın olması esastır, çünkü kullanılmayan her taahhüt saati doğrudan zarardır. Kapsama oranını ise yüzde yüze çıkarmak hedef olmamalıdır. Sağlıklı yaklaşım, son on iki ayın en düşük sürekli tüketim seviyesini taban kabul edip yalnızca o tabanı taahhüde bağlamak, dalgalanan kısmı esnek kapasiteyle karşılamaktır.

Üç yıllık taahhütler yalnızca teknoloji yol haritası öngörülebilir olduğunda anlamlıdır. Önümüzdeki on iki ay içinde bölge değişikliği, konteynerleştirme, işlemci mimarisi geçişi veya sağlayıcı çeşitlendirmesi planlıyorsanız bir yıllık taahhütler daha düşük fırsat maliyeti taşır. Taahhüt portföyünü tek seferde değil, üç aylık dilimler halinde kademeli yenilemek ise yenileme tarihlerinin tek bir noktada yığılmasını önler ve pazarlık esnekliği kazandırır.

FinOps olgunluğunuzu hangi metriklerle ölçersiniz?

FinOps, bulut harcamasını mühendislik, finans ve iş birimlerinin ortak sorumluluğuna dönüştüren operasyonel çerçevedir. Olgunluk seviyesi niyet beyanıyla değil iki sayıyla ölçülür: bulut harcamasının ne kadarının bir sahibe atanabildiği, yani tahsis oranı, ve tahminle gerçekleşen harcama arasındaki sapma.

FinOps Foundation bu olgunluğu emekleme, yürüme ve koşma seviyeleriyle tanımlar. Emekleme seviyesindeki kurum harcamasının en az yüzde 50'sini tahsis edebilir ve tahmin sapması yüzde 20 civarındadır. Yürüme seviyesinde tahsis oranı yaklaşık yüzde 80'e çıkar, sapma yüzde 15'e iner. Koşma seviyesinde ise harcamanın yüzde 90'ından fazlası tahsis edilir ve tahmin doğruluğu yüzde 12 bandına oturur. Bu eşikler, "FinOps yapıyoruz" ifadesini denetlenebilir bir iddiaya çeviren nadir sayısal referanslardan biridir.

Çerçevenin işleyişi bilgilendirme, optimizasyon ve işletme olmak üzere üç aşamalı bir döngüdür ve bir kurum farklı ekipleri için aynı anda farklı aşamalarda bulunabilir. Bilgilendirme aşaması görünürlük ve maliyet dağıtımını kurar. Optimizasyon aşaması yukarıda tarif edilen kaldıraçları uygular. İşletme aşaması bu kararları otomatikleştirir ve süreklilik kazandırır.

Kurumsal yapı tarafında da sinyal net. Flexera 2026 verilerine göre kurumların yüzde 63'ü kurulu bir FinOps ekibine sahip, yüzde 71'i ise bir Bulut Mükemmeliyet Merkezi işletiyor. Ayrı bir ekip kuramayan orta ölçekli kurumlar için pratik başlangıç, mühendislik, finans ve ürün taraflarından birer temsilcinin katıldığı aylık bir maliyet gözden geçirme toplantısıdır.

Yapay zeka iş yükleri bulut maliyet denklemini nasıl değiştiriyor?

Yapay zeka iş yükleri, klasik bulut optimizasyonu varsayımlarının bir kısmını geçersiz kılıyor. Grafik işlem birimleri saatlik olarak genel amaçlı işlem kaynaklarından kat kat pahalıdır ve statik olarak ayrılmış GPU filoları çoğu kurumda düşük kullanım oranıyla çalışır. Burada israf yüzdesi aynı kalsa bile mutlak tutar çok daha büyüktür.

İkinci fark faturalandırma birimidir. Model çıkarım hizmetleri sıklıkla token veya istek başına ücretlendirilir, dolayısıyla maliyet altyapı yapılandırmasından çok uygulama tasarımına bağlıdır. İstem uzunluğu, bağlam penceresi yönetimi, önbellekleme ve model seçimi, örnek boyutlandırmadan daha büyük maliyet etkisi yaratır. Bu nedenle yapay zeka maliyet optimizasyonu altyapı ekibinin tek başına çözebileceği bir konu değildir.

Üçüncü fark gecikme toleransıdır. Eğitim, ince ayar ve toplu çıkarım işleri kesintiye dayanıklıdır ve spot kapasitede önemli ölçüde ucuza çalıştırılabilir. Kullanıcıya dönük gerçek zamanlı çıkarım ise bu esnekliğe sahip değildir. İş yüklerini bu eksende ayırmak, GPU harcamasında en hızlı kazanımı sağlayan ayrımdır.

Bu bölüm, fiyatlandırma modelleri ve donanım nesilleri hızla değiştiği için makalenin en kısa ömürlü kısmıdır ve altı ayda bir gözden geçirilmelidir. Kapatma, boyutlandırma ve tahsis disiplini gibi temel ilkeler ise sağlayıcıdan bağımsız olarak geçerliliğini korur.

Sık sorulan sorular

Bulut maliyet optimizasyonu ile maliyet düşürme aynı şey midir?

Hayır. Maliyet düşürme mutlak harcamayı azaltmayı hedefler ve gerektiğinde performanstan ödün verir. Optimizasyon ise belirlenen performans ve uyumluluk eşikleri korunarak birim maliyetin düşürülmesidir. Optimizasyon sonucunda toplam fatura, iş hacmi büyüdüğü için artabilir; bu bir başarısızlık göstergesi değildir.

Kurumumuzdaki israf oranının makul olup olmadığını nasıl anlarım?

Sektör ortalaması referans alınabilir bir başlangıç noktasıdır ve son ölçümlerde yüzde 29 civarındadır. Kendi oranınızı hesaplamak için son otuz günde hiç trafik almamış kaynakların ve işlemci kullanımı sürekli yüzde yirminin altında kalan örneklerin toplam maliyetini aylık faturaya bölün. Bu oran yüzde 30'un üzerindeyse önceliğiniz araç satın almak değil, kapatma ve boyutlandırma kampanyası yürütmek olmalıdır.

FinOps ekibi kurmak için hangi harcama seviyesi eşiktir?

Ayrı bir ekip için kesin bir rakam yoktur, ancak pratik eşik bulut harcamasının bir kişinin tam zamanlı maliyetini birkaç kat aşmaya başladığı noktadır. Bu eşiğin altındaki kurumlar için doğru model, mevcut altyapı ekibinden bir kişiye maliyet sahipliğini resmen atamak ve aylık gözden geçirme ritmini kurmaktır.

Çok bulutlu mimari maliyeti artırır mı?

Genellikle evet, en azından kısa vadede. Farklı sağlayıcıların panoları, faturalandırma birimleri ve indirim mekanizmaları birbirine benzemez; bu da görünürlüğü zorlaştırır ve taahhüt indirimlerinin tek sağlayıcıda toplanmasını engeller. Bölgeler ve sağlayıcılar arası veri transferi ücretleri de sıklıkla hafife alınır. Çok bulutlu yapı, satıcı bağımlılığı veya veri ikametgahı gibi net bir gerekçeye dayanıyorsa savunulabilir; aksi halde maliyet açısından bir yüktür.

TL;DR

Bulut maliyet optimizasyonu, performans eşikleri korunarak birim maliyetin düşürülmesidir ve toplam faturayı kısmakla aynı şey değildir. Sektör genelinde bulut harcamasının yaklaşık yüzde 29'u israfa gitmektedir ve bu oran yapay zeka iş yükleriyle birlikte yeniden yükselişe geçmiştir. Kaldıraçlar geri dönüş süresine göre sıralanmalıdır: önce kullanılmayanı kapat, sonra doğru boyutlandır, sonra taahhüt modeline geç, en son mimariyi değiştir. Taahhütlerde kullanım oranı yüzde yüze yakın tutulmalı, kapsama oranı ise sürekli tüketim tabanıyla sınırlandırılmalıdır. FinOps olgunluğu tahsis oranı ve tahmin sapmasıyla ölçülür; olgun seviyede harcamanın yüzde 90'ından fazlası bir sahibe atanabilir. Yapay zeka iş yüklerinde maliyet kararı altyapıdan çok uygulama tasarımıyla belirlenir.

Sonuç

Bulut maliyetleri kontrolden çıktığında sorun neredeyse hiçbir zaman teknik değildir. Araçlar mevcut, sağlayıcı indirimleri erişilebilir, telemetri zaten toplanıyor. Eksik olan, harcamayı üreten kararla o harcamanın sonucunu gören kişi arasındaki bağdır. Bu bağ kurulmadan yapılan tasarruf kampanyaları birkaç ay içinde eski seviyeye geri döner, çünkü israfı üreten mekanizma yerinde durmaktadır.

Karar vericiler için doğru soru "hangi aracı alalım" değil, "harcamamızın yüzdesi kaçını bir sahibe atayabiliyoruz" sorusudur. Bu hafta yapılacak somut ilk adım şudur: son otuz günün faturasını çıkarın, etiketsiz kaynakların toplam maliyetini hesaplayın ve tahsis oranınızı yüzde olarak yazın. Oran yüzde 50'nin altındaysa optimizasyon değil etiketleme disiplini kurun. Yüzde 50 ile 80 arasındaysa kapatma ve doğru boyutlandırma kampanyasıyla başlayın. Yüzde 80'in üzerindeyse taahhüt portföyünüzü kullanım oranı üzerinden gözden geçirin ve yapay zeka iş yüklerinizi gecikme toleransına göre ayırın.

Kaynaklar

FinOps Foundation, FinOps Framework Maturity Model, https://www.finops.org/framework/maturity-model/

‍