Savings Plan mı, Reserved Instance mı? AWS Taahhüt Kararı Nasıl Verilir?

Kısaca

AWS üzerinde düzenli çalışan bir workload için temel soru yalnız "Savings Plan mı, Reserved Instance mı daha ucuz?" değildir. Doğru karar; workload'un ne kadar stabil olduğu, instance family veya Region değişikliği ihtimali, Fargate/Lambda kullanımı, kapasite garantisi gereksinimi ve taahhüt süresi birlikte değerlendirilerek verilmelidir.

Dynamis Teknoloji'de bu kararı yalnız indirim yüzdesi üzerinden değil, coverage, utilization, mimari esneklik ve break-even riski üzerinden ele alıyoruz.

Özet olarak:

• Compute Savings Plans en geniş esnekliği sağlar.
• EC2 Instance Savings Plans belirli bir Region ve instance family içinde daha sıkı kapsamla daha yüksek indirim potansiyeli sunar.
• Reserved Instances belirli EC2 kullanım modellerinde hâlâ anlamlı olabilir; regional ve zonal scope farklı davranır.
• Zonal Reserved Instance kapasite rezervasyonu sağlayabilir.
• Savings Plans kapasite rezervasyonu sağlamaz; gerekiyorsa Capacity Reservation ayrı kullanılır.

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

AWS Savings Plans, belirli bir süre boyunca belirli bir USD/saat kullanım taahhüdü karşılığında indirimli fiyat uygular.

Compute ve EC2 Instance Savings Plans için yaygın taahhüt süreleri:

• 1 yıl
• 3 yıl

Ödeme seçenekleri:

• No Upfront
• Partial Upfront
• All Upfront

AWS, taahhüt kapsamına giren kullanımı indirimli Savings Plans rate ile, taahhüdü aşan uygun kullanımı ise On-Demand rate ile ücretlendirir.

Buradaki kritik nokta şudur:

Savings Plan bir instance satın alma işlemi değildir; saatlik kullanım taahhüdüdür.

Compute Savings Plans nedir?

Compute Savings Plans, AWS'nin compute tarafında en esnek Savings Plans modelidir.

AWS dokümantasyonuna göre Compute Savings Plans:

• EC2 instance family değişse bile uygulanabilir,
• instance size değişse bile uygulanabilir,
• Region değişse bile uygulanabilir,
• işletim sistemi değişse bile uygulanabilir,
• tenancy değişse bile uygulanabilir,
• uygun Fargate kullanımına uygulanabilir,
• uygun Lambda kullanımına uygulanabilir.

AWS, Compute Savings Plans için On-Demand fiyatlarına göre %66'ya varan indirim potansiyeli belirtir. Bu oran belirli bir workload için garanti değildir; gerçek avantaj Region, instance, OS, ödeme ve kullanım yapısına bağlıdır.

Compute Savings Plans ne zaman güçlü adaydır?

Şu durumlarda daha anlamlı olabilir:

• instance family değişebiliyorsa,
• workload farklı Region'lara taşınabiliyorsa,
• EC2'den Fargate veya Lambda'ya geçiş olasılığı varsa,
• şirket hızlı büyüyor veya mimari sık değişiyorsa,
• uzun taahhüt boyunca belirli tek instance family'ye kilitlenmek istemiyorsanız.

Esneklik burada önemli bir FinOps değeridir: en yüksek indirim yüzdesini değil, kullanılabilir indirimi optimize edersiniz.

EC2 Instance Savings Plans nedir?

EC2 Instance Savings Plans belirli bir AWS Region + EC2 instance family kombinasyonuna bağlıdır.

Örneğin:

m7i + eu-central-1

gibi.

Aynı family ve Region içinde:

• instance size,
• operating system,
• tenancy

değişikliklerinde plan uygulanabilir.

AWS, EC2 Instance Savings Plans için On-Demand'e göre %72'ye varan indirim potansiyeli belirtir.

EC2 Instance Savings Plans ne zaman güçlü adaydır?

• workload uzun süre aynı Region'da kalacaksa,
• instance family'nin değişme ihtimali düşükse,
• Fargate/Lambda kapsamı gerekmiyorsa,
• kullanım baseline'ı stabilse,
• daha düşük esneklik karşılığında daha yüksek indirim potansiyeli kabul ediliyorsa.

Reserved Instance nedir?

EC2 Reserved Instance, belirli EC2 kullanım özelliklerine göre satın alınan indirim modelidir.

Reserved Instance iki temel offering class'a ayrılır:

• Standard RI
• Convertible RI

Standard RI genellikle daha yüksek indirim potansiyeli sunar fakat başka bir RI configuration'ına exchange edilemez. Convertible RI, şartları dahilinde başka Convertible RI configuration'larıyla exchange edilebilir.

Reserved Instance aynı zamanda scope açısından ikiye ayrılır:

• Regional RI
• Zonal RI

Bu ayrım kapasite davranışı açısından önemlidir.

Regional RI ile Zonal RI arasındaki fark nedir?

Regional Reserved Instance:

• belirli Region scope'undadır,
• o Region içindeki uygun EC2 kullanımına indirim sağlayabilir,
• kapasite rezervasyonu sağlamaz.

Zonal Reserved Instance:

• belirli Availability Zone'a bağlıdır,
• indirim yanında o Availability Zone için kapasite rezervasyonu sağlar.

Bu nedenle kapasite gereksinimi olan production sistemlerinde Reserved Instance kararı yalnız fiyat indirimi değil, capacity planning kararı da olabilir.

Savings Plan ile Reserved Instance arasındaki temel fark

Tablo kararın tamamını vermez; gerçek hesap kullanım verisiyle yapılmalıdır.

Savings Plans kapasite rezervasyonu sağlar mı?

Hayır.

AWS dokümantasyonunda Savings Plans'in fiyat indirimi sağladığı, ancak EC2 kapasitesi rezerve etmediği açıkça belirtilir.

Eğer belirli Availability Zone'da kapasite garantisi gerekiyorsa:

• On-Demand Capacity Reservation

ayrı kullanılabilir.

Uygun Savings Plans veya Regional RI indirimi bu kapasite kullanımıyla birlikte uygulanabilir.

Bu ayrım özellikle kritik production workload'larında önemlidir.

Taahhüt kararında hangi veriye bakılmalı?

Taahhüt satın almadan önce minimum şu veri setini çıkarın:

• son 30-60 günlük compute kullanımı,
• saatlik baseline,
• peak kullanım,
• instance family dağılımı,
• Region dağılımı,
• OS/tenancy dağılımı,
• Fargate/Lambda payı,
• mevcut Savings Plans coverage,
• mevcut RI coverage,
• utilization,
• önümüzdeki 12-36 aylık mimari plan.

AWS Savings Plans Purchase Analyzer son 60 güne kadar lookback kullanarak farklı commitment senaryolarını analiz etmeye yardımcı olabilir.

Coverage ile utilization aynı şey değildir

Bu iki kavram karıştırılır.

Coverage

Toplam uygun kullanımın ne kadarının indirimli taahhütle kapsandığını gösterir.

Utilization

Satın aldığınız taahhüdün ne kadarının gerçekten kullanıldığını gösterir.

Örneğin:

• coverage düşük olabilir → fazla On-Demand harcama vardır,
• utilization düşük olabilir → fazla commitment satın alınmıştır.

İyi FinOps hedefi yalnız coverage'ı artırmak değildir.

Coverage yükselirken utilization düşüyorsa maliyet optimizasyonu bozulabilir.

Baseline nasıl hesaplanmalı?

Taahhüt peak usage'a göre değil, sürekli tekrarlayan tabana göre boyutlandırılmalıdır.

Örnek:

• gece minimum 4 instance,
• gündüz ortalama 8 instance,
• campaign döneminde 20 instance

kullanıyorsanız 20 instance seviyesinde commitment vermek büyük ihtimalle gereksiz risk oluşturur.

İlk taahhüt için en güvenli başlangıç genellikle düzenli kullanılan tabanın tamamı veya kontrollü bir yüzdesidir.

Break-even mantığı

Taahhüdün ekonomik olması için kullanılmayan commitment maliyetinin indirim avantajını yememesi gerekir.

Basit düşünce:

Gerçek tasarruf = On-Demand karşılığı - commitment toplam maliyeti

Ancak bu hesapta:

• idle commitment,
• workload küçülmesi,
• Region değişimi,
• instance family değişimi,
• platform modernizasyonu

riskleri de değerlendirilmelidir.

En yüksek indirim oranı, kullanım değişirse en düşük gerçek tasarrufa dönüşebilir.

1 yıllık mı 3 yıllık mı?

3 yıllık taahhütler daha yüksek indirim potansiyeli sunabilir.

Fakat süre uzadıkça şu riskler artar:

• workload kapanabilir,
• ürün küçülebilir,
• instance family değişebilir,
• Region değişebilir,
• managed service'e geçilebilir,
• Fargate veya Lambda payı artabilir,
• şirket sağlayıcı değiştirebilir.

Bu nedenle süre seçerken:

1. workload ömrü,
2. revenue visibility,
3. mimari yol haritası,
4. kullanım stabilitesi

birlikte değerlendirilmelidir.

Compute Savings Plans ne zaman daha güvenli olabilir?

Özellikle şu senaryolarda:

• startup hızlı değişiyorsa,
• instance aileleri düzenli güncelleniyorsa,
• farklı Region'lar kullanılıyorsa,
• EC2 + Fargate + Lambda karışımı varsa,
• architecture roadmap belirsizse.

Buradaki fayda yalnız discount flexibility değildir.

Operational change cost da azalır; commitment yapısını değiştirmek için sürekli manuel RI exchange/modification ihtiyacı daha az olabilir.

EC2 Instance Savings Plans ne zaman daha mantıklı olabilir?

Örneğin:

• uzun süre aynı Region'da çalışan,
• aynı instance family'yi kullanan,
• 7/24 açık production VM'leri bulunan,
• compute pattern'i tahmin edilebilir

bir SaaS workload'u.

Bu durumda daha sıkı scope, daha yüksek indirim potansiyeliyle dengelenebilir.

Reserved Instance ne zaman hâlâ değerlendirilmeli?

Reserved Instance şu durumlarda özellikle değerlendirilebilir:

• belirli EC2 configuration'ı uzun süre sabitse,
• mevcut RI portföyü zaten varsa,
• RI Marketplace senaryosu anlamlıysa,
• capacity reservation benefit gerekiyorsa,
• Zonal RI ile capacity + discount birlikte isteniyorsa.

Ancak yeni commitment kararlarında Savings Plans ile RI mutlaka yan yana modellenmelidir.

Standard RI mı Convertible RI mı?

Standard RI:

• daha yüksek indirim potansiyeli,
• daha düşük esneklik,
• exchange yok.

Convertible RI:

• belirli koşullarda exchange edilebilir,
• instance family/type/platform/scope/tenancy değişikliklerinde daha fazla esneklik sağlar,
• ancak Region değiştirilemez.

Buradaki trade-off yine aynıdır:

discount vs flexibility.

Migration planı varsa neden taahhüt riski artar?

AWS'den çıkış, hybrid cloud veya farklı provider planı varsa uzun commitment dikkatli verilmelidir.

Örneğin bir workload 9 ay içinde başka platforma taşınacaksa 3 yıllık commitment nominal olarak ucuz görünse bile toplam ekonomik sonuç kötü olabilir.

AWS'den çıkış: maliyeti düşüren bulut göçü planı bu kararı migration açısından ayrıca ele alır.

AWS'de kalacak workload ile taşınacak workload'u ayırın

Her workload için üç karar verilebilir:

• kal
• optimize et
• taşı

Commitment yalnız kalacağı yüksek güvenle bilinen baseline üzerine verilmelidir.

AWS alternatifi: hangi iş yükü nerede kalmalı? workload placement kararını ayrı olarak ele alır.

Örnek karar senaryoları

Senaryo 1 — Sabit EC2 workload

• Region sabit
• m7i family sabit
• 24/7 kullanım
• 3 yıllık ürün ömrü yüksek güvenli

EC2 Instance Savings Plans veya RI güçlü aday olabilir.

Senaryo 2 — Hızlı değişen SaaS

• EC2 family değişiyor
• bazı servisler Fargate'e geçiyor
• ikinci Region planlanıyor

Compute Savings Plans daha geniş esneklik sağlayabilir.

Senaryo 3 — Kritik kapasite ihtiyacı

• belirli AZ'de kapasite garanti edilmeli

Savings Plan tek başına yeterli değildir. Capacity Reservation veya uygun Zonal RI modeli ayrıca değerlendirilmelidir.

Senaryo 4 — AWS'den kademeli çıkış

• önümüzdeki 12 ayda workload'ların bir kısmı taşınacak

Uzun commitment yerine daha düşük ve güvenli baseline veya hiç yeni commitment vermemek daha doğru olabilir.

Taahhüt satın alma sırası

Sağlıklı süreç şu sırada ilerler:

1. AWS faturalarını normalize edin.
2. Idle ve oversized resource'ları temizleyin.
3. Rightsizing yapın.
4. Workload placement kararını verin.
5. Stable baseline'ı ölçün.
6. Existing RI/SP coverage ve utilization'ı çıkarın.
7. Compute SP / EC2 SP / RI senaryolarını modelleyin.
8. Purchase Analyzer ile senaryoyu kontrol edin.
9. Küçük commitment ile başlayın.
10. Aylık utilization ve coverage review yapın.

En sık yapılan hata, rightsizing'den önce commitment satın almaktır.

Dynamis'te FinOps yaklaşımı

Dynamis'in FinOps hizmetinde AWS taahhütlerini yalnız satın alma önerisi olarak ele almıyoruz.

Önce:

• resource ownership,
• idle kaynaklar,
• rightsizing,
• egress,
• storage waste,
• workload placement

incelenir.

Ardından commitment kararı verilir.

Çünkü optimize edilmemiş bir workload'a Savings Plan almak, verimsizliği daha ucuz hale getirir; verimsizliği ortadan kaldırmaz.

Taahhüt kararının yanında AWS mimarisi, monitoring, backup, incident ve sürekli operasyon da dışarıdan yönetilecekse AWS yönetim hizmeti ana commercial destination olarak kullanılmalıdır.

Sık yapılan hatalar

Peak kullanıma commitment vermek: Baseline üzerinden başlayın.

%72 indirim gördüm, EC2 Instance SP seçeyim demek: Family ve Region lock-in riskini modelleyin.

Savings Plan kapasiteyi rezerve eder sanmak: Etmez; capacity ayrı konudur.

Rightsizing'den önce commitment almak: Fazla kaynak kullanımını uzun süreli taahhüde bağlayabilirsiniz.

Migration planını hesaba katmamak: Taşınacak workload'a uzun commitment vermeyin.

Coverage'ı tek KPI yapmak: Utilization düşükse tasarruf zarar görebilir.

3 yıllık planı yalnız indirim oranıyla seçmek: Workload ömrü ve mimari değişim riskini değerlendirin.

Sırada ne var

• AWS'den çıkış: maliyeti düşüren bulut göçü planı
• AWS alternatifi: hangi iş yükü nerede kalmalı?
• FinOps hizmeti
• AWS yönetim hizmeti

Kaynaklar

• AWS Savings Plans types
• AWS Compute and EC2 Instance Savings Plans pricing
• AWS Compute Savings Plans and Reserved Instances
• AWS Savings Plans Purchase Analyzer
• AWS Regional and zonal Reserved Instances
• AWS Reserved Instance types
• AWS EC2 Capacity Reservations