Egress Maliyeti Nasıl Düşürülür? Cloud Veri Transferi Maliyetlerini Azaltma

Kısaca

Egress, verinin cloud ortamından internete, başka bir Region'a, başka bir Availability Zone'a, başka bir cloud'a veya belirli ağ servislerinden geçerek çıkmasıdır. Birçok cloud mimarisinde compute fiyatı optimize edilirken network akışı gözden kaçtığı için egress, NAT ve cross-zone transfer ücretleri zamanla anlamlı maliyet üretir.

Dynamis Teknoloji'de egress optimizasyonunu yalnız "daha ucuz provider bulma" konusu olarak ele almıyoruz. Önce trafik yolunu çıkarıyor, sonra gereksiz veri hareketini azaltıyor, cache/CDN oranını artırıyor, same-zone placement'i iyileştiriyor, NAT ve inter-region akışlarını sadeleştiriyor ve ancak bundan sonra sağlayıcı fiyatlarını karşılaştırıyoruz.

Egress ve ingress arasındaki fark

Ingress, verinin cloud ortamına girmesidir.

Egress, verinin cloud kaynağından dışarı veya başka bir ücretli network sınırına çıkmasıdır.

Örnekler:

• VM → internet
• object storage → kullanıcı
• Region A → Region B
• Availability Zone A → Availability Zone B
• cloud → on-prem
• AWS → Azure
• backup repository → başka lokasyon

Cloud sağlayıcılarında ingress çoğu zaman ücretsiz veya düşük maliyetli olabilir; egress ise servis, Region, yön ve hacme göre ücretlenir.

Egress maliyeti neden görünmez büyür?

Network faturası çoğu zaman tek bir 'egress' satırından oluşmaz.

Ayrı ayrı ücret yaratabilecek alanlar:

• internet data transfer out
• inter-region transfer
• cross-AZ transfer
• load balancer processed data
• NAT Gateway processed data
• CDN cache fill
• CDN egress
• private link / endpoint
• VPN veya dedicated connection
• managed database network traffic

Bu yüzden yalnız toplam TB değerine bakmak yerine hangi verinin hangi kaynaktan hangi hedefe gittiğini çıkarmak gerekir.

1. Trafik akış haritasını çıkarın

İlk adım maliyet kalemlerini mimari akışla eşleştirmektir.

Her önemli trafik için şu alanları kaydedin:

• source
• destination
• Region
• Availability Zone
• protocol
• aylık GB/TB
• peak throughput
• internet mi private mı
• NAT üzerinden mi
• load balancer üzerinden mi
• cache/CDN var mı
• tekrar eden veri mi

Bu harita olmadan egress optimizasyonu yalnız fiyat tablosu karşılaştırmasına dönüşür.

2. Cross-AZ trafiği bulun

Aynı Region içinde olmak her zaman ücretsiz demek değildir.

Özellikle şu desenlerde cross-zone trafik oluşabilir:

• application node başka AZ'de, database başka AZ'de
• load balancer farklı AZ'deki backend'e trafik gönderiyor
• NAT Gateway tek AZ'de, private subnet'ler başka AZ'lerde
• distributed cache farklı AZ'de
• chatty microservice'ler AZ'ler arasında yoğun konuşuyor

HA için multi-AZ tasarım gerekli olabilir; amaç multi-AZ'yi kaldırmak değil, gereksiz cross-AZ veri hareketini azaltmaktır.

3. NAT Gateway maliyetini ayrı ölçün

NAT Gateway mimaride kolaylık sağlar ancak yoğun egress'te iki farklı maliyet oluşturabilir:

• NAT Gateway saatlik ücret
• NAT üzerinden işlenen veri

AWS dokümantasyonu ayrıca başka AZ'deki NAT Gateway'e trafik göndermenin ek cross-AZ data transfer maliyeti oluşturabileceğini belirtir.

Kontrol edin:

• private subnet hangi NAT'a çıkıyor?
• NAT aynı AZ'de mi?
• AWS servis trafiği internet/NAT yolundan mı gidiyor?
• VPC endpoint kullanılabilecek servisler var mı?

Yoğun S3/DynamoDB veya desteklenen AWS service trafiğinde uygun VPC endpoint kullanımı NAT data processing maliyetini azaltabilir.

Azure NAT Gateway tarafında da outbound bandwidth ücretine ek data processing maliyeti bulunabilir.

4. CDN ve cache kullanın

Statik veya tekrar tekrar indirilen içeriği her istekte origin'den göndermek egress'i büyütür.

İyi CDN adayları:

• image
• video
• JavaScript/CSS
• downloadable asset
• public document
• software package
• static API response

CDN, cache hit oranını artırarak origin'den çıkan veriyi azaltabilir.

Ancak CDN ücretsiz değildir.

Toplam maliyet modelinde:

• CDN egress
• request sayısı
• cache fill
• purge/invalidation
• origin egress

birlikte hesaplanmalıdır.

5. Cache-Control politikasını düzeltin

CDN kullanmak tek başına yeterli değildir.

Yanlış cache header nedeniyle hit rate düşük kalabilir.

Kontrol edin:

• Cache-Control
• max-age
• s-maxage
• immutable
• ETag
• Last-Modified
• query string varyasyonu
• cookie varyasyonu

Örneğin aynı static asset her query parametresiyle farklı cache key'e dönüşüyorsa CDN avantajı azalabilir.

6. Büyük dosyaları tekrar tekrar taşımayın

Sık görülen hata:

• backup dosyasını farklı sistemlere tekrar kopyalamak
• analytics export'u her gün full dump olarak göndermek
• aynı media setini farklı Region'lara tekrar tekrar taşımak

Alternatifler:

• incremental transfer
• differential backup
• deduplication
• compression
• object lifecycle
• destination-side processing

olabilir.

7. Backup ve replication trafiğini ayrı yönetin

Backup/DR mimarisinde egress tahmin edilenden hızlı büyüyebilir.

Özellikle:

• full backup her gün başka Region'a
• cross-cloud replication
• uzun retention ile tekrar transfer
• large database log shipping

maliyet yaratabilir.

Backup için şu sorular sorulmalıdır:

• full backup gerçekten ne sıklıkta gerekli?
• incremental mümkün mü?
• cross-region copy gerekli mi?
• restore hedefi neresi?
• immutable copy aynı provider içinde tutulabilir mi?

RPO/RTO hedefi gereksiz veri kopyalamadan karşılanmalıdır.

8. Inter-region trafiği minimize edin

Bir servisi global yapmak her component'i multi-region yapmak anlamına gelmez.

Örnek kötü desen:

• application EU Region
• database başka Region
• object storage üçüncü Region

Bu durumda latency yanında sürekli transfer maliyeti oluşur.

Data gravity prensibiyle:

• compute
• database
• cache
• object storage

mümkün olduğunca aynı workload locality içinde tutulmalıdır.

9. Chatty microservice'leri tespit edin

Microservice sayısı arttıkça network çağrıları da artabilir.

Bir request'in kullanıcıya cevap vermeden önce 20 internal API çağrısı yapması cross-zone veya cross-region ise network maliyetini katlayabilir.

İnceleyin:

• service-to-service request sayısı
• payload size
• response duplication
• retry
• polling
• serialization overhead

Optimizasyonlar:

• response compression
• payload küçültme
• batching
• caching
• event-driven model
• same-zone affinity

olabilir.

10. API payload'larını küçültün

Her API response'ta kullanılmayan alanları göndermek küçük görünse de yüksek request hacminde ciddi data transfer oluşturabilir.

Kontrol edin:

• büyük JSON payload
• gereksiz nested object
• base64 binary
• log/export endpoint
• no compression

Gzip/Brotli, pagination ve field selection network maliyetini düşürebilir.

11. Object storage download pattern'ini inceleyin

Object storage ucuz görünebilir fakat public download veya başka cloud'a yoğun çıkış varsa total cost değişebilir.

Özellikle:

• media platformu
• software distribution
• backup download
• dataset hosting

senaryolarında storage $/GB değil, storage + request + egress toplamı değerlendirilmelidir.

12. Multi-cloud mimaride veri hareketini sınırlandırın

Multi-cloud tasarımda en pahalı desenlerden biri sürekli iki yönlü veri akışıdır.

Örnek:

• app AWS'de
• DB Azure'da
• analytics GCP'de

Bu mimari teknik olarak çalışabilir ancak latency ve egress maliyeti üretebilir.

Daha iyi yaklaşım:

• workload boundary'leri belirleyin
• data ownership tanımlayın
• analytics için batch copy kullanın
• real-time transferi gerçekten gerekli alanlarla sınırlayın

13. Provider değiştirmeden önce iç optimizasyon yapın

Egress yüksek diye doğrudan cloud provider değiştirmek doğru başlangıç olmayabilir.

Önce:

• cross-AZ
• NAT
• inter-region
• cache miss
• duplicate transfer
• oversized payload

temizlenmelidir.

Aksi halde kötü network tasarımını başka sağlayıcıya taşımış olursunuz.

14. Provider fiyatlarını workload bazında karşılaştırın

AWS, Azure ve Google Cloud data transfer fiyatlandırmaları Region, destination, servis ve hacme göre değişir.

Bu yüzden karşılaştırma şu formatta yapılmalıdır:

Yalnız VM fiyatını karşılaştırmak eksik TCO üretir.

AWS tarafında özellikle ne kontrol edilmeli?

AWS için:

• EC2 data transfer
• S3 transfer
• inter-AZ traffic
• inter-region traffic
• NAT Gateway
• Elastic Load Balancing
• CloudFront
• VPC endpoint

ayrı incelenmelidir.

AWS bazı uygun internet data transfer out kullanımlarında belirli aylık ücretsiz kota sunabilir; ancak exact servis/Region şartları güncel pricing sayfasından doğrulanmalıdır.

Azure tarafında özellikle ne kontrol edilmeli?

Azure'da:

• bandwidth outbound
• zone-to-zone
• region-to-region
• NAT Gateway data processing
• Front Door/CDN
• ExpressRoute/VPN

ayrı fiyatlanabilir.

Azure egress ücretleri zone ve destination'a göre değişir; hesaplamayı Azure Pricing Calculator üzerinden güncel Region ile yapmak gerekir.

Egress optimizasyonu için FinOps KPI'ları

Takip edilebilecek KPI'lar:

• network cost / total cloud cost
• internet egress GB/TB
• inter-region GB
• cross-AZ GB
• NAT processed GB
• CDN hit ratio
• origin egress
• cost per GB delivered
• cost per active user
• cost per API request

Bu KPI'lar yalnız fatura değil mimari davranışı da görünür hale getirir.

Egress anomaly alarmı

Network kullanımı dalgalanıyorsa bütçe alarmı yalnız toplam cloud spend'e değil network kategorisine de uygulanmalıdır.

Örnek alarm:

• egress günlük ortalamanın %50 üzerine çıktı
• NAT processed bytes iki katına çıktı
• CDN hit ratio %80'den %55'e düştü
• inter-region transfer aniden arttı

Bu sinyaller yanlış deploy veya routing problemini erken gösterebilir.

Dynamis'te egress maliyeti analizi

Dynamis'in FinOps hizmetinde network maliyetini şu sırayla inceliyoruz:

1. fatura kalemlerini normalize et
2. source/destination trafik haritasını çıkar
3. cross-AZ ve inter-region akışı bul
4. NAT ve load balancer maliyetini ayır
5. CDN/cache hit oranını ölç
6. backup/replication trafiğini incele
7. gereksiz veri hareketini azalt
8. provider/TCO karşılaştırmasını en son yap

Amaç yalnız GB başına fiyatı düşürmek değil, gereksiz GB'ın oluşmasını engellemektir.

Sık yapılan hatalar

Aynı Region = ücretsiz sanmak: Cross-AZ ve servis yolları maliyet oluşturabilir.

NAT maliyetini internet egress'e karıştırmak: NAT'ın ayrıca data processing maliyeti olabilir.

CDN her zaman ucuzdur demek: Hit ratio ve CDN fiyatı birlikte hesaplanmalıdır.

Backup trafiğini küçümsemek: Büyük full backup'lar network faturasını hızla büyütebilir.

Multi-cloud'u ücretsiz network sanmak: Provider'lar arası trafik genellikle egress üretir.

Compute fiyatına göre provider seçmek: Network TCO'yu değiştirebilir.

Sırada ne var

• Savings Plan mı, Reserved Instance mı?
• AWS'den çıkış: maliyeti düşüren bulut göçü planı
• AWS alternatifi: hangi iş yükü nerede kalmalı?
• FinOps hizmeti

Kaynaklar

• AWS EC2 On-Demand Pricing — Data Transfer
• AWS NAT Gateway Pricing
• AWS CloudFront Pricing
• Azure Bandwidth Pricing
• Azure NAT Gateway Pricing
• Google Cloud Network Pricing
• Google Cloud CDN Pricing