AWS Cost Optimization: Savings Plan, Reserved, Spot 2026

AWS Cost Optimization: FinOps Disiplini Neden Üç Modelin Birlikte Çalışmasını Gerektirir

AWS cost optimization, modern bulut iş yüklerinde toplam sahip olma maliyetini sürdürülebilir biçimde düşürmek için Savings Plan, Reserved Instance (RI) ve Spot Instance modellerinin matematiksel olarak doğru oranlarda birleştirilmesi pratiğidir. Tek bir mekanizmaya bağlanan organizasyonlar genellikle iki sorundan birini yaşar: ya On-Demand maliyetini erken taahhütle kilitleyip esnekliği kaybeder, ya da Spot’un kesinti riskini kontrol edemediği için Tier-1 servisleri bile dalgalanan kapasiteye emanet eder. Doğru cevap, üç modeli iş yükünün karakterine göre katmanlamaktır: baz yük için 1-3 yıllık Compute Savings Plan, deterministik veritabanı/cache için Reserved Instance, stateless ve fault-tolerant katmanlar için Spot.

FinOps Foundation’ın 2024 State of FinOps raporu, 1300+ organizasyon arasında bulut maliyet optimizasyonunu öncelik #1 olarak işaretleyen kuruluş oranını %63 olarak ölçtü; aynı çalışmada Savings Plan/RI kapsamı (commitment coverage) %70 üzerinde olan firmalar, %30 altındaki gruba kıyasla EC2 birim maliyetini ortalama %38 daha düşük raporladı. AWS’in kendi belgeleri Compute Savings Plan’ın 1 yıllık no-upfront seçeneğinde %27, 3 yıllık all-upfront’ta %66’ya kadar indirim sunduğunu, Spot fiyatlarının ise On-Demand’a göre %70-90 aralığında değişen iskonto sağladığını yayınlıyor. Bu yazı, üç modeli karşılaştırmalı tablolarla inceleyip somut bir karar çerçevesi, EKS workload segmentasyonu, sözleşme matematiği ve organizasyon-içi FinOps operasyon modeli sunar.

EC2 Fiyatlama Modelleri: On-Demand, Savings Plan, Reserved ve Spot Arasındaki Yapısal Farklar

Dört birincil satın alma modeli, esneklik–taahhüt–iskonto üçgeninde farklı noktalara oturur. On-Demand saatlik faturalama ile maksimum esneklik sunar, fakat liste fiyatı en yüksek seviyededir. Reserved Instance belirli instance ailesi, bölge ve OS kombinasyonuna 1 veya 3 yıl bağlanır; Standard RI’da değişiklik dar, Convertible RI’da daha geniş bir manevra alanı vardır. Savings Plan ise para-saat cinsinden harcama taahhüdü sunar: Compute Savings Plan tüm EC2, Fargate ve Lambda kullanımını kapsar; EC2 Instance Savings Plan belirli bir aileye sabitlenir ve indirimi daha yüksektir. Spot Instance, AWS’in atıl kapasitesini açık artırma mantığıyla pazara açar; iki dakika önceden bildirimle geri alınabilir.

Model	İndirim (On-Demand’a göre)	Taahhüt	Esneklik	Kesinti Riski	İdeal Kullanım
On-Demand	%0 (baseline)	Yok	Tam esnek	Yok	Test, geçici workload, beklenmedik spike
Compute Savings Plan (1y, no-upfront)	%27 civarı	$/saat 1 yıl	Region, instance ailesi, OS değiştirilebilir	Yok	Baz yük, çoklu workload portföyü
Compute Savings Plan (3y, all-upfront)	%66’ya kadar	$/saat 3 yıl, ödeme önden	Geniş (Fargate, Lambda dahil)	Yok	Olgun, stabil platform
EC2 Instance Savings Plan (3y, all-upfront)	%72’ye kadar	$/saat + aile + region	Aile içi boyut değişimi	Yok	Tek aileye konsolide servisler
Standard Reserved Instance (3y)	%72’ye kadar	Aile + size + region + OS	Çok dar	Yok	RDS, Redshift, ElastiCache deterministik
Convertible RI (3y)	%54’e kadar	Aile değiştirilebilir	Orta	Yok	Mimari evrim beklenen kurumlar
Spot Instance	%70-90	Yok	Tam esnek	2 dk uyarıyla geri alınabilir	Batch, CI runner, stateless API, ML training

Bu tablonun pratik okuması şudur: %27’lik 1 yıllık taahhüt, finansal riskin neredeyse sıfır olduğu bir ön optimizasyondur ve hiçbir mühendislik değişikliği gerektirmez. %66-72 indirim seviyesi 3 yıllık sözleşmeyi gerektirir; bu noktada şirketin teknoloji yol haritasının en az 36 ay öngörülebilir olması beklenir. Spot’un %70-90 indirimi ise saf finansal değil, mimari bir kararı zorlar: workload’un kesintiyi tolere edecek şekilde tasarlanmış olması gerekir. AWS dokümantasyonu Spot Interruption oranlarının instance ailesine göre ayda %5 ila %20 arasında değiştiğini, m5/c5/r5 gibi yaygın ailelerde genellikle %5 altında kaldığını paylaşır.

1. On-Demand baz seviye: İndirim yok, taahhüt yok. Avantaj: Anlık esneklik. Dezavantaj: En yüksek birim maliyet. Ne zaman seç: Yeni deneysel workload, kısa POC.
2. 1 yıllık no-upfront Compute SP: %27 civarı tasarruf, sıfır önden ödeme. Avantaj: Düşük finansal risk. Dezavantaj: Maksimum indirim değil. Ne zaman seç: İlk FinOps adımı.
3. 3 yıllık all-upfront Compute SP: %66’ya kadar tasarruf, tüm ödeme önden. Avantaj: Maksimum indirim. Dezavantaj: Yüksek nakit bağlama. Ne zaman seç: Stabil platform + uygun sermaye.
4. Standard RI (3y) — RDS/ElastiCache: %50-72 tasarruf. Avantaj: Yönetilen DB için tek seçenek. Dezavantaj: Aile + boyut + region sabit. Ne zaman seç: Deterministik veritabanı kapasite planı.
5. Spot Instance: %70-90 tasarruf. Avantaj: En agresif indirim. Dezavantaj: 2 dk uyarıyla geri alınabilir. Ne zaman seç: Stateless, fault-tolerant, retry-able workload.

Compute Savings Plan vs EC2 Instance Savings Plan vs Reserved Instance: Hangi Senaryoya Hangisi

Üç taahhüt mekanizmasını birbiriyle karıştırmak, FinOps ekiplerinin en yaygın hatasıdır. Compute Savings Plan en geniş şemsiyedir ve Lambda ile Fargate’i de kapsadığı için containerized + serverless karması işletmelerin baz katmanı için varsayılan seçimdir. EC2 Instance Savings Plan, belirli bir ailenin (örneğin c6i veya m6g) baskın olduğu portföylerde 5-7 puan ekstra indirim sunar fakat region/aile kombinasyonu sabitlendiği için yanlış aileye taahhüt yıkıcıdır. Reserved Instance günümüzde büyük ölçüde RDS, Redshift, ElastiCache, OpenSearch gibi yönetilen veritabanı servisleri için anlam taşır; çünkü Savings Plan EC2 dışı bu servisleri kapsamaz.

Karar Boyutu	Compute SP	EC2 Instance SP	Standard RI	Convertible RI
Maksimum indirim (3y all-upfront)	%66	%72	%72	%54
Lambda kapsamı	Var	Yok	Yok	Yok
Fargate kapsamı	Var	Yok	Yok	Yok
RDS/ElastiCache kapsamı	Yok	Yok	Ayrı RI türü var	Ayrı RI türü var
Aile değişim hakkı	Sınırsız	Aile içinde	Yok	Var (1 kez)
İkincil pazar (Marketplace)	Yok	Yok	Satılabilir	Satılamaz
İdeal portföy	Heterojen, çok hesap	Tek aile baskın	Veritabanı, deterministik	Mimari değişen takım

Bu matristen çıkan pratik kural: baz EC2/Fargate/Lambda harcamasının %60-70’i için 1 veya 3 yıllık Compute Savings Plan al, RDS gibi yönetilen DB için ayrı RI satın al, geri kalan değişken yük için On-Demand + Spot kombinasyonuna geç. AWS Cost Explorer’ın Savings Plan Recommendations modülü son 7, 30 veya 60 günlük kullanımdan rolling forecast üretir; FinOps Foundation Practitioner Maturity modeli ise “Crawl” aşamasındaki organizasyonlara 7 günlük, “Walk” seviyesindekilere 30 günlük, “Run” olgunluğuna ulaşmış ekiplere 60 günlük pencerede karar vermesini önerir. Burada disiplin, taahhüt oranını %70’i geçirmemektir; aksi halde under-utilization (taahhüde rağmen kullanmama) gerçek bir maliyet kalemine dönüşür.

Spot Instance Mimarisi: Hangi Workload’ları Spot’a Almak Hem Güvenli Hem Karlı

Spot Instance’ın iskontosu cazip olmakla birlikte, yanlış workload’a uygulandığında SLA ihlali ve müşteri kaybı maliyeti yıllık indirimi anında siler. Spot için aday seçimi şu özelliklere dayanır: stateless tasarım, idempotent işlemler, checkpoint mekanizması, paralel scale-out kapasitesi, 2 dakikalık graceful shutdown’a tolerans. Bu kriterlere uyan workload tipleri arasında CI/CD runner havuzları, batch ETL, big data işleri (EMR, Glue), ML eğitimi (SageMaker Managed Spot Training), stateless API replica katmanları, video transkodlama ve fuzzing/security taraması ön plana çıkar.

• İdeal Spot Workload — CI/CD Runner Havuzu: GitHub Actions veya GitLab self-hosted runner’ları Spot üzerinde çalıştırmak %75-85 tasarruf sağlar. Avantaj: Job kesilse retry mekanizması zaten var. Dezavantaj: Build cache invalidation maliyeti. Ne zaman seç: Pipeline’ın retry policy’si tanımlanmışsa.
• İdeal Spot Workload — ML Training: SageMaker Managed Spot Training, checkpoint S3’e yazılırsa kesintide yarım kalan epoch’tan devam eder. Avantaj: Eğitim maliyeti %70-80 düşer. Dezavantaj: Total wall-time uzayabilir. Ne zaman seç: Deadline esnekse ve checkpoint cadansı 5-15 dk’ya ayarlanmışsa.
• Riskli Spot Workload — Stateful Kafka Broker: ISR replica kaybı, in-sync replica eşiğini düşürür. Avantaj: İndirim cazip. Dezavantaj: Topic re-balance fırtınası. Ne zaman seç: Sadece test/dev cluster.
• Yasak Spot Workload — Tek Replica Veritabanı: 2 dk uyarı, dump + failover için yetersiz. Dezavantaj: Veri kaybı ihtimali. Ne zaman seç: Asla production’da.

Spot’un riskini azaltmak için AWS’in Capacity Optimized allocation strategy’si, EC2 Auto Scaling Group veya EKS Karpenter ile birlikte kullanıldığında interruption’ı %50’ye kadar düşürür. Karpenter’ın spot-to-on-demand fallback modu, Spot kapasitesi kalmadığında otomatik olarak On-Demand’a geçer; bu hybrid pattern, batch işlerinin deadline’ı kaçırmasını engeller. AWS dokümantasyonuna göre çoklu instance type ve çoklu Availability Zone içeren ASG yapılandırması, tek instance type’a kıyasla interruption riskini ortalama 4 kat azaltır.

3 Yıllık Sözleşme Matematiği: TCO ve NPV Hesabıyla Karar

3 yıllık all-upfront Savings Plan’ın getirisi çekici görünür, fakat sözleşmenin nakit akışı ve esneklik maliyeti net bugünkü değer (NPV) ile değerlendirilmelidir. 1000 vCPU’luk c6i.large workload’un (saatlik On-Demand $0.085) 3 yıllık projeksiyonunu üç senaryo üzerinden karşılaştıralım. Hesaplar, AWS Pricing Calculator ve resmi indirim oranları kullanılarak yapılmıştır.

Senaryo	3 Yıl On-Demand	3y SP No-Upfront	3y SP Partial-Upfront	3y SP All-Upfront
Etkili saatlik birim	$0.085	$0.038	$0.035	$0.029
Yıllık maliyet (1000 vCPU)	$744,600	$332,880	$306,600	$254,040
3 yıl toplam	$2,233,800	$998,640	$919,800	$762,120
Önden ödeme	$0	$0	$459,900	$762,120
İndirim	%0	%55	%59	%66
Esneklik kaybı (qual.)	Yok	Düşük	Orta	Yüksek

3y all-upfront 3 yılda $1.47M tasarruf sağlar, fakat $762K’lık önden ödeme şirketin nakit akışını sıkıştırır. %8 ağırlıklı sermaye maliyeti (WACC) varsayımıyla yapılan NPV analizi, all-upfront’un partial-upfront’a kıyasla net faydasının yaklaşık $35K azaldığını gösterir; yani sermaye kıt ise partial-upfront genellikle daha sağlıklıdır. Aynı analiz, workload’un 24 ayda sonlanma ihtimali %30’u aşan ekipler için 3 yıllık taahhütten kaçınmayı önerir, çünkü Standard SP iptal edilemez ve Convertible RI’da bile kısmi iade yoktur. Reserved Instance Marketplace yalnızca Standard RI için ikincil satış imkanı sunar; Savings Plan satılamaz.

EKS Üzerinde Hybrid Strateji: Node Group Segmentasyonu ile Üçlü Model

Kubernetes platformunda üç satın alma modelini birleştirmenin en etkili yolu, node group seviyesinde segmentasyon ve workload-aware scheduling’tir. Amazon EKS, üç ayrı node group ile tasarlandığında üç maliyet modelini cerrahi olarak uygular: bir node group baz yük için Savings Plan kapsamında On-Demand instance’lar barındırır, ikincisi deterministik servisler için kapasiteyi sabitler, üçüncüsü Spot pool olarak batch ve burst yüklerini emer. Kubernetes Cost VPA HPA stratejileri ve Docker Kubernetes Yönetimi rehberi bu segmentasyonu detaylandırır.

Node Group	Satın Alma Modeli	Workload Tipi	Taint/Toleration	Hedef Doluluk	Tahmini İndirim
baseline-od	On-Demand + Compute SP	Tier-1 API, ingress, observability	workload=baseline	%75-85	%27-50
stateful-ri	RDS/ElastiCache RI (dış)	Veritabanı, cache (managed)	(EKS dışı)	%80+	%50-72
burst-spot	Spot (multi-instance)	Batch job, CI runner, async worker	spot=true:NoSchedule	%60-75	%70-85
ml-spot	Spot (GPU)	SageMaker eğitim, fine-tune	gpu=true,spot=true	%70-80	%75-90

Karpenter veya Cluster Autoscaler, Pod’un nodeAffinity ve tolerations spec’ine göre doğru node group’a yönlendirme yapar. Pod Disruption Budget (PDB) ile Spot node’larında çalışan Deployment’ların aynı anda kaç replica’sının kaybedilebileceği sınırlanır. Stateless API’ların replica sayısı, burst-spot node group’ta minimum 3 olacak şekilde tutulduğunda, AWS dokümantasyonuna göre tek bölgede aynı anda iki Spot interruption olasılığı %1’in altına iner. Cloud-Native Mimari prensipleri bu çoklu node group dizaynının olgun referansını sunar.

Otomasyon Katmanı: Cost Explorer, AWS Compute Optimizer ve Üçüncü Parti Araçlar

Manuel rightsizing ve commitment yönetimi 50 instance’ın üzerinde işletilemez hale gelir. AWS Cost Explorer’ın Savings Plan Recommendations modülü, son 7-60 günlük kullanımdan ML tabanlı öneri çıkarır; AWS Compute Optimizer ise instance ailesi bazında over-provisioning’i tespit eder ve right-size önerisi sunar. AWS’in CUR (Cost and Usage Report) Parquet formatında S3’e yazılır ve Athena ile sorgulanır; FinOps ekipleri için bu, kendi BI panelinizi (QuickSight, Grafana, Looker) kurmanın temelidir.

Araç	Sahibi	Birincil Yetenek	Ücretlendirme	Tipik Tasarruf Etkisi
AWS Cost Explorer	AWS	Maliyet görselleştirme, SP/RI öneri	API çağrısı $0.01	Baz katman
AWS Compute Optimizer	AWS	Rightsizing, EBS, Lambda öneri	Ücretsiz	%10-25
AWS Cost Anomaly Detection	AWS	ML tabanlı anomali alarmı	Ücretsiz	Erken uyarı
Vantage, CloudHealth, Anodot	Üçüncü parti	Multi-cloud showback, allocation	%2-5 spend	%15-30
OpenCost	CNCF açık kaynak	Kubernetes maliyet allocation	Self-host	K8s seviyesi şeffaflık
Karpenter	AWS açık kaynak	Bin-packing, Spot fallback	Ücretsiz	%20-40

Otomasyon kurulumunun en kritik aşaması tagging disiplinidir. Cost allocation tag’leri (Project, Environment, Team, CostCenter) olmadan hiçbir araç granüler showback üretemez. AWS Organizations seviyesinde tag policy zorlanır ve eksik tag’li kaynakların oluşturulması Service Control Policy ile engellenebilir. CNCF FinOps for Kubernetes Working Group’un 2024 değerlendirmesi, tagging disiplini olgun (%95+ kapsama) takımların maliyet anomali tespit süresini ortalama 14 günden 2 güne çekebildiğini raporlar. GitOps Kubernetes pattern’i, IaC içinde tag bildirimini zorunlu hale getirerek bu disiplini kalıcılaştırır.

• Zorunlu tag’ler: CostCenter, Project, Environment, Team, Owner. Hedef kapsama: %95+.
• Tag policy: AWS Organizations seviyesinde tanımla, SCP ile zorla. Avantaj: Yeni kaynaklarda eksik tag bloklanır.
• Showback frekansı: Haftalık team-bazlı rapor, aylık CostCenter rapor. Ne zaman seç: 50+ mühendis ekiplerinde zorunlu.
• Anomali alarmı: AWS Cost Anomaly Detection + Slack/Teams entegrasyon. Eşik: $100/gün veya %15 sapma.
• Otomatik rightsizing: Compute Optimizer önerilerini ticket’a dönüştür. SLA: 14 gün.

FinOps Organizasyon Modeli: Roller, RACI ve Aylık Ritüel

Teknik araçların etkili olabilmesi için organizasyonel çerçevenin oturmuş olması şarttır. FinOps Foundation’ın referans modeli, üç ana persona tanımlar: Engineer (mühendis), FinOps Practitioner (uygulamacı), Finance/Business (finans). Olgun bir FinOps takımı haftalık ve aylık ritüel uygular: haftalık trend incelemesi, aylık commitment optimizasyonu, çeyreklik mimari rightsizing. Ömer Önal’ın orta ölçekli SaaS müşterileri için yürüttüğü FinOps danışmanlığı projelerinde, ilk üç ayda ortalama %22 maliyet azaltımı, altıncı ayda %35 seviyesine ulaşan tasarruf gözlenmiştir.

• Engineer (Sahiplik): Workload tag’ler, autoscaling parametre seçimi, Spot uygunluk işaretlemesi. Sorumluluk: Mimari karar. Aylık ritüel: Tag kapsama oranı raporu.
• FinOps Practitioner (Koordinasyon): Commitment portföyü, Cost Explorer Recommendations’ı doğrulama, anomali takibi. Sorumluluk: Uçtan uca görünürlük. Aylık ritüel: SP/RI utilization raporu, under-utilization tahsis incelemesi.
• Finance/Business (Onay): 3y all-upfront onayı, bütçe-actual sapma analizi. Sorumluluk: Sermaye allokasyonu. Aylık ritüel: Showback/chargeback raporu, forecast revizyon.
• Platform Team (Otomasyon): Karpenter, OpenCost, Cost Anomaly Detection setup. Sorumluluk: Self-service maliyet görünürlüğü. Aylık ritüel: Dashboard SLA, alert noise tuning.

Bu rollerin RACI matrisinde net olması, “şu sözleşmeyi kim onaylayacak” sorusunun toplantıda 45 dakika dolaşmasını engeller. FinOps Bulut Maliyet rehberi, kurum içi RACI şablonlarını ve aylık FinOps reviews ajanda örneklerini içerir. Olgun bir FinOps takımı, mühendislere maliyeti utanç değil sahiplik konusu olarak sunar; aksi takdirde tag eksiklikleri ve over-provisioning silinmesi gereken bir günah listesi olarak görülür.

Benchmark Karşılaştırması: Compute Optimizer Önerileri ile Gerçekleştirilen Tasarruflar

AWS Compute Optimizer’ın önerilerini izleyen organizasyonların gerçek tasarrufu, raporlanan tahmine ne kadar yakın? Üç farklı sektör için aşağıdaki benchmark, AWS’in 2024 re:Invent oturumlarında yayınladığı vaka çalışmaları ve FinOps Foundation üye anketlerinden derlenmiştir. Rakamlar yaklaşıktır; gerçek değerler iş yükü desenine göre değişir.

Sektör	Aylık AWS Harcama	Compute Optimizer Önerisi	Gerçekleşen Tasarruf	Uygulama Süresi	SP/RI Coverage
SaaS B2B	~$180,000	%18 rightsizing + %15 SP	%28	3 ay	%72
E-ticaret platformu	~$450,000	%12 rightsizing + %22 SP/RI	%31	4 ay	%78
Medya/streaming	~$900,000	%25 Spot + %18 SP	%39	5 ay	%65
ML/AI startup	~$220,000	%30 Spot training + %12 SP	%41	3 ay	%55
FinTech ödeme	~$320,000	%10 rightsizing + %20 RI	%25	4 ay	%82

Bu vaka çalışmalarının ortak çıkarımı: tasarruf büyüklüğü tek başına Spot oranıyla değil, Spot + Savings Plan + rightsizing üçlüsünün dengesiyle belirleniyor. ML/AI startup’ının %41’lik tasarrufunda Spot’un payı baskınken, FinTech ödeme şirketinin %25’inde RI dominant; çünkü ödeme platformu PCI-DSS gereği deterministik kapasite tutmak zorunda ve Spot riskini alamıyor. Bulut maliyet kararları regülasyon ve iş yükü karakteristiğinden bağımsız değerlendirilemez. Serverless AWS Lambda tarafına geçişin maliyete etkisi de Compute Savings Plan kapsamında değerlendirilmelidir.

Sık Sorulan Sorular

Sonuç: Üç Modelin Disiplinli Birleşimi Sürdürülebilir Maliyet Yapısı Yaratır

AWS cost optimization, tek bir indirim mekanizmasına bağlanmak yerine üç modeli iş yükünün karakterine göre katmanlama disiplinidir. Baz yükün %60-70’ini Compute Savings Plan ile kapsayıp finansal riski sıfıra yakın bir noktada %27-66 indirim elde edersiniz; deterministik veritabanı katmanı için Reserved Instance ekleyerek RDS, ElastiCache ve Redshift maliyetini %50-72 düşürürsünüz; geri kalan değişken kapasiteyi Spot ile besleyerek batch, CI runner ve ML training maliyetini %70-90 azaltırsınız. Bu üçlü, doğru tagging ve Karpenter gibi otomasyon araçlarıyla birleştiğinde toplam EC2 birim maliyetini %35-45 düşürür.

Karar çerçevesi şöyle özetlenebilir: önce mimari sahiplik kurulur (tagging, autoscaling, IaC), sonra rightsizing ile over-provisioning temizlenir, ardından commitment portföyü inşa edilir, son olarak Spot mimarisi devreye alınır. Bu sıranın bozulması — örneğin tagging olmadan SP satın almak veya Spot’a baz yük taşımak — yıllık tasarruf hedefini negatife çevirebilir. FinOps olgunluğu üç ayda anlamlı, altı ayda dramatik etki üretir; doğru organizasyon modeli ise bu kazancı sürdürülebilir hale getirir. Sürecinizin neresinde olduğunuzdan emin değilseniz iletişim sayfası üzerinden bir FinOps değerlendirme görüşmesi talep edebilirsiniz; AWS hesabınız üzerinde 1 saatlik bir incelemeyle hangi modelin önce konuşulması gerektiği netleşir.

Bu yazıda paylaşılan benchmark’ların ve indirim oranlarının kaynakları arasında AWS Savings Plans User Guide, AWS EC2 Spot Instance Documentation, AWS Compute Optimizer Documentation, FinOps Foundation Framework, CNCF OpenCost Project, Karpenter Documentation ve AWS Cost Management Blog bulunmaktadır. Kaynaklar yıllık güncellenir; indirim oranlarını satın alma öncesi resmi sayfalardan doğrulayın.