AWS Fiyatlandırma Nasıl Çalışır? AWS Maliyeti Nasıl Hesaplanır?

Kısaca

AWS fiyatlandırması tek bir sunucu fiyatından oluşmaz. Toplam maliyet; compute, storage, database, network, public IPv4, load balancer, NAT Gateway, monitoring, backup ve commitment modellerinin birleşimidir.

Bu nedenle AWS maliyetini hesaplamak için yalnız EC2 saatlik fiyatına bakmak yeterli değildir. Sağlıklı yaklaşım, workload'u servis bazında modellemek ve gerçek kullanım verisiyle düzenli olarak karşılaştırmaktır.

Dynamis Teknoloji'de AWS maliyet analizini mimari + kullanım + operasyon + taahhüt birlikte ele alınarak yapıyoruz.

AWS fiyatlandırma nasıl çalışır?

AWS genel olarak kullandıkça öde modeline dayanır; ancak her servisin ölçüm birimi ve fiyatlandırma yapısı farklı olabilir.

Örneğin:

• EC2: instance tipi ve kullanım süresi
• EBS: volume kapasitesi ve bazı volume tiplerinde provisioned performans
• S3: storage, request ve data transfer
• RDS: instance, storage, I/O, backup ve deployment modeli
• NAT Gateway: saat ve işlenen veri
• Load Balancer: çalışma süresi ve kapasite/kullanım metrikleri
• CloudWatch: metric, log ingestion, retention ve alarm kullanımına göre

Toplam AWS faturası bu servislerin birlikte kullanımından oluşur.

AWS maliyetini hesaplamaya nereden başlanmalı?

Önce workload'u bileşenlerine ayırın:

1. compute
2. storage
3. database
4. network
5. backup
6. monitoring
7. lisans
8. commitment

Sonra her bileşenin kullanım modelini belirleyin.

1. EC2 compute maliyeti

EC2 maliyeti şu faktörlere göre değişir:

• instance family
• instance size
• işletim sistemi
• Region
• tenancy
• kullanım süresi
• pricing model

Örneğin Windows instance, Linux instance'tan lisans nedeniyle farklı maliyet oluşturabilir.

AWS EC2 Nedir? production EC2 mimarisini daha ayrıntılı ele alır.

2. EBS storage maliyeti

EC2 instance kapalı olsa bile bağlı EBS volume maliyet üretmeye devam edebilir.

Kontrol edin:

• volume size
• volume type
• provisioned IOPS
• throughput
• snapshot
• unattached volume

Özellikle migration veya test sonrası kalan diskler görünmeyen maliyet oluşturabilir.

3. Data transfer maliyeti

AWS data transfer maliyeti yalnız internet egress değildir.

Şunlar ayrı maliyet oluşturabilir:

• internet data transfer out
• Availability Zone'lar arası trafik
• Region'lar arası trafik
• NAT Gateway
• load balancer
• CDN

Network yoğun mimarilerde toplam faturanın önemli kısmı data transfer'dan gelebilir.

Egress Maliyeti Nasıl Düşürülür? network maliyetlerini ayrı olarak ele alır.

4. NAT Gateway maliyeti neden önemlidir?

AWS NAT Gateway kullanımında saatlik ücret ve işlenen veri miktarı üzerinden ücret oluşabilir.

Bu yüzden yüksek hacimli private subnet trafiği NAT üzerinden geçiyorsa beklenenden yüksek maliyet oluşabilir.

Kontrol edin:

• hangi trafik NAT üzerinden geçiyor?
• AWS servislerine erişimde VPC endpoint kullanılabilir mi?
• cross-AZ NAT trafiği oluşuyor mu?

5. Public IPv4 maliyeti

Public IPv4 adresleri de AWS maliyet modelinin ayrı bir parçasıdır.

Bu nedenle kullanılmayan public IP'ler veya gereksiz public endpoint'ler ayrıca gözden geçirilmelidir.

6. Load Balancer maliyeti

Application Load Balancer, Network Load Balancer veya diğer load balancing servislerinde yalnız altyapının açık olması değil, kullanım seviyesi de maliyeti etkileyebilir.

Kontrol edin:

• kullanılmayan load balancer
• boş target group
• gereksiz duplicate environment
• test load balancer'ları

7. RDS ve managed database maliyeti

Database maliyeti genellikle:

• instance
• storage
• I/O
• backup
• HA / Multi-AZ
• read replica
• data transfer

kalemlerinden oluşabilir.

Bu nedenle yalnız EC2 fiyatını optimize etmek toplam faturayı yeterince düşürmeyebilir.

8. Monitoring ve logging maliyeti

CloudWatch gibi servislerde:

• metric sayısı
• log ingestion
• log retention
• alarm
• tracing

kullanımı maliyet oluşturabilir.

Production visibility önemlidir; ancak gereksiz debug log veya çok uzun retention maliyeti artırabilir.

9. Backup ve snapshot maliyeti

Backup kritik bir production gereksinimidir, ancak retention kontrol edilmezse maliyet büyüyebilir.

Kontrol edin:

• eski snapshot
• duplicate backup
• gereksiz uzun retention
• artık kullanılmayan workload backup'ları

Backup maliyeti düşürülürken recovery gereksinimi ve RPO/RTO korunmalıdır.

AWS Pricing Calculator nasıl kullanılmalı?

AWS Pricing Calculator yeni workload, migration veya mimari değişikliklerin maliyetini tahmin etmek için kullanılabilir.

Sağlıklı tahmin için şu girdiler net olmalıdır:

• Region
• işletim sistemi
• instance type
• çalışma süresi
• utilization
• EBS kapasitesi
• data transfer
• backup
• load balancer
• managed database
• support ihtiyacı

AWS'nin kendi dokümantasyonuna göre Pricing Calculator bir tahmin aracıdır; gerçek ücret kullanım davranışına bağlı olarak farklılaşabilir.

Pricing Calculator neden gerçek faturadan farklı çıkabilir?

Çünkü tahmin sırasında şu faktörler yanlış veya eksik modellenebilir:

• gerçek trafik
• egress
• spike
• storage büyümesi
• log hacmi
• request sayısı
• unused resource
• discount
• commitment

Bu nedenle calculator sonucu bütçe planlama için başlangıçtır, nihai fatura garantisi değildir.

On-Demand ne zaman mantıklıdır?

On-Demand model:

• yeni workload
• belirsiz kullanım
• kısa süreli ihtiyaç
• yüksek esneklik

gerektiren durumlarda uygundur.

Uzun süre stabil çalışan workload'larda daha farklı pricing modelleri değerlendirilebilir.

Savings Plans nasıl çalışır?

Savings Plans, belirli bir kullanım taahhüdü karşılığında On-Demand fiyatlarına göre indirim sağlayabilir.

AWS'nin güncel modelinde farklı Savings Plans türleri bulunur ve uygun plan workload tipine göre seçilmelidir.

Ancak commitment satın almadan önce:

1. idle kaynakları temizleyin
2. rightsizing yapın
3. stable baseline ölçün
4. sonra taahhüt değerlendirin

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

Reserved Instances ne zaman değerlendirilir?

Reserved Instances belirli EC2 kullanım senaryolarında fiyat avantajı sağlayabilir.

Karar verirken:

• instance family
• Region
• kullanım süresi
• flexibility ihtiyacı
• payment model

değerlendirilmelidir.

Spot Instances maliyet avantajı sağlar mı?

Evet, interruption toleransı olan workload'larda maliyet avantajı sağlayabilir.

Uygun örnekler:

• batch
• stateless worker
• CI runner
• distributed processing

Ancak kritik stateful workload için kesinti modeli ayrıca tasarlanmalıdır.

AWS faturası neden beklenenden yüksek gelir?

En sık nedenler:

• oversized EC2
• açık unutulan test ortamları
• unattached EBS
• snapshot birikimi
• yüksek NAT trafiği
• cross-AZ trafik
• data transfer out
• RDS tier büyümesi
• log ingestion
• gereksiz public IPv4
• yanlış commitment

Cloud Faturası Neden Beklenenden Yüksek Gelir? genel cloud maliyet triage'ını açıklar.

AWS maliyetini nasıl optimize edebilirsiniz?

Sağlıklı sıra:

1. Cost Explorer / billing görünürlüğü
2. resource ownership
3. idle resource cleanup
4. rightsizing
5. storage ve snapshot optimizasyonu
6. network / NAT / egress analizi
7. database optimizasyonu
8. commitment
9. recurring review

AWS maliyet optimizasyonunda FinOps

Tek seferlik cleanup yeterli değildir.

Yeni kaynaklar açıldıkça veya workload büyüdükçe maliyet yeniden artabilir.

Bu nedenle:

• tagging
• budget
• anomaly alert
• owner
• monthly review

kullanılmalıdır.

FinOps Nedir? bu operasyon modelini detaylandırır.

AWS maliyeti hesaplamak için örnek yaklaşım

Bir production web uygulaması için tahmin şu şekilde ayrıştırılabilir:

Compute

• 2 application EC2 instance

Storage

• EBS root + data volume

Database

• RDS instance + storage + backup

Network

• Load Balancer
• NAT Gateway
• internet egress

Observability

• CloudWatch logs ve metric

Backup

• snapshot / AWS Backup

Bu model tek bir EC2 fiyatına göre çok daha gerçekçi TCO verir.

AWS maliyetinde developer time da hesaba katılmalı mı?

Evet.

Altyapı ucuz görünse bile ekip düzenli olarak:

• patching
• backup
• incident
• network troubleshooting
• cost review

ile uğraşıyorsa toplam sahip olma maliyeti yükselir.

Bu nedenle gerçek toplam maliyet:

AWS faturası + lisans + operasyon zamanı + incident riski

olarak düşünülmelidir.

Dynamis AWS maliyet analizinde neye bakıyor?

Dynamis mevcut AWS hesabınız üzerinde ihtiyaca göre:

• EC2
• EBS
• RDS
• NAT
• data transfer
• load balancer
• CloudWatch
• backup
• idle resources
• rightsizing
• Savings Plans / commitment

alanlarını birlikte değerlendirir.

Başka platforma migration zorunlu değildir.

AWS yönetim hizmeti, mevcut AWS hesabının production operasyonu ve maliyet kontrolünü birlikte ele alır.

Sık yapılan hatalar

Yalnız EC2 saatlik fiyatına bakmak: Storage, network ve managed service maliyetlerini dahil edin.

Pricing Calculator sonucunu garanti sanmak: Gerçek kullanım tahminden farklı olabilir.

NAT ve egress'i unutmak: Network maliyetini ayrı modelleyin.

Rightsizing'den önce commitment almak: Fazla kapasiteyi uzun süreli taahhüde bağlamayın.

Backup ve logging'i sıfırlamak: Maliyet azaltırken operasyon riskini artırmayın.

Sonuç

AWS fiyatlandırması karmaşık görünmesinin nedeni tek bir fiyat yerine çok sayıda servis ve kullanım metriğinin birlikte faturaya yansımasıdır.

Doğru maliyet hesabı compute, storage, database, network, monitoring, backup ve commitment kalemlerini ayrı ayrı modelleyip gerçek kullanımla doğrulamayı gerektirir.

Sırada ne var

• AWS EC2 Nedir?
• Cloud Faturası Neden Beklenenden Yüksek Gelir?
• Savings Plan mı, Reserved Instance mı?
• Egress Maliyeti Nasıl Düşürülür?
• FinOps Nedir?
• AWS yönetim hizmeti

Kaynaklar

• AWS Pricing
• AWS Pricing Calculator documentation
• Generating Amazon EC2 estimates
• Pricing for NAT gateways
• What are Savings Plans?