Zniżki w AWS bez ryzyka lock-in - Savings Plans vs Reserved Instances
Rachunek za AWS rośnie z miesiąca na miesiąc. W pewnym momencie ktoś w zespole pyta: „Czy nie powinniśmy kupić Reserved Instances?”. To jest właściwy moment, żeby zatrzymać się i przemyśleć, co dokładnie kupujesz i jakie zobowiązanie na siebie bierzesz.
Problem polega na tym, że AWS ma dzisiaj dwa mechanizmy zniżek za zobowiązanie, które pokrywają się zakresem, ale różnią się elastycznością. Zły wybór oznacza albo utratę pieniędzy (zobowiązanie na infrastrukturę, której za rok nie będziesz potrzebować), albo niedostateczne oszczędności (zbyt ostrożne podejście, gdy dane mówią jasno).
Jak działają Reserved Instances
Reserved Instances to starszy z dwóch mechanizmów. Istnieją od 2009 roku i przez lata były jedynym sposobem na zniżki w AWS.
Zasada działania
Kupujesz zobowiązanie na konkretną konfigurację:
- Typ instancji (np. m5.xlarge)
- Region (np. eu-central-1)
- Okres (1 rok lub 3 lata)
- Opcja płatności (All Upfront, Partial Upfront, No Upfront)
W zamian otrzymujesz zniżkę od 30% (1 rok, No Upfront) do 72% (3 lata, All Upfront) w porównaniu do ceny on-demand.
Typy Reserved Instances
| Typ RI | Elastyczność | Zniżka (1Y / 3Y) | Zastosowanie |
|---|---|---|---|
| Standard RI | Brak - dokładny typ instancji + region | ~40% / ~60% | Stabilna produkcja, znana konfiguracja |
| Convertible RI | Można zmienić typ instancji (wymiana) | ~33% / ~54% | Gdy przewidujesz zmianę generacji (np. m5 → m6i) |
Ważna cecha: Size Flexibility
Standard RI w ramach tej samej rodziny instancji (np. m5) automatycznie rozkłada się na różne rozmiary. Jedno RI na m5.2xlarge pokrywa:
- 2× m5.xlarge
- 4× m5.large
- 8× m5.medium
To jest normalizacja przez współczynnik rozmiaru. Działa automatycznie w ramach tego samego regionu i family.
Gdzie RI nadal mają sens
- RDS Reserved Instances - Savings Plans nie pokrywają RDS. Jeśli masz stabilne bazy danych, RI jest jedynym sposobem na zniżkę.
- ElastiCache Reserved Nodes - analogicznie, brak pokrycia przez Savings Plans.
- OpenSearch Reserved Instances - to samo.
- Redshift Reserved Nodes - jedyna opcja zniżki.
Dla tych usług nie ma alternatywy. RI to jedyny mechanizm.
Jak działają Savings Plans
Savings Plans (wprowadzone w 2019 roku) to nowszy mechanizm. Zamiast zobowiązania na konkretną instancję, zobowiązujesz się do minimalnego poziomu wydatków na godzinę (wyrażonego w USD/h).
Zasada działania
Deklarujesz: „Przez następne 1 (lub 3) lata będę wydawać minimum X USD na godzinę na compute”. Wszystko do tego poziomu jest rozliczane ze zniżką. Wszystko powyżej - po cenie on-demand.
Typy Savings Plans
| Typ SP | Zakres | Elastyczność | Zniżka (1Y / 3Y, All Upfront) |
|---|---|---|---|
| Compute Savings Plans | EC2, Fargate, Lambda | Dowolna rodzina, rozmiar, region, OS, tenancy | ~33% / ~54% |
| EC2 Instance Savings Plans | Tylko EC2 | Dowolny rozmiar w ramach rodziny + regionu | ~40% / ~60% |
| SageMaker Savings Plans | Tylko SageMaker | Dowolny typ instancji SageMaker | ~20% / ~64% |
Kluczowa różnica: Compute SP vs EC2 Instance SP
Compute Savings Plans to najbardziej elastyczna opcja:
- Zmieniasz region? Zniżka nadal działa.
- Przenosisz workload z EC2 na Fargate? Zniżka nadal działa.
- Migrujesz z m5.xlarge na m6i.2xlarge? Zniżka nadal działa.
- Przenosisz część obliczeń na Lambda? Zniżka nadal działa.
EC2 Instance Savings Plans dają wyższą zniżkę, ale wiążą Cię z rodziną instancji i regionem. Jeśli jesteś pewny, że przez rok nie zmienisz ani regionu, ani rodziny, to lepsza opcja.
Porównanie: Savings Plans vs Reserved Instances
| Wymiar | Reserved Instances (Standard) | Compute Savings Plans | EC2 Instance SP |
|---|---|---|---|
| Zniżka (3Y All Upfront) | ~60-72% | ~54% | ~60% |
| Lock-in: region | Tak | Nie | Tak |
| Lock-in: rodzina instancji | Tak | Nie | Tak |
| Lock-in: rozmiar | Nie (Size Flex) | Nie | Nie |
| Pokrywa Fargate | Nie | Tak | Nie |
| Pokrywa Lambda | Nie | Tak | Nie |
| Pokrywa RDS | Tak (osobne RDS RI) | Nie | Nie |
| Marketplace (odsprzedaż) | Tak (Standard RI) | Nie | Nie |
| Zmiana w trakcie okresu | Convertible: tak, Standard: nie | Nie (ale nie trzeba) | Nie (ale nie trzeba) |
Kalkulacja na realnym przykładzie
Scenariusz: polska firma SaaS, infrastruktura w eu-central-1
Stała infrastruktura produkcyjna:
- 3× m6i.xlarge (EC2, aplikacja) = 3 × $0.192/h = $0.576/h
- 2× r6i.large (EC2, cache warstwy) = 2 × $0.126/h = $0.252/h
- 1× db.r6g.xlarge (RDS PostgreSQL) = $0.348/h
- Fargate tasks (średnie zużycie) = ~$0.15/h
Łączne on-demand: ~$1.326/h = ~$968/miesiąc = ~$11,610/rok
Opcja A: Tylko Reserved Instances
- EC2 RI (1Y, All Upfront) na m6i.xlarge × 3 i r6i.large × 2: zniżka ~40%
- RDS RI (1Y, All Upfront) na db.r6g.xlarge: zniżka ~40%
- Fargate: brak zniżki (RI nie pokrywa Fargate)
Oszczędności na EC2 + RDS: ~$4,200/rok Koszt po zniżce: ~$7,410/rok
Opcja B: Compute Savings Plans + RDS RI
- Compute SP na $0.978/h (pokrywa EC2 + Fargate): zniżka ~33% (1Y)
- RDS RI na db.r6g.xlarge: zniżka ~40%
Oszczędności na compute: ~$2,830/rok (niższy % ale pokrywa Fargate) Oszczędności na RDS: ~$1,220/rok Łączne oszczędności: ~$4,050/rok Koszt po zniżce: ~$7,560/rok
Opcja C: EC2 Instance SP + RDS RI (rekomendacja)
- EC2 Instance SP na $0.828/h (pokrywa EC2, rodzina m6i + r6i, eu-central-1): zniżka ~40%
- Compute SP na $0.15/h (pokrywa Fargate osobno): zniżka ~33%
- RDS RI na db.r6g.xlarge: zniżka ~40%
Łączne oszczędności: ~$4,400/rok Koszt po zniżce: ~$7,210/rok
Różnica między opcjami to ~$350/rok. Przy budżecie ~$12k/rok to mniej niż 3%. Elastyczność jest ważniejsza niż kilka procent dodatkowej zniżki.
Strategia zakupu - podejście warstwowe
Nie kupuj zobowiązań na 100% infrastruktury. Optymalne podejście to pokrycie 60-80% stabilnego baseline i pozostawienie 20-40% na on-demand (elastyczność na peak load, eksperymenty, zmiany).
Krok 1: Zidentyfikuj baseline
W AWS Cost Explorer przejdź do Savings Plans > Recommendations. AWS analizuje ostatnie 7/30/60 dni i sugeruje optymalny poziom zobowiązania.
Alternatywnie, w Cost Explorer ustaw granulację „Hourly” i znajdź minimalny poziom wydatków, który utrzymuje się stabilnie przez ostatnie 30 dni. To jest Twój bezpieczny baseline.
Krok 2: Wybierz warstwę zobowiązań
| Warstwa | Mechanizm | Pokrycie | Cel |
|---|---|---|---|
| 1 (stabilna) | EC2 Instance SP (3Y) | 40-50% baseline | Maksymalna zniżka na pewną infrastrukturę |
| 2 (elastyczna) | Compute SP (1Y) | 20-30% baseline | Pokrycie Fargate/Lambda + bufor na zmiany |
| 3 (bazy danych) | RDS / ElastiCache RI | Bazy prod 24/7 | Jedyna opcja zniżki na managed DB |
| 4 (on-demand) | Brak zobowiązania | 20-40% peak | Elastyczność, autoscaling, dev/test |
Krok 3: Kiedy 1 rok, kiedy 3 lata?
3 lata (wyższa zniżka, wyższe ryzyko):
- Bazy danych produkcyjne (rzadko się zmienia silnik/rozmiar)
- Core infrastruktura, która istnieje od >12 miesięcy bez istotnych zmian
- Firma nie planuje migracji na inną chmurę ani zmiany architektury w ciągu 3 lat
1 rok (niższa zniżka, minimalne ryzyko):
- Infrastruktura, która rośnie szybko (startup w fazie wzrostu)
- Planujesz zmianę architektury w ciągu 12-18 miesięcy
- Nie masz pewności co do przyszłych potrzeb
Zasada: jeśli wahasz się między 1Y a 3Y, wybierz 1Y. Koszt błędu przy 3Y jest trzy razy wyższy.
Pułapki i błędy
1. Kupowanie zobowiązań na dev/test
Środowiska deweloperskie powinny być wyłączane poza godzinami pracy. Jeśli dev działa 10h/dzień × 5 dni/tydzień (30% czasu), to zobowiązanie 24/7 marnuje 70% zniżki.
Lepsze podejście: Instance Scheduler (automatyczne wyłączanie) + on-demand lub Spot Instances.
2. Ignorowanie Spot Instances
Zanim kupisz zobowiązanie, sprawdź czy workload nie może działać na Spot. Spot daje 60-90% zniżki bez żadnego zobowiązania. Dla batch processing, CI/CD, ML training - Spot jest tańszy niż 3-letnie RI.
3. Zobowiązanie na starej generacji instancji
AWS regularnie wprowadza nowe generacje (m5 → m6i → m7i). Nowa generacja daje lepszą wydajność za niższą cenę. Jeśli kupujesz 3-letnie RI na m5, blokujesz się na starszą generację.
Rozwiązanie: Compute Savings Plans, które automatycznie obejmują nowe generacje.
4. Brak monitoringu wykorzystania
Po zakupie RI/SP sprawdzaj regularnie:
- Savings Plans Utilization Report - jaki procent zobowiązania jest faktycznie wykorzystywany?
- Savings Plans Coverage Report - jaki procent wydatków jest pokryty zniżkami?
- RI Utilization - czy wszystkie RI są aktywnie używane?
Cel: utilization >90%. Jeśli spada poniżej 80%, masz za dużo zobowiązań.
5. All Upfront bez potrzeby
Płatność z góry (All Upfront) daje dodatkowe 5-8% zniżki. Ale zamraża gotówkę. Dla startupu z ograniczoną płynnością, No Upfront (nieco niższa zniżka, ale zero zamrożonego kapitału) jest często lepszym wyborem.
Kalkulacja: 3Y All Upfront na $1/h = ~$15,000 z góry. Przy No Upfront płacisz $0.95/h (5% drożej), ale nie zamrażasz $15k.
Kiedy Savings Plans, kiedy RI - matryca decyzyjna
| Sytuacja | Rekomendacja | Uzasadnienie |
|---|---|---|
| EC2 + Fargate + Lambda (mix) | Compute Savings Plans | Pokrywa wszystko jednym zobowiązaniem |
| Tylko EC2, stabilna rodzina i region | EC2 Instance SP | Wyższa zniżka niż Compute SP |
| RDS, ElastiCache, OpenSearch, Redshift | Reserved Instances | SP nie pokrywa tych usług |
| Dynamiczna infrastruktura (częste zmiany) | Compute SP (1Y, No Upfront) | Minimalne ryzyko, elastyczność na zmiany |
| Startup w fazie wzrostu (>50% YoY) | Krótkie SP (1Y) na 40-50% baseline | Baseline rośnie, nie chcesz się blokować |
| Stabilna firma (wzrost <10% YoY) | Mix 3Y SP (60%) + 1Y SP (20%) | Maksymalne oszczędności przy niskim ryzyku |
| Migracja planowana w ciągu 2 lat | Tylko 1Y SP lub brak zobowiązań | Nie blokuj się przed migracją |
AWS Cost Explorer - jak korzystać z rekomendacji
AWS automatycznie generuje rekomendacje Savings Plans na podstawie Twojej historii użycia. Znajdziesz je w:
Cost Explorer → Savings Plans → Recommendations
Parametry, które warto dostosować:
- Lookback period: 30 dni (domyślne) lub 60 dni (lepsze dla sezonowego workload)
- Term: 1 rok (bezpieczniej) lub 3 lata (jeśli infrastruktura jest stabilna)
- Payment option: No Upfront (dla zachowania płynności) lub All Upfront (maksymalna zniżka)
- Plan type: Compute (elastyczny) lub EC2 Instance (wyższa zniżka)
AWS pokaże:
- Rekomendowaną kwotę zobowiązania ($/h)
- Szacowane oszczędności miesięczne i roczne
- Szacowane pokrycie (coverage %)
Traktuj te rekomendacje jako punkt wyjścia, nie jako ostateczną decyzję. AWS nie wie o Twoich planach migracji, zmianach architektury ani sezonowości.
Savings Plans a multi-cloud i migracje
Jeśli rozważasz przeniesienie części workload na Azure lub GCP w ciągu najbliższych 2-3 lat, zobowiązanie 3-letnie na AWS jest ryzykowne. Nawet Compute Savings Plans z całą swoją elastycznością nie przenoszą się na inną chmurę.
Rekomendacja dla firm z planem multi-cloud:
- Zobowiązanie max na 1 rok
- Pokrycie max 50% baseline (reszta on-demand)
- Regularna rewizja co 6 miesięcy
Dla firm, które są pewne pozostania na AWS:
- 3-letnie zobowiązanie na stabilny baseline to bezpieczna decyzja
- Oszczędności 54-60% vs on-demand znacząco wpływają na budżet IT
Podsumowanie - rekomendacja
Dla większości polskich firm B2B korzystających z AWS, optymalna strategia w 2026 roku wygląda tak:
- Compute Savings Plans (1Y) jako główne zobowiązanie - pokrywa EC2 + Fargate + Lambda, daje pełną elastyczność zmiany regionu i rodziny instancji
- RDS Reserved Instances (1Y lub 3Y) na produkcyjne bazy danych - brak alternatywy
- Spot Instances na batch processing, CI/CD, ML training - 60-90% zniżki bez zobowiązania
- On-demand na dev/test + peak load - elastyczność bez marnotrawstwa
Ta kombinacja daje 35-50% redukcji łącznego rachunku za AWS bez ryzyka, że za rok będziesz płacić za infrastrukturę, której nie potrzebujesz.
Jak możemy pomóc
W Devopsity projektujemy strategie FinOps dla firm na AWS. Typowa współpraca obejmuje:
- Audyt kosztów (1 dzień) - identyfikacja szybkich oszczędności i baseline do zobowiązań
- Rekomendacja SP/RI (1-2 dni) - analiza historii zużycia, dobór optymalnej kombinacji zobowiązań
- Wdrożenie monitoringu (1 dzień) - dashboardy utilization, alerty na niewykorzystane RI, budżety
- Kwartalny przegląd (ongoing) - dostosowanie zobowiązań do zmieniającej się infrastruktury
Przepłacasz za AWS?
Umów się na bezpłatną 30-minutową konsultację techniczną. Bez pitcha - rozmowa o Twoim środowisku i potencjalnych oszczędnościach.
Najczęściej zadawane pytania
Czy mogę anulować Savings Plans przed końcem okresu?
Nie. Savings Plans to zobowiązanie na 1 lub 3 lata i nie jest anulowalne. Jeśli Twoje zużycie spadnie poniżej zobowiązania, nadal płacisz minimalną kwotę. Dlatego zobowiązuj się tylko na stabilny baseline, nie na peak.
Czy Savings Plans obejmują RDS?
Nie. Savings Plans pokrywają tylko compute (EC2, Fargate, Lambda, SageMaker). Dla RDS, ElastiCache, OpenSearch i Redshift jedyną opcją zniżki są Reserved Instances.
Czy mogę mieć jednocześnie RI i Savings Plans?
Tak. AWS najpierw aplikuje RI (bardziej specyficzne), potem SP (bardziej ogólne), a resztę rozlicza on-demand. To standardowe podejście: RI na bazy danych + SP na compute.
Jaka jest minimalna kwota Savings Plans?
Minimum to $0.001/h (~$0.73/miesiąc). W praktyce nie ma sensu kupować SP poniżej ~$0.10/h (~$73/miesiąc), bo oszczędności są minimalne, a administracja jest taka sama.
Kiedy Spot jest lepszy niż Savings Plans?
Spot daje 60-90% zniżki bez zobowiązania, ale instancja może być przerwana w dowolnym momencie. Spot jest lepszy dla workload, który toleruje przerwy: CI/CD, batch processing, ML training, rendering. Dla produkcyjnych serwerów, które muszą działać 24/7 bez przerw, SP/RI to właściwy wybór.
