AWS Savings Plans vs RI 2026: Co wybrać?

Powiem szczerze — wybór pomiędzy AWS Savings Plans (SP) a Reserved Instances (RI) to chyba najbardziej drażniąca decyzja, jaką musisz podjąć jako osoba odpowiedzialna za chmurowy budżet. W 2026 roku AWS oferuje już cztery główne mechanizmy commitmentów, a każdy z nich może przynieść oszczędności od 27% do nawet 72% w porównaniu do cen On-Demand. Brzmi nieźle? Owszem, ale niewłaściwy wybór oznacza zamrożenie budżetu na 1–3 lata bez realnych korzyści (sam widziałem firmę, która kupiła RI na rok przed migracją na Graviton — bolesne).

W tym przewodniku porównamy wszystkie warianty zobowiązań, pokażemy konkretne kalkulacje TCO, przedstawimy kod AWS CLI do analizy pokrycia oraz omówimy strategie hybrydowe, których naprawdę używają dojrzałe zespoły FinOps. Zero teorii akademickiej — tylko to, co działa.

Czym właściwie są AWS Savings Plans i Reserved Instances?

Oba mechanizmy są formą commitmentu finansowego — zobowiązujesz się do określonego poziomu wydatków albo uruchomienia konkretnych instancji przez 1 lub 3 lata, a w zamian dostajesz rabat. Cała różnica leży w elastyczności i zakresie pokrycia. I to właśnie ta elastyczność (lub jej brak) zazwyczaj decyduje o tym, czy commitment się opłaci.

Reserved Instances (RI) — model klasyczny

RI to starszy mechanizm, wprowadzony jeszcze w 2009 roku. Zobowiązujesz się do konkretnego typu instancji (np. m6i.large) w określonym regionie. Istnieją dwa warianty:

Standard RI — najwyższy rabat (do 72% dla 3-letniego No Upfront), za to elastyczność na poziomie betonu. Można zmienić tylko Availability Zone, rozmiar w obrębie tej samej rodziny i platformę sieciową.
Convertible RI — rabat do 66%, ale możesz wymienić rezerwację na inną rodzinę instancji, OS lub tenancy. Idealne, gdy planujesz migrację z Intel na Graviton albo zmianę architektury.

Savings Plans (SP) — model nowoczesny

SP wprowadzono w 2019 roku jako uproszczenie tego całego bałaganu. Zamiast zobowiązywać się do konkretnej instancji, zobowiązujesz się do stałych wydatków godzinowych (np. $10/h) przez 1 lub 3 lata. W 2026 roku dostępne są trzy typy:

Compute Savings Plans — najbardziej elastyczne. Pokrywają EC2, Fargate i Lambda, niezależnie od regionu, rodziny instancji czy OS. Rabat do 66%.
EC2 Instance Savings Plans — ograniczone do jednej rodziny instancji w jednym regionie. Wyższy rabat (do 72%), ale niska elastyczność — w sumie podobnie jak Standard RI.
SageMaker Savings Plans — dedykowane dla obciążeń ML w SageMaker. Rabat do 64% bez ograniczeń co do instancji.

Porównanie tabelaryczne: SP vs RI w 2026

Czasem jeden rzut oka na tabelę mówi więcej niż dwa akapity tekstu. Poniższe zestawienie podsumowuje kluczowe różnice w aktualnej ofercie AWS:

Cecha	Compute SP	EC2 Instance SP	Standard RI	Convertible RI
Maks. rabat	66%	72%	72%	66%
Pokrywa Lambda/Fargate	Tak	Nie	Nie	Nie
Zmiana regionu	Tak	Nie	Nie	Tak (wymiana)
Zmiana rodziny	Tak	Nie	Nie	Tak (wymiana)
Marketplace (odsprzedaż)	Nie	Nie	Tak	Nie
Okresy commitmentu	1 lub 3 lata	1 lub 3 lata	1 lub 3 lata	1 lub 3 lata
Modele płatności	No/Partial/All Upfront	No/Partial/All Upfront	No/Partial/All Upfront	No/Partial/All Upfront

Realne kalkulacje TCO dla 2026 roku

Przyjmijmy konkretny scenariusz. Aplikacja webowa działająca 24/7 na instancjach m6i.large w regionie eu-central-1 (Frankfurt). Cena On-Demand to ok. $0.108/h. To jest baseline, od którego liczymy oszczędności.

Scenariusz A: 20 instancji m6i.large, stabilne obciążenie

On-Demand: 20 × $0.108 × 8760h = $18 921/rok
3-year Standard RI, All Upfront: ok. 60% rabatu = $7 568/rok (oszczędność $11 353)
3-year EC2 Instance SP, All Upfront: 60% rabatu = $7 568/rok
3-year Compute SP, All Upfront: 54% rabatu = $8 703/rok (oszczędność $10 218)

Różnica między EC2 Instance SP a Compute SP to mniej więcej $1 135/rok. Można to traktować jako cenę elastyczności — możliwości migracji do innej rodziny lub regionu, gdy biznes nagle zmieni kierunek (a wiesz przecież, że zmieni).

Scenariusz B: Mix obciążeń — EC2 + Fargate + Lambda

Tutaj robi się ciekawie. Jeśli architektura zawiera serverless (Lambda, Fargate), to RI w ogóle tych usług nie pokrywają. Tylko Compute SP obejmuje całość. Załóżmy firmę wydającą $50 000/miesiąc na compute (60% EC2, 25% Fargate, 15% Lambda):

RI tylko na EC2: oszczędność ok. $216 000/rok
Compute SP na całość: oszczędność ok. $324 000/rok

W tym przypadku Compute SP wygrywa o $108 000/rok, mimo że ma niższy stawkowy rabat. Powód? Po prostu pokrywa więcej. To jest moim zdaniem najczęściej pomijany argument — ludzie patrzą na procentowy rabat, a nie na bezwzględne oszczędności.

Strategia pokrycia: zasada warstwowa

Dojrzałe zespoły FinOps stosują strategię warstwową. Zamiast wybierać jeden typ commitmentu, mieszają je w przemyślanych proporcjach:

Warstwa bazowa (60–70% pokrycia): 3-year Compute SP No Upfront — pokrywa stabilne minimum obciążenia z maksymalną elastycznością.
Warstwa średnia (20–30% pokrycia): 1-year EC2 Instance SP lub Standard RI — wyższy rabat dla przewidywalnych workloadów, krótszy commitment ogranicza ryzyko.
Warstwa zmienna (10–20% pokrycia): On-Demand i Spot Instances — absorbują szczyty oraz wszelkie eksperymenty.

Złota zasada: nigdy nie kupuj więcej niż 80% commitmentu, bo niewykorzystany SP/RI to czysta strata. Nie jest to zresztą abstrakcja — według raportu Flexera State of the Cloud 2026, średni poziom marnotrawstwa commitmentów wynosi 13%. Dwa procenty całego budżetu chmurowego idą w błoto, bo ktoś kupił "z górką, na wszelki wypadek".

Praktyka: analiza pokrycia przez AWS CLI

Zanim cokolwiek kupisz — sprawdź aktualne wykorzystanie i pokrycie. AWS Cost Explorer udostępnia dwa kluczowe API: get-savings-plans-coverage i get-reservation-coverage. Bez tej analizy działasz po omacku.

Sprawdzenie pokrycia Savings Plans z ostatnich 30 dni

aws ce get-savings-plans-coverage \
  --time-period Start=2026-04-11,End=2026-05-11 \
  --granularity DAILY \
  --metrics SpendCoveredBySavingsPlans \
  --query 'SavingsPlansCoverages[*].[TimePeriod.Start,Coverage.CoveragePercentage]' \
  --output table

Identyfikacja niepokrytych wydatków On-Demand

aws ce get-cost-and-usage \
  --time-period Start=2026-04-11,End=2026-05-11 \
  --granularity MONTHLY \
  --metrics UnblendedCost \
  --filter '{
    "And": [
      {"Dimensions": {"Key": "SERVICE", "Values": ["Amazon Elastic Compute Cloud - Compute"]}},
      {"Dimensions": {"Key": "PURCHASE_TYPE", "Values": ["On Demand"]}}
    ]
  }' \
  --group-by Type=DIMENSION,Key=INSTANCE_TYPE

Rekomendacje zakupu od AWS

aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years THREE_YEARS \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS \
  --query 'SavingsPlansPurchaseRecommendation.SavingsPlansPurchaseRecommendationDetails[*].[HourlyCommitmentToPurchase,EstimatedMonthlySavingsAmount,EstimatedROI]'

Mała uwaga z doświadczenia: rekomendacje AWS bazują na 7-, 30- lub 60-dniowym oknie historycznym. Dla obciążeń z sezonowością (czyli — szczerze — większości realnych systemów produkcyjnych) zawsze wybierz SIXTY_DAYS. Inaczej ryzykujesz przeszacowanie commitmentu o 20–30%.

Kiedy wybrać RI zamiast SP?

Mimo że Savings Plans są domyślnym wyborem dla większości scenariuszy, RI nadal mają swoje miejsce. Konkretnie:

RDS, ElastiCache, Redshift, OpenSearch, DynamoDB — Savings Plans nie pokrywają tych usług, kropka. Tylko RI / Reserved Capacity da Ci tu rabat.
Potrzeba odsprzedaży — Standard RI można sprzedać na Reserved Instance Marketplace. Savings Plans są nieodwracalne, więc kupujesz je raz na zawsze.
Capacity Reservation — RI gwarantuje pojemność w AZ. SP nie rezerwują mocy, więc w przypadku braku zasobów (np. podczas regionalnej awarii) potrzebujesz osobnej On-Demand Capacity Reservation.

Najczęstsze błędy przy zakupie commitmentów

1. Zakup na podstawie szczytu, nie bazy

Klasyk. Analiza tygodniowego obciążenia pokazuje pik 100 instancji w godzinach 9–17, ale baseline to 30 instancji. Kupuj commitment tylko na baseline (30), reszta niech idzie na On-Demand albo Spot. Inaczej co weekend płacisz za niewykorzystany commitment.

2. Ignorowanie roadmapy architektury

Jeśli za 6 miesięcy planujesz migrację z m5 na m7g (Graviton), Standard RI lub EC2 Instance SP zostaną uwięzione w starym świecie. Wybierz Compute SP albo Convertible RI — koszt elastyczności (1–2 punkty procentowe rabatu) jest groszowy w porównaniu z koniecznością płacenia za nieużywany commitment.

3. Brak współdzielenia commitmentów na poziomie organizacji

W AWS Organizations koniecznie włącz Reserved Instance Sharing oraz Savings Plans Sharing, żeby commitmenty z jednego konta pokrywały wydatki innych:

aws organizations enable-aws-service-access \
  --service-principal ram.amazonaws.com

aws ce update-cost-allocation-tags-status \
  --cost-allocation-tags-status TagKey=Environment,Status=Active

4. Pomijanie All Upfront przy stabilnych workloadach

Przy 3-letnim commitmencie różnica między No Upfront a All Upfront to dodatkowe 2–4% rabatu. Dla firmy wydającej $1M/rok mówimy o $20–40k oszczędności w zamian za zamrożenie gotówki. Czy się opłaca? Zależy od kosztu kapitału, ale dla większości firm — zdecydowanie tak.

Automatyzacja: Terraform + Lambda do monitoringu pokrycia

Dobrze, teorii już dość. Poniższy moduł Terraform tworzy regularną Lambdę, która co tydzień sprawdza pokrycie SP i wysyła alert do Slacka, jeśli spadnie poniżej 70%. To rozwiązanie, które wdrażam u praktycznie każdego klienta:

resource "aws_lambda_function" "sp_coverage_monitor" {
  function_name = "savings-plans-coverage-monitor"
  runtime       = "python3.12"
  handler       = "index.lambda_handler"
  role          = aws_iam_role.sp_monitor.arn
  timeout       = 60

  environment {
    variables = {
      SLACK_WEBHOOK = var.slack_webhook
      THRESHOLD     = "70"
    }
  }
}

resource "aws_cloudwatch_event_rule" "weekly" {
  name                = "sp-coverage-weekly"
  schedule_expression = "cron(0 9 ? * MON *)"
}

resource "aws_cloudwatch_event_target" "lambda" {
  rule = aws_cloudwatch_event_rule.weekly.name
  arn  = aws_lambda_function.sp_coverage_monitor.arn
}

A oto kod handlera Lambdy:

import boto3, os, json, urllib.request
from datetime import datetime, timedelta

def lambda_handler(event, context):
    ce = boto3.client('ce')
    end = datetime.utcnow().date()
    start = end - timedelta(days=7)

    resp = ce.get_savings_plans_coverage(
        TimePeriod={'Start': str(start), 'End': str(end)},
        Granularity='MONTHLY'
    )
    coverage = float(resp['SavingsPlansCoverages'][0]['Coverage']['CoveragePercentage'])
    threshold = float(os.environ['THRESHOLD'])

    if coverage < threshold:
        msg = f":warning: Pokrycie Savings Plans spadło do {coverage:.1f}% (próg: {threshold}%)"
        req = urllib.request.Request(
            os.environ['SLACK_WEBHOOK'],
            data=json.dumps({'text': msg}).encode(),
            headers={'Content-Type': 'application/json'}
        )
        urllib.request.urlopen(req)

    return {'coverage': coverage}

Najnowsze zmiany w 2026 roku

Świat AWS commitmentów nie stoi w miejscu. W ciągu ostatnich 12 miesięcy AWS wprowadził kilka modyfikacji, które warto znać:

Savings Plans dla Bedrock — od Q1 2026 dostępne dla wybranych modeli. Rabat do 50% przy 1-letnim commitmencie. Game changer dla firm budujących produkty z GenAI.
Rozszerzone Compute SP — obejmują teraz także AWS Lambda SnapStart oraz Lambda Provisioned Concurrency.
Granularność godzinowa w Cost Explorer — nowy parametr HOURLY w API pozwala precyzyjnie identyfikować okna niskiego pokrycia.

Rekomendowana strategia 2026: ścieżka decyzyjna

Jeśli nie wiesz, od czego zacząć, oto ściąga którą sam stosuję podczas pierwszych warsztatów FinOps:

Masz stabilne obciążenie tylko na EC2, brak planów migracji? → 3-year EC2 Instance SP All Upfront
Używasz mix EC2 + Fargate + Lambda? → 3-year Compute SP No/Partial Upfront
Planujesz migrację Intel → Graviton w ciągu 12 miesięcy? → 1-year Compute SP + Convertible RI na chwilowe pozycje
Masz znaczące wydatki na RDS/ElastiCache? → RDS Reserved Instances dodatkowo do Compute SP
Niepewność biznesowa (startup, projekt < 12 miesięcy)? → 1-year No Upfront SP + Spot Instances

Często zadawane pytania (FAQ)

Czy mogę anulować Savings Plans przed terminem?

Nie. Zarówno Savings Plans, jak i Reserved Instances są nieodwracalnymi zobowiązaniami finansowymi. Standard RI można jednak odsprzedać na Reserved Instance Marketplace — z reguły poniżej ceny zakupu i tylko jeśli RI ma ponad miesiąc do końca.

Co się stanie, jeśli wydam mniej niż commitment Savings Plans?

Płacisz pełną kwotę commitmentu, niezależnie od faktycznego użycia. Jeśli zobowiążesz się na $10/h, a wykorzystasz tylko $7/h, te brakujące $3/h to czysta strata. Dlatego rekomenduję pokrywać 60–80% baseline, a nigdy szczytu.

Czy Savings Plans pokrywają Spot Instances?

Nie. Spot Instances mają już własny rabat (do 90%) i nie są objęte ani SP, ani RI. Spot i SP to komplementarne strategie — SP pokrywa baseline, Spot łapie elastyczną pojemność.

Jak wybrać między No Upfront, Partial Upfront i All Upfront?

All Upfront daje dodatkowe 2–4% rabatu w zamian za zapłatę z góry. Wybierz tę opcję, jeśli masz nadwyżkę gotówki i preferujesz niższy TCO. No Upfront jest lepszy dla startupów dbających o cash flow albo przy testowaniu nowej strategii commitmentów.

Czy Convertible RI to dobry wybór w 2026 roku?

W większości przypadków — nie. Compute SP są po prostu lepsze: oferują podobny rabat (66%) i znacznie większą elastyczność (pokrywają Lambda, Fargate, dowolny region). Convertible RI mają sens głównie wtedy, gdy potrzebujesz Capacity Reservation w konkretnej AZ.

Czy commitmenty można współdzielić między kontami AWS Organizations?

Tak. W AWS Organizations można włączyć RI Sharing oraz Savings Plans Sharing w ustawieniach Billing & Cost Management. Po aktywacji commitment z konta master automatycznie pokrywa wydatki we wszystkich kontach członkowskich (chyba że konkretne konto zostało wyłączone z sharingu).

Podsumowanie

W 2026 roku Compute Savings Plans są domyślnym wyborem dla większości organizacji — łączą wysoki rabat z bezprecedensową elastycznością obejmującą Lambda, Fargate i EC2 niezależnie od regionu. Reserved Instances wciąż jednak pozostają niezbędne dla RDS, ElastiCache i innych usług niewspieranych przez SP, a także w scenariuszach wymagających odsprzedaży lub Capacity Reservation.

Klucz do sukcesu? Strategia warstwowa: 60–70% pokrycia commitmentami, 10–20% Spot Instances, reszta On-Demand jako bufor. I jeszcze jedno — co najmniej raz w miesiącu monitoruj wskaźnik pokrycia i wykorzystania. Niewykorzystany commitment to czysta strata, a niskie pokrycie oznacza utracone oszczędności. Obie sytuacje kosztują, więc warto trzymać rękę na pulsie.