Azure IaaS Maliyet Optimizasyonu: Sahadan FinOps Notları
Aslında, Şöyle başlayayım: Azure faturası, tek bir kötü kararla bir anda şişmiyor (en azından benim deneyimim böyle). Yavaş yavaş oluyor bu iş. Bir bakmışsınız, üç sene önce “geçici” diye açılmış bir Premium SSD hâlâ orada dürüyor, kimse dokunmaya cesaret edemiyor; ya da geliştirici ekip “ne olur ne olmaz” diyerek D8s_v5 seçmiş, halbuki o iş yükü B2s’te bile pek zorlanmıyor.
Ben bu işi 20 yıldır yapıyorum ve açık konuşayım — bulut maliyetlerinin büyük kısmı teknik bir problem değil aslında. Kültürel bir problem. Kimse “benim” demediği için kimse silmiyor, kimse küçültmüyor, kimse de dönüp sorgulamıyor. Evet, mesele biraz da bu.
Doğrusu, Neyse, uzatmayalım. Microsoft’un Azure IaaS — ki bu tartışılır — blog serisinin üçüncü yazısı çıktı, konu da maliyet verimliliği. Ben de bu vesileyle hem oradaki başlıklara değineyim hem de sahada gördüklerimi, Türkiye’deki kurumsal yapıların yaşadığı gerçek sıkıntıları araya serpiştireyim; çünkü kağıt üstündeki öneriyle canlı ortamın hali bazen aynı gezegende bile olmuyor — valla güzel iş çıkarmışlar —
Neden Azure Faturası “Birdenbire” Kabarır?
Aslında birdenbire kabarmaz. Sadece bir anda fark edersiniz, olay biraz orada dönüyor. İkisi aynı şey değil.
Compute, storage ve networking — bu üçlü, IaaS tarafındaki harcamanın neredeyse hepsini yiyor. Her birinin içinde ayrı bir sessiz — kendi adıma konuşayım — tuzak var; VM seçimi, disk tipi, public IP unutulması… Tek tek bakınca “eh işte” diyorsunuz. Ama üst üste gelince tablo değişiyor, hem de fena değişiyor.
Doğrusu, Kurumsal tarafta en sık gördüğüm mesele şu: ilk göç kararları. Şirket on-prem’den Azure’a geçiyor, ekip henüz bulut kafasına tam oturmamış oluyor, “lift and shift” diye başlanmış iş orada kalıyor. Sonra ne oluyor? On-prem’deki 32 GB RAM’li sunucunun aynısı bulutta dürüyor ama makine %8 CPU kullanıyor; kağıt üstünde göç tamam, pratikte işe fatura can sıkıyor.
Buluta taşımak, optimize etmek demek değildir. Taşıdıktan sonra optimize etmezseniz, sadece pahalı bir veri merkeziniz olur — o kadar.
Compute: VM Seçimi Sanıldığından Karmaşık
İnsanlar VM seçimine genelde “kaç core, kaç RAM” diye giriyor. Kısa cevap bu, evet. Ama işin aslı orada bitmiyor; hatta bazen daha yeni başlıyor.
Hani, Azure’da bugün itibarıyla 700’ün üzerinde VM SKU var. B-serisi, D-serisi, E-serisi, F-serisi, L-serisi, M-serisi, N-serisi… üstüne bir de her serinin v3, v4, v5, v6 varyantları geliyor. Şey, ilk bakışta biraz göz yoruyor. Ama doğru seçim yapıldığında %40-60 arası tasarruf görmek mümkün — abartı değil bu, baya gerçek bir rakam.
Sık Yapılan Hatalar
- Burstable ihmali: Geliştirme ve test ortamlarında B-serisi çoğu zaman tam yerine oturuyor. Buna rağmen ekipler alışkanlıktan D-serisi seçiyor; neden derseniz, sanırım biraz “bildiğimiz yoldan şaşmayalım” rahatlığı.
- Yeni nesli kaçırmak: Dv5 yerine hâlâ Dv3 çalıştıran çok müşteri gördüm. Bak şimdi, aynı fiyata daha iyi performans alabiliyorken eski nesilde kalmanın pek savunulacak tarafı yok. (bu kritik)
- Reserved Instance korkusu: “3 yıl bağlanmak istemem” cümlesini çok duydum. Haklılık payı var gibi dürüyor ama 1 yıllık RI bile %30-40 tasarruf getiriyor ve iptal/değişim tarafında da eliniz bayağı bağlı değil. — bunu es geçmeyin
- Spot VM’i unutmak: Batch işleri, CI/CD runner’ları ve hayatı olmayan iş yükleri için Spot fiyatları resmen tuhaf derecede ucuz. %70-90 arası indirim var; insan görünce bir an şüphe ediyor açıkçası.
Türkiye Perspektifi: Kur Riski Faktörü
Şimdi burada Microsoft’un genel anlatısında pek geçmeyen. Türkiye’de masanın üstünde duran bir konu var: kur riski. Azure faturası USD/EUR olarak geliyor. TL bazında baktığınızda işe çoğu zaman “hesap ettiğinizden” daha fazla ödüyorsunuz; ay sonu gelince tablo hafif can sıkıyor.
Bu yüzden Türkiye’deki kurumsal müşterilerime hep şunu söylüyorum: Reserved Instance’a girmek burada Batı’daki emsallerine göre daha hayatı olabiliyor. Çünkü 3 yıllık RI aldığınızda sadece Azure listesindeki indirimi almıyorsunuz (bu kısmı herkes görüyor), aynı zamanda kur oynaklığına karşı da kendinize küçük bir kalkan kurmuş oluyorsunuz. Fiyatı efektif olarak sabitlemiş oluyorsunuz (buna dikkat edin). Küçük detay gibi dürüyor ama sene sonunda etkisi baya hissediliyor.
Sağ Ölçekleme (Rightsizing) İçin Pratik Yol Haritası
Araya gireyim: Azure Advisor’ın rightsizing önerileri fena değil. Ama tek başına yetmiyor; orada iş biraz yüzeyde kalıyor. Ben genelde şu sırayla gidiyorum:
- Azure Monitör’da en az 14 gün metrik topla (7 gün yetmez, hafta sonu davranışı kaçar gider)
- p95 CPU ve memory değerlerine bak — average çoğu zaman yanıltıyor
- Network throughput ve disk IOPS tarafını da atlama
- Küçültmeden önce staging ortamında dene — bazı uygulamalar RAM’e beklenmedik şekilde yapışıyor
- Küçültme sonrası 2 hafta izle; gerekirse geri dönersin (bence en önemlisi)
İlginç olan şu ki, Evet.
Neyse uzatmayalım: VM seçimi sadece kapasite hesabı değil, kullanım şekli, maliyet baskısı. Hatta ülkenin para birimiyle bile ilgili oluyor. Sız ne dersiniz?
Storage: Sessiz Katil
İtiraf edeyim, Storage tarafı, açık konuşayım, compute’tan bile daha sinsi geliyor bana. Neden mi? Çünkü birikiyor da birikiyor; kimse dönüp bakmıyor, silmek akla gelmiyor, sonra bir de Premium disk tarifesi P30 ile Standard HDD S30 arasında neredeyse 10 kat fiyat farkı çıkınca insan “biz bunu ne ara büyüttük?” diye kalıyor (evet, doğru duydunuz)
Şuna çok denk geldim: geliştirme ekibi POC için Premium SSD açıyor, iş bitiyor ama disk orada öylece dürüyor. Ya da eski bir SQL Server’ın data disk’i Premium’da kalmış oluyor, halbuki iş yükü artık kilit değil (bizzat test ettim). Kimse dokunmaya cesaret edemiyor çünkü “ya bozulursa?” hissi var ya, işte asıl bütçeyi o kemiriyor (en azından benim deneyimim böyle)
Katman Stratejisi
Blob Storage’ta Hot / Cool / Cold / Archive katmanları var; kağıt üstünde basit dürüyor ama pratikte iş biraz karışabiliyor. Her biri farklı bir senaryo için iyi geliyor, mesela aktif veri başka yerde dursun, arşiv başka yerde sürünsün (ciddiyim). İşte kaba bir eşleme tablosu:
| Katman | Uygun Senaryo | Erişim Sıklığı | Min. Bekletme |
|---|---|---|---|
| Hot | Aktif uygulama verisi | Sürekli | Yok |
| Cool | Aylık raporlar, yedekler | Ayda birkaç | 30 gün |
| Cold | Uzun süreli backup | 3 ayda bir | 90 gün |
| Archive | Yasal saklama, log arşivi | Yılda bir | 180 gün |
Lifecycle management policy yazın derim. Bir kere kuruyorsunuz ve sonra kendi hâline bırakıyorsunuz — sistem eski blob’ları otomatik olarak alt katmanlara indiriyor (tabi burada prefix’leri doğru vermek şart). Örnek bir JSON policy şöyle:
Bunu biraz açayım.
{
"rules": [{
"name": "logArchiveRule",
"enabled": true,
"type": "Lifecycle",
"definition": {
"filters": { "blobTypes": ["blockBlob"], "prefixMatch": ["logs/"] },
"actions": {
"baseBlob": {
"tierToCool": { "daysAfterModificationGreaterThan": 30 },
"tierToArchive": { "daysAfterModificationGreaterThan": 180 },
"delete": { "daysAfterModificationGreaterThan": 730 }
}
}
}
}]
}Managed Disk Tuzakları
Şöyle ki, Beni en çok şaşırtan konu snapshot birikmesi öldü (kendi tecrübem). Ekipler snapshot alıyor, ihtiyaç bitiyor, sonra bir düşüneyim… silmeyi unutuyor; yanı olay tam böyle sessiz sedasız ilerliyor. Aylar sonra bakıyorsunuz, TB’lar dolusu boş yere tutulmuş snapshot var ve fatura da usül usül şişmiş (bu beni çok şaşırttı)
Garip gelecek ama, Bir de disk boyutu işi var; eskiden P30 (1 TB) ile P20 (512 GB) arasında geçiş yapmak için diski boşaltıp yeniden oluşturmak gerekiyordu (ben de ilk duyduğumda şaşırmıştım). Şimdi Azure’da disk downsizing daha kolaylaştı ama hâlâ tam otomatik değil, el değmesi gereken yerler çıkabiliyor. Otomatize etmek lazım, yoksa biri büyük ihtimalle unutuyor.
Bunu biraz açayım.
Neyse, çok dağıtmayayım; Azure storage tarafı benim için ayrı bir dünya zaten. Geçmişte bu konuda yazmıştım da:
Bandwidth: Cross-Region Trafiği Öldürür
Cross-region veri transferi Azure’da en pahalı network kalemlerinden biri. Hatta aynı region içindeki AZ’ler arası trafik bile ücretli olabiliyor. Su senaryo çok tanıdık: uygulama West Europe’ta, veritabanı North Europe’ta; neden diye soruyorsun, cevap da genelde “yer vardı burada” oluyor, biraz aceleyle alınmış bir karar yanı.
Bakın, Aylık faturada bandwidth kalemi 10 bin dolara kadar çıkabiliyor böyle senaryolarda. Halbuki iki kaynağı aynı region’a taşımak tek seferlik bir is, sonra rahatliyorsun; uzun vadede kendini fazlasıyla karşılıyor, hatta bazen “bunu niye daha önce yapmamisiz” dedirtiyor.
Evet.
Public IP Enflasyonu
Bu klasik mesele. Test için açılan public IP’ler kalıp gidiyor, kimse de fark etmiyor; Standard SKU IP’ler artık bedava değil, saatlik ücret var ve 100 tane atıl public IP demek yıl sonunda hiç hoş olmayan bir rakam çıkması demek.
Bak şimdi, Azure Resource Graph’ta su sorguyla atıl IP’leri bulabiliyorsunuz:
Resources
| where type =~ 'microsoft.network/publicipaddresses'
| where properties.ipConfiguration == ''
| project name, resourceGroup, location, sku.nameNeyse, konu basit gibi görünüyor ama değil. Bir kez temizlik yapmayinca bu IP’ler sessizce bekliyor, fatura da usül usül büyüyor (kendi tecrübem)
NAT Gateway vs Instance-Level Public IP
Ne yalan söyleyeyim, Küçük ekipseniz. Az sayıda VM’ınız varsa, her VM’e Instance-Level Public IP takmak ilk anda kolay geliyor. Ama VM sayısı 10’u geçtiğinde NAT Gateway hem daha ekonomik oluyor hem de daha güvenli tarafa geçmenizi sağlıyor; geçiş zamanında yapılmalı çünkü biriktikce is zorlaşıyor, migrasyon da uzadıkça uzuyor.
Hani bazen “sonra bakarız” denir ya, işte o sonra pek gelmiyor. Bu yüzden network tarafındaki ufak görünen kalemleri erken yakalamak lazım; yoksa ay sonunda surprise diye karşımıza cikiyorlar.
Sürekli Optimizasyon: Bir Kültür Meselesi
Bir şey dikkatimi çekti: Buraya kadar teknik tarafı konuştum (en azından benim deneyimim böyle). Şimdi asıl can sıkıcı ama önemli yere geleyim: bu iş bir kere yapılıp kenara bırakılan bir proje değil. FinOps dediğiniz şey kültür oluyor, süreklilik istiyor, biraz da disiplin dayatıyor. Evet, tam olarak öyle. Daha fazla bilgi için
Herkes İçin Geçerli Prensipler
Kurum büyük olsun küçük olsun fark etmiyor; boyut değişiyor ama bazı kurallar değişmiyor. Üç temel prensip var ve bunlar biraz sert gelebilir ama bence doğru:
- Görünürlük olmadan optimize etme olmaz: Azure Cost Management ve tag disiplini olmadan sağlıklı ilerleyemezsiniz.
- Sahiplik olmadan tasarruf olmaz: Her kaynağın bir sahibi olmalı. Sahipsiz kaynak = ölü kaynak. (bu kritik)
- Ölçüm olmadan başarı iddia edilemez: “Bu ay %20 tasarruf ettik” diyebilmek için önceki ayı bilmeniz gerekiyor. — ciddi fark yaratıyor
Bazı ekipler bunu başta hafife alıyor, sonra fatura gelince yüzleri düşüyor. Evet. Aslında olay şu: görünmeyen şeyi optimize edemezsiniz (çok basit geliyor ama pratikte herkes tökezliyor), sahiplenilmeyen şeyi de kimse savunmuyor. Sonuç mu? Rakamlar kendi başına konuşmaya başlıyor.
Nereden Başlamalı? Pratik İlk 30 Gün
Bu yazıyı okuyup “tamam, bir şeyler yapmalıyım” diyenler için, işte elle tutulur bir yol haritası: lafı gevelemeden ilerleyelim.
Şöyle ki, 1. Hafta: Azure Cost Management’ı açın. Son 3 ayın — ki bu tartışılır — harcamasını kategori kategori çıkarın, sonra bir bakın; çoğu zaman en pahalı görünen şey değil, aslında sessizce akan kalem can sıkıyor (buna dikkat edin). Şaşırdım açıkçası.
Tuhaf ama, 2. Hafta: Azure Advisor’a girin, “Cost” tab’ını açın. Oradaki rightsizing, RI ve unused resource önerilerini bir Excel’e dökün, ama düz liste olarak bırakmayın; önce etkiyi, sonra işi kimin çözeceğini yanına yazın. Böyle olunca tablo biraz daha işe yarıyor.
3. Hafta: En büyük 5 VM’i inceleyin. Metriklere bakın, gerçekten o boyutta kalmaları gerekiyor mu diye sorun kendinize; bazen cevap net oluyor, bazen de insan “hmm, bu niye böyle durmuş?” diye kalıyor. En az 1-2 tanesi için küçültme kararı çıkarmaya çalışın (yanlış duymadınız)
4. Hafta: Reserved Instance analizi yapın. Sürekli çalışan iş yükleri için 1 yıllık RI planı çıkarın; her senaryoda mucize beklemeyin ama düzgün kurgulanırsa faturada hissedilir bir düşüş geliyor, hatta bazı yapılarda %30 civarı fark bile görülebiliyor.
Optimizasyon dediğimiz şey aslında disiplin. Sihirli bir formül yok. Düzenli bakan kazanır.
Bu arada altyapı optimizasyonu tarafında Linux iş yükleri için storage seçimi de kritik bir konu — Azure Files NFS ile Linux İş Yükleri: Sahadan Notlar yazımda bu konuya girmiştim, ilgilenenler için oradan devam edilebilir. Burada, neyse, çok dağıtmayayım; ama burada da aynı mantık geçerli: doğru yeri kurcalayınca sonuç hemen kendini belli ediyor.
Sıkça Sorulan Sorular
Reserved Instance almak riskli mi? Ya iş yükü değişirse?
Azure RI’lar aslında sanıldığı kadar sert değil. Yanı aynı VM ailesi içinde exchange yapabiliyorsunuz, (söylemesi ayıp) hatta region bile değiştirebiliyorsunuz. Kısacası, üstüne bir de iptal opsiyonu var (küçük bir ceza ödüyorsunuz tabiî). Bence 1 yıllık RI’lar için “risk” argümanı pek tutmuyor — çoğu senaryoda RI almamak daha pahalıya geliyor.
Çok konuştum, örnekle göstereyim.
Azure Hybrid Benefit gerçekten işe yarıyor mu?
Vallahi yarıyor. Windows Server ve SQL Server lisansınız varsa bunları Azure’a taşımak, Windows VM maliyetinizi %40’a yakın düşürebiliyor. Açıkçası Türkiye’de EA anlaşması olan kurumların çoğunda bu benefit hâlâ kullanılmıyor — hani ciddi bir kayıp bu. İlk bakılacak yerlerden biri burası olmalı.
Spot VM’leri production’da kullanmak mantıklı mı?
Kritik uygulamalar için hayır. Azure herhangi bir anda sadece 30 bir düşüneyim… saniye önceden haber verip makinayı kapatabilir. Ama mesela batch processing, video encoding, CI/CD runner ya da ML training gibi kesintiye toleranslı iş yükleri için %70-90 arası tasarruf sağlıyor. Tecrübeme göre doğru yerde kullanılınca gerçekten altın değerinde.
Küçük bir şirketiz, FinOps tool’una para vermeye değer mi?
Aylık faturanız 5.000 USD’nın altındaysa Azure’un kendi araçları (Cost Management, Advisor) gayet yeterli. 10.000 USD’yi geçince üçüncü parti FinOps araçları (CloudHealth, Apptio Cloudability vb.) yatırımın kendini daha hızlı amorti ettiriyor. Onun altında zaten Excel + Azure yerleşik araçları idare eder.
Rightsizing sonrası performans sorunu yaşarsam ne olur?
Bakın, Azure’da VM boyutunu değiştirmek 5-10 dakikalık bir iş (VM restart gerekiyor). Yanı küçültüp beğenmezseniz aynı gün eski boyuta dönebiliyorsunuz. Bu yüzden rightsizing’e “büyük risk” gözüyle bakmayın — aslında kolayca geri alınabilen bir aksiyon bu.
Kaynaklar ve İleri Okuma
Azure Cost Management Best Practices — Microsoft Learn
Daha açık söyleyeyim, garip gelecek ama, Azure Well-Architected Framework: Cost Optimization Pillar
Azure Advisor Cost Recommendations Reference (ben de ilk duyduğumda şaşırmıştım)
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments