Bulut Maliyetleri Nasıl Düşürülür? 10 Etkili Yöntem

Bulut faturası neden her ay biraz daha büyüyor?

Bulut faturası çoğu zaman tek bir büyük hatadan değil, küçük ve sessiz kaynaklardan büyür. Kullanılmayan diskler, gece boyunca açık kalan test makineleri, gereğinden büyük veritabanları ve bölge dışına taşınan gigabaytlar birleştiğinde tablo değişir. Panelde her şey normal görünür; faturada ise sürpriz vardır.

Hosting tarafında farklı müşterilerin bulut kaynaklarını incelerken bunu defalarca gördüm. Bir sanal makinenin işlemci kullanımı düşük diye hemen küçültmek kolaydır. Disk türünü, ağ trafiğini, yedekleme politikasını ve yoğun saatleri hesaba katmazsanız yalnızca başka bir faturayı büyütmüş olursunuz.

Bulut maliyet optimizasyonu, en ucuz servisi seçmekten ibaret değil. İhtiyaca uygun kapasiteyi doğru zaman aralığında çalıştırmak, gereksiz veriyi taşımamak ve değişikliklerin etkisini ölçmek gerekir. Ben önce görünürlük kuruyor, sonra risk seviyesi düşük kaynaklardan ilerliyorum.

1. Faturayı hizmet bazında parçalayın

İlk adım tasarruf etmek değil, paranın nereye gittiğini görmektir. Toplam aylık tutar yalnızca alarm verir. Kaynağın hangi servis, proje, ortam veya ekip tarafından tüketildiğini göremiyorsanız yanlış yerde kesinti yapabilirsiniz.

Bulut sağlayıcınızın maliyet panelinde en az şu boyutları etkinleştirin:

• Hizmet türü: sanal makine, disk, nesne depolama, veritabanı ve ağ çıkışı.
• Kaynak veya proje etiketi.
• Üretim, staging ve geliştirme ortamı.
• Bölge ve kullanılabilirlik alanı.
• Günlük ve aylık maliyet değişimi.

Etiketleme baştan yapılmadıysa eski kaynakları sonradan sınıflandırmak yorucu olur. Yine de bunu ertelemeyin. project, environment, owner ve expires_at alanları basit ama işe yarayan bir başlangıçtır.

Ben maliyet raporuna kaynak yaşını da ekliyorum. Altmış gündür değişmemiş bir test diski veya doksan gündür trafik almayan bir IP adresi, inceleme sırasını kendiliğinden öne çıkarır.

2. Kullanılmayan kaynakları temizleyin

Bulut ortamlarında sanal makineyi silip bağlı diski bırakmak çok kolaydır. Snapshot’lar, eski imajlar, ayrılmış ama kullanılmayan IP adresleri ve unutulmuş yük dengeleyiciler de benzer şekilde yaşamaya devam eder.

Temizlik işlemine doğrudan silme komutuyla başlamayın. Önce envanter çıkarın, sahibini bulun, son erişim tarihini kontrol edin ve kısa bir bekleme süresi tanımlayın. Boş görünen kaynak ayda bir çalışan rapor sistemine ait olabilir.

find /srv/backups -type f -mtime +30 -printf '%TY-%Tm-%Td %s %pn' | sort

Bu komut, Linux üzerindeki yerel yedekleri yaşlarına göre gösterir. Buradaki -mtime +30 ifadesi, değişim zamanına göre otuz günden eski dosyaları arar. Bulut nesne depolaması için sağlayıcının yaşam döngüsü kurallarını kullanın; silme işini elle yazılmış bir script’e bırakmak gereksiz risk taşır.

Bir kaynak silinmeden önce şu soruya cevap arayın: Geri dönmemiz gerekirse bunu nereden üreteceğiz? Cevap yoksa önce arşivleme veya onay süreci kurun.

3. Sanal makine boyutlarını gerçek kullanıma göre seçin

Yeni bir sunucu açarken büyük makine seçmek rahat hissettirir. Sonra uygulama büyür diye iki kat RAM, dört kat CPU alınır. Uygulama büyümez; fatura büyür.

Rightsizing için yalnızca ortalama CPU kullanımına bakmayın. En az iki veya dört haftalık veride CPU, bellek, disk gecikmesi, disk IOPS’u, ağ trafiği ve yoğun saatlerdeki ani artışları birlikte inceleyin. Ortalama yüzde 8 CPU kullanan bir makine, her sabah birkaç dakika boyunca işlemciyi tamamen dolduruyor olabilir.

Linux VPS’lerde kaba bir ön kontrol için şu komutlar işime yarıyor:

uptime
free -h
vmstat 5 6
iostat -xz 5 3

free -h bellek durumunu, vmstat bekleme ve swap davranışını, iostat ise disk tarafındaki yükü gösterir. iostat her sistemde kurulu gelmeyebilir; Debian’da genellikle sysstat paketi gerekir.

Ben geçmişte bir VPS’in CPU grafiğine bakıp makineyi küçültmeye hazırlanmıştım. Sonra bellek ve disk davranışını kontrol ettiğimde uygulamanın disk önbelleğine yüklendiğini gördüm. Boyutu değiştirmek yerine sorgu ve önbellek davranışını düzelttik. Daha ucuz plan, ancak ölçümden sonra anlamlıydı.

4. Geliştirme ve staging kaynaklarını zamanlayın

Geliştirme ortamlarının çoğu gece kullanılmaz. Buna rağmen sanal makineler, yönetilen veritabanları ve test kümeleri haftanın yedi günü çalışır. Üretimde gerekli olan sürekli çalışma düzenini staging’e kopyalamak pahalı bir alışkanlıktır.

Çalışma saatlerini belirleyip kaynakları otomatik durdurun. Hafta içi 08.00-20.00 arasında çalışan bir test sunucusu, kullanım desenine göre belirgin fark yaratabilir. Saat dilimini açıkça tanımlayın; hesap UTC, ekip Türkiye saati kullanıyorsa plan beklemediğiniz anda devreye girebilir.

Otomatik durdurma öncesinde uygulama ve veritabanına düzgün kapanış sinyali gönderin. Sadece güç kesmek, yazma işlemi yapan bir veritabanında bozulmaya veya uzun recovery süresine yol açabilir.

Geçici kaynaklarda expires_at etiketi zorunlu tutulabilir. Süresi geçen kaynak için önce sahibine bildirim, sonra durdurma, en son silme uygulanabilir. İnsan hafızasına güvenmeyin. Gece vardiyasında unutulan test sunucusu sabaha kadar iyi çalışır; iyi çalıştığı için de para harcar.

5. Depolama sınıfını ve disk türünü ayarlayın

Her veri hızlı SSD üzerinde durmak zorunda değil. Sık erişilen veritabanı dosyaları ile altı ay önce alınmış log arşivi aynı depolama sınıfını kullanıyorsa maliyet ve performans birlikte yanlış ayarlanmış demektir.

Veriyi erişim sıklığına göre ayırın:

• Aktif veritabanı ve uygulama dosyaları: düşük gecikmeli disk.
• Günlük yedekler: standart nesne depolama.
• Uzun süre saklanacak arşivler: soğuk veya arşiv sınıfı.
• Geçici derleme ve cache verileri: yeniden üretilebilir alan.

Arşiv sınıfına geçerken geri alma ücretini ve erişim gecikmesini hesaba katın. Bir dosyayı ucuz depolamaya taşımak, acil durumda onu geri çağırmayı pahalı hâle getirebilir.

Yerel sunucularda disk tüketimini incelerken ilk açtığım araç ncdu‘dur. Bulut diskinde de aynı düşünce geçerli: alanı hangi klasörün veya veri tipinin yediğini görmeden disk büyütmek, sorunu yalnızca ileri bir tarihe taşır.

6. Snapshot ve yedek saklama politikasını sadeleştirin

Snapshot almak kolay, silmek zordur. Her değişiklikten önce alınan snapshot’lar zamanla birbirine benzeyen onlarca kopyaya dönüşebilir. Bazı sistemlerde snapshot maliyeti yalnızca görünen disk kapasitesiyle değil, değişen bloklarla da ilişkilidir.

Bir saklama politikası yazın. Günlük yedekleri kısa süre, haftalık yedekleri daha uzun süre, aylık arşivleri ise mevzuatın veya iş ihtiyacının gerektirdiği kadar saklayabilirsiniz. Rakamlar her sistem için aynı değildir; politikanın yazılı ve otomatik uygulanması gerekir.

Yedekleri silmeden önce geri dönüş testi yapın. Benim için test edilmemiş yedek, geleceğe bırakılmış bir varsayımdan ibarettir. borgbackup veya sağlayıcının yedekleme sistemi kullanılsa da bu değişmez.

borg list /backup/repository
borg check --verify-data /backup/repository

borg check bütün kurtarma senaryosunu doğrulamaz, fakat arşivin okunabilirliği hakkında değerli bir kontrol sağlar. Asıl sınama, ayrı bir makineye dosya veya servis geri yükleyip uygulamanın gerçekten açıldığını görmektir.

7. Ağ çıkışı ve veri transferini azaltın

Bulut faturalarında hesaplanması en zor kalemlerden biri veri transferidir. Aynı bölgedeki servisler arasında trafik farklı fiyatlanabilir; bölgeler arası trafik ve internet çıkışı beklenenden pahalı olabilir.

Uygulama ile veritabanını gereksiz yere farklı bölgelere koymayın. Kullanıcıya sunulan statik dosyaları CDN üzerinden servis edin. Büyük dosyaları her istekte uygulama sunucusundan geçirmek yerine nesne depolama ve önbellekleme kullanın.

İzleme sistemleri de ağ tüketebilir. Her konteynerin ayrıntılı logunu başka bölgedeki bir servise sürekli göndermek yerine örnekleme oranını, saklama süresini ve sıkıştırmayı gözden geçirin. Log seviyesi üretimde debug kaldığında yalnızca disk değil, ağ bütçesi de etkilenir.

Burada küçük bir ölçüm işe yarar:

iftop -i eth0

Bu komut anlık bağlantıları gösterir; aylık fatura analizi değildir. Yine de hangi servisin beklenmedik veri taşıdığını bulmak için iyi bir başlangıçtır. Üretim makinesinde çalıştırmadan önce yetki ve paket durumunu kontrol edin.

8. Taahhütlü indirimleri acele etmeden değerlendirin

Uzun süre aynı kapasiteyi kullanacağınızdan eminseniz rezerve kapasite, tasarruf planı veya benzeri taahhütlü modeller işe yarayabilir. İndirim gördüğünüz için bir yıllık ya da üç yıllık sözleşme imzalamak ise yanlış boyutlandırılmış kaynağı daha ucuza satın almak olabilir.

Önce son birkaç ayın taban kullanımını çıkarın. Üretim veritabanı, sürekli çalışan web katmanı veya değişmeyecek bir Kubernetes worker grubu bu hesap için uygun adaylardır. Staging, kampanya dönemi kapasitesi ve hızla değişen projeler için esnek fiyatlandırma daha güvenli olabilir.

Şunları yazılı olarak kontrol edin:

• Taahhüt hangi servis ve bölge için geçerli?
• Boyut veya makine ailesi değiştiğinde esneklik var mı?
• Erken iptal, satma veya devretme koşulları nedir?
• Vergi, lisans ve veri transferi indirim kapsamına giriyor mu?

Fiyat karşılaştırmasını yalnızca liste fiyatıyla yapmayın. Taahhüt nedeniyle kaybedilen esneklik de maliyetin bir parçasıdır.

9. Mimarinin gerçekten buluta uygun olup olmadığını sorgulayın

Her iş yükünü onlarca yönetilen servise bölmek otomatik olarak daha ucuz değildir. Küçük bir uygulama için sürekli çalışan bir küme, ayrı yük dengeleyici, yönetilen veritabanı ve yüksek hacimli gözlemleme servisi kurmak VPS’ten pahalı olabilir.

İş yükünün davranışına bakın. Trafik düzensiz ve kısa süreliyse olay güdümlü veya serverless yapı mantıklı olabilir. Serverless Nedir? Avantajları ve Kullanım Alanları başlıklı yazıda istek başına ücretlenen sistemlerin hangi durumlarda anlamlı olabileceğini karşılaştırmıştım.

Sabit trafik alan, az sayıda bileşeni bulunan bir uygulamada tek bir VPS veya birkaç sade sanal makine daha öngörülebilir olabilir. Bulut Sunucu vs VPS: Hangi Senaryoda Doğru Tercih yazısında da değindiğim gibi, karar yalnızca işlemci ve RAM fiyatına bakılarak verilmemeli; yönetim yükü, yedekleme, ağ ve operasyon süresi de hesaba katılmalı.

Mimarinin maliyetini ölçmek için aylık toplamı istek, müşteri, işlenen dosya veya tamamlanan görev başına bölün. Fatura aynı kalsa bile birim maliyet düşüyorsa doğru yönde ilerliyor olabilirsiniz.

10. Maliyet alarmları ve sorumluluk sınırları koyun

Ay sonunda fatura incelemek geç kalmış bir kontrol yöntemidir. Bütçe uyarıları, günlük maliyet raporları ve ani artış alarmları kurun. Bildirim yalnızca finans ekibine gitmemeli; kaynağın sahibi ve teknik sorumlusu da alıcılar arasında olmalı.

Alarmları çok hassas ayarlarsanız ekip onları susturur. Çok geniş bırakırsanız artışı günler sonra görürsünüz. Normal değişkenliği bildiğiniz projelerde eşik değerlerini buna göre belirleyin ve alarmın yanında kaynak kimliğini de gönderin.

Basit bir günlük rapor için etiketlenmiş kaynakları dışa aktarabilirsiniz:

#!/usr/bin/env bash
set -euo pipefail

printf 'Rapor tarihi: '
date -u +%F
printf 'Host: '
hostname

Bu örnek maliyet hesabı yapmaz; raporun hangi makineden ve hangi tarihte üretildiğini sabitler. Gerçek maliyet verisini sağlayıcının API’sinden çekiyorsanız API anahtarını script içine yazmayın. IAM rolü, kısa ömürlü kimlik bilgisi ve yalnızca okuma yetkisi kullanın.

Bir ekip kaynak açtığında sahibini, amacını ve kapanış tarihini belirtmeli. Bir gece vardiyasında cron’a fazladan bir yıldız yazılan yedek script’i her dakika çalışmaya başlamış, kısa süre içinde yaklaşık 40 bin e-posta birikmişti. O olayda sorun kaynak boyutu değildi; görünürlük ve onay eksikliğiydi. Maliyet alarmının yanına değişiklik geçmişini ve sorumlu kişiyi koymak bu yüzden değerli.

Bulut maliyet optimizasyonu için küçük bir çalışma planı

On yöntemi aynı gün uygulamaya çalışmak yerine sıralı ilerleyin. İlk hafta maliyetleri hizmet ve etiket bazında görünür kılın. İkinci hafta boşta kalan diskleri, IP adreslerini ve eski snapshot’ları inceleyin. Üçüncü hafta staging çalışma saatlerini düzenleyin. Dördüncü hafta makine boyutları ve depolama sınıfları için ölçüm yapın.

Her değişiklikten önce mevcut maliyeti ve performansı kaydedin. Sonra tek bir değişiklik yapıp birkaç gün gözlemleyin. Aynı anda disk türünü, makine ailesini ve ağ topolojisini değiştirirseniz hangi kararın etkili olduğunu anlayamazsınız.

Operasyon maliyetini de hesaba katın. Daha ucuz görünen servis ek bakım, daha fazla izleme veya karmaşık hata ayıklama gerektiriyorsa toplam hesap değişebilir. Birkaç liralık tasarruf için gece vardiyasını büyütmek iyi bir optimizasyon değildir.

VPS ile bulut arasında karar verirken

Öngörülebilir trafik alan bir web sitesi, küçük API veya kişisel proje için VPS’in sabit aylık fiyatı yönetimi kolaylaştırabilir. Trafiğin ani değiştiği, farklı bölgelerde kullanıcıların bulunduğu veya otomatik ölçeklemenin iş değerini artırdığı sistemlerde bulut servisleri daha uygun olabilir.

VPS seçtiğinizde de maliyet kontrolü bitmez. Yedekleme, trafik, disk büyümesi, monitoring ve yönetim süresini bütçeye ekleyin. Yeni VPS Sunucuyu 30 Dakikada Canlıya Alma Rehberi ile kurulum adımlarını standartlaştırmak, elle yapılan tekrarları ve yanlış yapılandırma ihtimalini azaltır.

Bulutun esnekliği ile VPS’in sadeliği arasında herkes için geçerli bir kazanan yok. İş yükünün ritmi, ekibin becerisi ve kesinti toleransı kararı belirler. Benim kontrol listemde ilk soru fiyat değil: Bu sistemi birkaç ay sonra hâlâ aynı şekilde mi çalıştıracağım?

Sık Sorulan Sorular

Bulut maliyetlerini düşürmeye nereden başlamalıyım?

Önce son faturayı hizmet, bölge, proje ve ortam bazında ayırın. Kullanılmayan diskleri, snapshot’ları ve gece açık kalan geliştirme kaynaklarını bulmak genellikle düşük riskli bir başlangıçtır.

Bulut kaynaklarını küçültmek performansı bozar mı?

Ölçüm yapmadan küçültürseniz bozabilir. CPU yanında bellek, swap, disk gecikmesi, IOPS ve yoğun saatlerdeki davranışı izleyin; değişiklikten önce snapshot alıp geri dönüş planı hazırlayın.

Rezerve kapasite veya uzun süreli taahhüt almak mantıklı mı?

Sabit ve uzun süre değişmeyecek kapasite için mantıklı olabilir. Önce birkaç aylık taban kullanımı çıkarın, taahhüdün hangi bölge ve makine ailesini kapsadığını kontrol edin ve belirsiz iş yüklerini bu kapsama dahil etmeyin.

VPS mi, bulut sunucu mu daha ucuz?

Sabit trafik ve sınırlı mimari için VPS daha öngörülebilir bir maliyet sunabilir. Değişken trafik, çoklu bölge veya otomatik ölçekleme ihtiyacı varsa bulutun ek maliyeti operasyonel faydayla dengelenebilir; doğru cevap iş yüküne göre değişir.

Faturanızı küçültmeden önce onu oluşturan davranışı görünür hâle getirin. Benim için en güvenli tasarruf, silme tuşuna basmadan önce sahibini, kullanım desenini ve geri dönüş yolunu yazabildiğim tasarruftur.