Gerçek Hayattan Bulut Maliyetlerini Azaltma. Geçen Yıl Bulut Masraflarını Nasıl %35 Azalttık?
Cloud cost optimisation benim için artık tek seferlik bir “bahar temizliği” değil.
Son bir yılda bunun aslında sürekli ele alınması gereken bir mühendislik disiplini olduğunu net şekilde gördüm.
Geçtiğimiz yıl boyunca dört farklı AWS hesabında ve birden fazla ortamda (non‑prod ve prod dahil) maliyetleri sistematik olarak azaltmaya odaklandım. Bazı kazanımlar küçük görünüyordu, bazıları ise daha derin mimari ve operasyonel değişiklikler gerektirdi. Ancak zamanla hepsi birikerek anlamlı sonuçlar üretti.
Bu süreçten çıkardığım en büyük ders şuydu:
Göremediğin şeyi optimize edemezsin.
Görünürlük sağlandıktan sonra gerisi tamamen mühendislik işi oluyor: önce büyük maliyet kalemlerine odaklanmak, varsayımları sorgulamak ve evet — production ortamlarını da dikkatli şekilde ele almak.
Bu yazıyı “şunu yap, bunu yapma” demek için değil; bir bulut mühendisi olarak yaşadıklarımı diğer bulut mühendisleriyle paylaşmak için yazıyorum. İşine yarayanı alabilir, gerisini rahatlıkla es geçebilirsin.
Sonuçlar (Yıl Bazında)
AWS Hesap A
- Non‑Prod: %35 azalma
- Prod: %24 azalma
AWS Hesap B
- Non‑Prod: %11 azalma
- Prod: %5 artış
Son satır özellikle önemli.
Bir ortamda production maliyeti arttı ve bu tamamen bilinçli ve kabul edilebilir bir artıştı. Yeni workload’lar devreye alındı, erişilebilirlik artırıldı ve daha fazla iş değeri üretildi.
Zihinsel dönüşüm:
Cost optimisation, “ne pahasına olursa olsun daha az harca” anlamına gelmez.
Bazı durumlarda daha iyi güvenlik, dayanıklılık ya da performans daha pahalıya mal olur — ve üretilen değer bunu karşılıyorsa, bu son derece doğaldır. Asıl hedef, akıllı harcamaktır.
Gerçekten İşe Yarayan Yaklaşım
1) Önce Güçlü Bir Görünürlük Sağlamak
Her şey burada başladı.
En fazla fayda sağladığım adımlar:
- Tutarlı ve kapsamlı tagging
(Environment, App/Service, Owner, CostCenter, BusinessUnit, Compliance vb.) - Tag’leri AWS Organisations Tag Policies ve AWS Config ile zorunlu hale getirmek
- Cost & Usage Report (CUR) yapılandırmak ve gerektiğinde Athena ile detaylı analiz yapmak
Beklediğimden çok daha büyük etkisi olan bir konu da şuydu:
maliyetleri düzenli olarak mühendislerle paylaşmak.
Cost grafikleri stand‑up’lara ve sprint review’lara girdiğinde davranışlar değişti. Sadece finance ekibine giden raporlara kıyasla, geliştirme ekipleriyle yapılan aylık cost review’lar optimizasyon fırsatlarını çok daha hızlı ortaya çıkardı.
İnsanlar görebildikleri şeyleri düzeltir.
2) Önce Büyük Maliyet Kalemlerine Odaklanmak
En büyük tasarruflar hiçbir zaman mikro ayarlardan gelmedi.
Asıl fark yaratan alanlar:
- Veritabanları (RDS)
- Compute (EC2, Auto Scaling, fazla kapasite)
- Observability (CloudWatch log ve metrikleri)
- Storage (EBS snapshot’lar, ECR image’ları)
Basit ama etkili bir alışkanlık: Dev/test ortamlarını 15 dakika daha erken kapatabiliyorsak, kapatmak.
Bu tür küçük iyileştirmeler yeterince tekrarlandığında ciddi tasarruf yaratıyor.
3) Production Dokunulmaz Değil
Eskiden production’a hiç dokunulmaması gereken bir alan gibi yaklaşırdım.
Gerçek şu ki production kutsal değil, sadece daha hassas.
Zaman içinde production ortamlarında şunlar birikiyor:
- Sahipsiz EBS snapshot’lar
- Boşta duran Elastic IP’ler
- Eski ve kullanılmayan ECR image’ları
- Gereğinden uzun log retention süreleri
- Fazla büyük instance’lar
Değişiklik pencereleri, kademeli geçişler ve temkinli testlerle production ortamlarını da güvenli şekilde optimize etmek mümkün.
Dikkatli olmak, hiç dokunmamak anlamına gelmiyor.
Somut Aksiyonlar ve Etkileri
A) Gereksiz Kaynakları Kaldırmak veya Yeniden Düzenlemek
- Gereksiz DB ve compute kullanımını kaldırmak veya yeniden yapılandırmak
- Aktif olarak kullanılmayan bir staging ortamını kapatmak (yaklaşık %9 tasarruf)
- Shared hesapta kalan eski bir Windows instance’ı kaldırmak
Hızlı tespit için kullandığım sinyaller:
- Uzun süreli düşük CPU, IOPS ve network kullanımı
- AWS Compute Optimiser önerileri
- Owner veya Environment tag’i olmayan kaynaklar
B) Storage Hijyeni (EBS, RDS, ECR)
Eğlenceli bir iş değil, ama etkisi oldukça büyük.
- Kullanılmayan EBS snapshot’lar (non‑prod): %22 azalma
- Kullanılmayan EBS snapshot’lar (prod): %47 azalma
- Gereksiz RDS snapshot’lar: %3 azalma
- İlk ECR image temizliği: %23 azalma
Uyguladığım genel yaklaşım:
- Belirli bir süreden eski snapshot’ları listelemek
- Kaynağı hâlâ var mı kontrol etmek
- Gerekli yedekleri tutmak
- Kalanları silmek ve mümkün olan yerlerde lifecycle ile otomatikleştirmek
Lifecycle policy’ler sonrasında ECR tarafında kalıcı olarak yaklaşık %61’lik bir azalma sağlandı.
C) RDS Çalışma Süresi Optimizasyonu
- Non‑prod RDS çalışma saatlerini azaltarak yaklaşık %15 tasarruf sağlandı.
Nasıl:
- EventBridge ve Lambda (veya SSM Automation) ile mesai dışı stop/start
- RDS kapasite ayarlarını gerçek kullanım ihtiyacına göre güncellemek
- Performance Insights ile idle süreleri analiz etmek
D) Observability Maliyetleri (CloudWatch)
En çok şaşırdığım alan burası oldu.
- CloudWatch maliyetleri yıl bazında yaklaşık %58 azaldı.
Etkili olan adımlar:
- Log retention’ı agresif şekilde azaltmak
(non‑prod: 7–14 gün, prod: 30–90 gün; regülasyonlar aksi değilse) - High‑cardinality custom metric’leri temizlemek
- Gürültülü log’ları kapatmak, debug log’ları yalnızca gerektiğinde açmak
- Uygun yerlerde log yerine metric kullanmak
E) Compute Right‑Sizing ve Zamanlama
- Belirli bir platformda EC2 maliyetlerinde yaklaşık %17 azalma sağlandı.
İşe yarayan pratikler:
- Compute Optimiser önerilerini düzenli incelemek
- Uyumlu senaryolarda yeni nesil instance’lara ve Graviton’a geçmek
- Auto Scaling minimum ve maksimum değerlerini gerçekçi tutmak
- Batch ve CI workload’larda Spot instance kullanmak
Servis Bazlı Öne Çıkan Sonuçlar
- CloudWatch: %58 azalma
- Amazon Neptune: %33 azalma
- Amazon OpenSearch: %100 azalma (kullanılmadığı için tamamen kaldırıldı)
- Amazon ECR: %61 azalma (lifecycle policy sonrası)
Production Güvenle Optimize Edilebilir: Kontrol Listem
- Sahipsiz kaynakları temizlemek (snapshot, EIP, boş load balancer’lar)
- CloudWatch retention’ı gerçek compliance ihtiyacına çekmek
- RDS ve EC2 instance’larını right‑size etmek
- Pahalı log desenlerini metric’lerle değiştirmek
- Dayanıklılığı bozmuyorsa NAT Gateway konsolidasyonu yapmak
- Graviton geçişlerini mutlaka yük testleriyle doğrulamak
Kültür, En Büyük Çarpan Oldu
Teknik değişiklikler önemliydi; ancak asıl farkı yaratan şey kültürdü.
- Maliyet, ekiplerin ortak konusu hâline geldi
- Suçlama yerine bağlam konuşuldu
- Aylık review’lar sahiplenmeyi artırdı
- Küçük kazanımlar görünür şekilde paylaşıldı
İnsanlar yaptıkları işin somut etkisini gördüğünde, cost farkındalığı çok hızlı yayılıyor.
30 / 60 / 90 Günlük Basit Bir Plan
Gün 1–30
- CUR, Budget ve Anomaly Detection etkinleştirmek
- Tag politikalarını zorunlu kılmak
- Snapshot, ECR ve log retention temizliği
Gün 31–60
- Non‑prod schedule’ları uygulamak
- En pahalı kaynakları right‑size etmek
- Kullanılmayan ortamları kaldırmak
Gün 61–90
- Production ortamlarını temkinli şekilde optimize etmek
- Mimari trade‑off’ları değerlendirmek
- IaC üzerinden guardrail’leri kalıcı hale getirmek
Taviz Vermediğim Prensipler
- Mümkün olduğunca her şeyi tag’lemek
- Production ortamlarının “dokunulmaz” olmadığını kabul etmek
- Güvenlik ve erişilebilirlik maliyetleri artırabilir; değer üretiyorsa bu kabul edilebilir
- Görünürlük, tahminden her zaman daha iyidir
- Bir kerelik büyük hamleler yerine sürekli küçük iyileştirmeler kazanır
Eğer sen de cloud maliyetlerini optimize etmeye çalıştıysan — ister başarılı ol ister zorlan — deneyimlerini duymak isterim. Bu alan, paylaştıkça çok daha yönetilebilir hale geliyor.
