Cloud Faturası Neden Beklenenden Yüksek Gelir?

Kısaca

Cloud faturası beklenenden yüksek geldiğinde ilk yapılması gereken provider değiştirmek değil, artışın hangi servis, kaynak, proje ve environment'ta başladığını bulmaktır. En sık nedenler fazla boyutlandırılmış compute kaynakları, açık unutulan development/test ortamları, storage ve snapshot birikimi, database tier büyümesi, network/egress trafiği, log hacmi, commitment hataları ve ownership eksikliğidir.

Dynamis Teknoloji'de cloud maliyetini yalnız fiyat listesi üzerinden değil, kullanım, mimari, operasyon ve toplam sahip olma maliyeti birlikte değerlendirilerek analiz ediyoruz.

Cloud faturası neden beklenenden yüksek gelir?

Cloud maliyeti tek bir kalem değildir.

Toplam fatura şu bileşenlerin birleşiminden oluşabilir:

• compute
• storage
• database
• network ve egress
• backup
• monitoring ve logging
• managed services
• lisans
• support
• commitment / reservation
• development ve staging ortamları

Bu nedenle "VM fiyatı değişmedi ama fatura arttı" senaryosu oldukça normaldir. Artış başka bir servis veya kullanım davranışından geliyor olabilir.

1. Kaynak kullanımı büyümüş olabilir

En basit neden gerçekten daha fazla kaynak kullanıyor olmanızdır.

Örneğin:

• yeni VM'ler açıldı
• mevcut VM büyütüldü
• Kubernetes node sayısı arttı
• database tier yükseltildi
• storage kapasitesi büyüdü
• yeni Region açıldı
• yeni kullanıcı veya müşteri trafiği geldi

Büyüme business açısından doğru olabilir. Problem, artışın bilinmeden gerçekleşmesidir.

İlk kontrol:

1. Bu ay ile önceki ayı karşılaştırın.
2. En büyük artışı gösteren servisleri bulun.
3. Servis içinde kaynak seviyesine inin.
4. Artışın hangi tarihte başladığını belirleyin.
5. O tarihte deployment, migration veya kapasite değişikliği olup olmadığını kontrol edin.

2. VM ve instance'lar gereğinden büyük olabilir

Cloud ortamlarında sık görülen problemlerden biri overprovisioning'dir.

Örneğin:

• 8 vCPU VM yalnızca %10-15 CPU kullanıyor
• 32 GB RAM'li sunucuda peak kullanım 8 GB
• production için seçilen instance staging'e de aynen kopyalanmış
• yeni nesil daha verimli instance family kullanılmıyor

Ancak yalnız ortalama CPU'ya bakarak instance küçültmek doğru değildir.

Rightsizing sırasında şu metrikler birlikte incelenmelidir:

• p95 CPU
• memory
• disk IOPS
• network throughput
• latency
• peak saatler
• autoscaling davranışı
• failover ihtiyacı
• büyüme trendi

Cloud cost optimization ve FinOps hizmeti, rightsizing'i yalnız "bir boy küçültme" işlemi olarak değil production riskleriyle birlikte ele alır.

3. Development ve staging kaynakları 7/24 açık kalıyor olabilir

Küçük yazılım ekiplerinde önemli maliyet kalemlerinden biri production dışı ortamlardır.

Örnek:

• staging VM gece ve hafta sonu açık
• test database production boyutunda
• geçici feature environment kapatılmamış
• developer sandbox'ları unutulmuş
• QA ortamı sürekli yüksek kapasitede

Bu ortamlar gerçekten 7/24 gerekli değilse schedule veya otomatik kapatma uygulanabilir.

Örneğin:

• mesai saatlerinde aç
• gece kapat
• hafta sonu minimum kapasite
• yalnız test pipeline sırasında oluştur
• preview environment'ı TTL ile otomatik sil

Bu yaklaşım production performansına dokunmadan maliyeti azaltabilir.

4. Disk, snapshot ve backup birikmiş olabilir

Compute kaynakları silinse bile bağlı storage maliyeti devam edebilir.

Sık karşılaşılan örnekler:

• unattached disk
• eski EBS / managed disk
• snapshot birikimi
• gereksiz uzun backup retention
• eski database backup'ları
• kullanılmayan object storage
• log archive'ları

Buradaki risk, "eski" görünen her şeyi silmektir.

Önce owner, son kullanım, recovery gereksinimi, retention policy ve compliance ihtiyacı doğrulanmalıdır.

5. Database maliyeti sessizce büyüyor olabilir

Managed database maliyetleri compute tier, storage, IOPS, backup, read replica, high availability, data transfer ve lisans gibi birden fazla bileşenden oluşabilir.

Kontrol edin:

• CPU / memory
• connection sayısı
• slow query
• storage büyümesi
• read/write IOPS
• replica gereksinimi
• HA gerçekten gerekli mi?
• backup retention doğru mu?

Database maliyetini yalnız "instance fiyatı" üzerinden değerlendirmek eksik kalır.

6. Network ve egress maliyeti artmış olabilir

Cloud faturasında en zor fark edilen kalemlerden biri network'tür.

Artış şunlardan gelebilir:

• internet data transfer out
• cross-AZ trafik
• inter-region trafik
• NAT Gateway
• load balancer
• backup replication
• object storage download
• multi-cloud trafik
• CDN bypass

Egress maliyeti nasıl düşürülür? rehberi network maliyetini ayrı olarak ele alır.

7. Monitoring ve logging maliyeti kontrolsüz büyüyebilir

Observability servisleri kritik olabilir ama yanlış retention ve ingestion modeli pahalı hale gelebilir.

Kontrol edilmesi gerekenler:

• log ingestion miktarı
• debug log'lar production'da açık mı?
• retention süresi
• high-cardinality metric'ler
• duplicate log
• gereksiz trace sampling
• eski workspace / log group
• audit log gereksinimleri

Amaç logging'i kapatmak değil, hangi logun operasyonel değeri olduğunu ayırmaktır.

8. Savings Plan, Reserved Instance veya reservation doğru kullanılmıyor olabilir

Commitment modelleri maliyeti düşürebilir ancak yanlış alınırsa tasarruf yerine yeni maliyet yaratabilir.

İki temel KPI önemlidir:

• coverage: kullanımın ne kadarı indirimli model kapsamında?
• utilization: satın alınan taahhüdün ne kadarı gerçekten kullanılıyor?

Savings Plan mı, Reserved Instance mı? rehberi bu kararı ayrıntılı açıklar.

Commitment almadan önce rightsizing ve workload placement yapılmalıdır.

9. Tagging ve ownership eksikliği maliyeti görünmez yapabilir

Owner'ı belli olmayan kaynaklar kolay unutulur.

Minimum tagging örneği:

• owner
• project
• environment
• application
• customer
• cost-center

Maliyet görünürlüğü, optimizasyonun temelidir.

10. Cloud faturası artarken developer time da artıyor olabilir

Cloud maliyetini yalnız provider faturası olarak değerlendirmek eksik olabilir.

Gerçek toplam maliyet; cloud faturası, lisans, operasyon zamanı, incident maliyeti ve bakım yükünün birlikte değerlendirilmesini gerektirir.

Örneğin daha ucuz bir altyapı, geliştiricilerin her hafta patch, backup, deployment, monitoring, incident ve network troubleshooting ile uğraşmasına neden oluyorsa toplam maliyet daha yüksek olabilir.

11. Autoscaling yanlış çalışıyor olabilir

Autoscaling yalnız maliyet düşürmez; yanlış konfigürasyonda maliyeti artırabilir.

Problemler:

• scale-out çok agresif
• scale-in çok yavaş
• minimum replica gereğinden yüksek
• test ortamında autoscaling açık
• metric yanlış seçilmiş
• spike sonrası kapasite düşmüyor

12. Yeni kaynaklar açılıyor ama eskileri kapatılmıyor olabilir

Migration ve deployment sonrası duplicate kaynaklar sık görülür. Bu yüzden her deployment veya migration sürecinde decommission checklist olmalıdır.

Cloud faturasını 30 dakikada nasıl hızlı tararsınız?

1. Bu ay vs önceki ay toplam fark
2. Top 5 servis
3. Top 20 kaynak
4. Yeni açılan kaynaklar
5. Idle / düşük kullanılan compute
6. Unattached disk ve eski snapshot
7. Database tier / storage büyümesi
8. Egress ve NAT maliyeti
9. Log ingestion
10. Commitment coverage / utilization
11. Untagged kaynaklar
12. Dev / staging kaynakları

Bu tarama root cause'u her zaman çözmez ama nerede derinleşmeniz gerektiğini gösterir.

Maliyet artışı her zaman problem midir?

Hayır. Kullanıcı sayısı, trafik, availability, backup, security veya monitoring kapsamı büyüdüyse maliyet artışı normal olabilir.

Buradaki temel soru: Maliyet artışı business value ve teknik gereksinimle orantılı mı?

Provider değiştirmek çözüm mü?

Bazen. Ama provider değişimi engineering effort, migration, downtime, data transfer, yeniden test ve yeni operasyon bilgisi maliyeti yaratır.

Bu nedenle önce mevcut ortamın gerçek optimizasyon potansiyeli ölçülmelidir.

AWS kullanıyorsanız AWS yönetim hizmeti, Azure kullanıyorsanız Azure yönetimi hizmeti mevcut ortamı iyileştirmek için ayrı commercial destination'lardır.

Provider değişimi ancak toplam teknik ve ticari avantaj netse düşünülmelidir.

FinOps bu problemi nasıl çözer?

FinOps yalnız fatura azaltma projesi değildir.

Pratik yaklaşım üç aşamalıdır:

Görünürlük

Hangi ekip, proje ve resource maliyet üretiyor?

Optimizasyon

Rightsizing, idle kaynak, storage, network ve commitment fırsatları uygulanır.

Sürekli kontrol

Budget, tagging, anomaly detection ve düzenli review ile maliyet drift'i önlenir.

Dynamis'in FinOps hizmeti, AWS, Azure ve diğer cloud ortamlarında bu süreci production performansını koruyarak yönetir.

Dynamis Cloud Maliyet Analizinde neye bakıyor?

İlk assessment'ta kapsamınıza göre provider ve account yapısı, top cost services, resource ownership, VM/instance utilization, database, storage, backup, network/egress, commitment, dev/staging, tagging, budget, anomaly ve developer operations yükü incelenir.

Çıktı yalnız "şunu kapatın" listesi değildir. Aksiyonlar tasarruf potansiyeli, production riski, uygulama eforu, owner ve öncelik ile sıralanmalıdır.

Sık yapılan hatalar

Sadece en pahalı VM'e bakmak: Toplam maliyet storage, network ve database'den gelebilir.

Ortalama CPU'ya göre küçültmek: Peak, memory, IOPS ve latency'yi kontrol edin.

Commitment'ı ilk çözüm yapmak: Önce waste ve rightsizing.

Backup'ı maliyet diye kapatmak: Recovery ve RPO/RTO gereksinimini doğrulayın.

Tagging'i ertelemek: Ownership yoksa waste tekrar oluşur.

Provider değiştirmeyi otomatik çözüm sanmak: Migration TCO'sunu hesaba katın.

Tek seferlik cleanup yapmak: Yeni kaynaklarla maliyet tekrar büyür.

Sonuç

Cloud faturası beklenenden yüksek geldiğinde ilk soru "hangi provider daha ucuz?" olmamalıdır. Önce artışın nerede başladığını, kaynağın owner'ını, gerçek kullanım değişimini, fazla kapasiteyi, storage/network büyümesini, commitment durumunu ve dev/staging kontrolünü görünür hale getirin.

Bu görünürlük sağlandıktan sonra gerçek optimizasyon kararı verilebilir.

Sırada ne var

• Egress Maliyeti Nasıl Düşürülür?
• Savings Plan mı, Reserved Instance mı?
• Azure Faturasını Satır Satır Okuma
• FinOps hizmeti
• AWS yönetim hizmeti
• Azure yönetimi hizmeti

Kaynaklar

• AWS Cost Optimization Hub
• AWS Cost Anomaly Detection
• Microsoft Cost Management documentation