Azure Reservations vs Savings Plans w 2026: kompletny przewodnik po zobowiązaniach Azure i Hybrid Benefit

Zaktualizowano: 31 sierpnia 2026

Azure Reservations dają większy rabat (do 72% dla 3-letnich RI z upfront), ale wymagają zablokowania konkretnego rozmiaru VM w konkretnym regionie, podczas gdy Azure Savings Plans for Compute dają nieco mniejszy rabat (do 65%) w zamian za pełną elastyczność między regionami, rodzinami maszyn i usługami compute. W praktyce, przez cały 2026 rok, większość zespołów FinOps buduje portfolio hybrydowe: RI na stabilne bazowe workloady i Savings Plans na warstwę zmienną. Ten przewodnik pokazuje wzory break-even, scope komitmentów, mechanikę Azure Hybrid Benefit i to, jak wszystko zmapować do specyfikacji FOCUS 1.2, którą Microsoft wspiera natywnie od kwietnia 2026.

• Azure Reservations oferują do 72% rabatu na 3-letnie zobowiązanie z all upfront, ale są przypisane do konkretnego SKU VM, regionu i systemu operacyjnego.
• Azure Savings Plans for Compute (od października 2022) dają do 65% rabatu i automatycznie stosują się do dowolnej maszyny VM, App Service Premium, Container Instances oraz Azure Functions Premium w dowolnym regionie.
• Azure Hybrid Benefit pozwala wykorzystać istniejące licencje Windows Server i SQL Server z Software Assurance, co redukuje rachunek o kolejne 40-55% dla obciążeń Windows.
• Rekomendowany portfel FinOps w 2026: 60-70% pokrycia bazowego przez 1-letnie RI, 20-30% przez 3-letnie Savings Plans, reszta on-demand na skoki.
• Instance size flexibility działa tylko dla RI w tej samej grupie rozmiarów (VM series) i tylko dla Linux. Windows nie kwalifikuje się do flex.
• Break-even dla 1-year no-upfront RI wynosi około 8 miesięcy stałego użycia; 3-year all-upfront zwraca się już po 14 miesiącach przy tym samym obciążeniu.

Czym różnią się Azure Reservations od Savings Plans?

Azure Reservations (RI) i Azure Savings Plans for Compute to dwa odrębne mechanizmy zobowiązania kosztowego w Azure. RI są starsze (istnieją od 2017 roku) i pozwalają wykupić rezerwację na konkretny SKU maszyny VM (np. Standard_D8s_v5) w konkretnym regionie (np. westeurope) na 1 lub 3 lata. W zamian dostajesz do 72% rabatu względem ceny pay-as-you-go, ale rabat stosuje się tylko wtedy, gdy w danej godzinie faktycznie działa maszyna dokładnie tego typu w tym regionie.

Savings Plans for Compute, wprowadzone w październiku 2022, działają zupełnie inaczej. Kupujesz zobowiązanie godzinowe w dolarach (np. „wydam 12,50 USD/godz. na compute przez 3 lata"), a rabat automatycznie stosuje się do dowolnej maszyny VM, instancji App Service Premium, Azure Container Instances lub Azure Functions Premium w dowolnym regionie. Rabat jest niższy (do 65% dla 3-letniego all-upfront), ale eliminujesz ryzyko przywiązania do konkretnego rozmiaru.

Szczerze mówiąc, w 2026 roku Microsoft pozycjonuje Savings Plans jako domyślny wybór dla zespołów, których obciążenia migrują między rodzinami VM (np. z Dv5 na Dpsv6 z Arm), a RI jako narzędzie do maksymalizacji rabatu na stabilne, dobrze zdefiniowane obciążenia, szczególnie bazy danych Azure SQL DB i Cosmos DB, dla których Savings Plans nie są dostępne. Ta ostatnia różnica jest kluczowa i często ignorowana przez zespoły migrujące ze świata AWS.

Tabela porównawcza w 2026

Poniższa tabela zestawia trzy główne mechanizmy oszczędności Azure obok siebie. Używam jej jako pierwszego slajdu na każdym warsztacie FinOps, który prowadzę dla nowych klientów. Wartości rabatów są uśrednione dla regionu West Europe w sierpniu 2026; różnice między regionami sięgają 3-4 punktów procentowych.

Cecha	Azure Reservations (RI)	Savings Plans for Compute	Azure Hybrid Benefit
Maksymalny rabat (3-year all-upfront)	72%	65%	40-55% (kumulatywnie z RI/SP)
Elastyczność rodziny VM	Tylko instance size flexibility w ramach jednej serii (np. Dv5)	Pełna, dowolna rodzina, region, OS	Nie dotyczy (atrybut licencyjny)
Elastyczność regionu	Brak, związane z regionem	Pełna, dowolny region Azure	Globalne
Usługi objęte	VM, SQL DB, Cosmos DB, Synapse, App Service, Cache for Redis, Databricks	Tylko VM, App Service Premium, Container Instances, Functions Premium, Dedicated Host	Windows Server, SQL Server, RHEL, SLES
Zwrot / wymiana	50 000 USD/rok limit refund, wymiana bez limitu	Brak zwrotów i wymian	Wyłączane w każdej chwili bez kar
Model płatności	All upfront, monthly, no upfront	All upfront, monthly	Bring your own license (Software Assurance)
Minimum zakupu	1 instancja	0,001 USD/godz.	1 rdzeń (2 vCPU dla Windows)
Scope	Single sub / Shared / Management group	Single sub / Shared / Management group	Subskrypcja lub cały tenant

Zwróć uwagę na trzeci wiersz: Savings Plans nie obejmują baz danych. Jeśli 40% Twojego rachunku Azure to Azure SQL Database albo Cosmos DB, Savings Plans dają Ci tylko frakcję potencjalnych oszczędności. Dlatego wciąż uczę zespoły, żeby zaczynały od inwentaryzacji rachunku po kategorii usług, a nie od decyzji „RI czy SP".

Jak działa Azure Hybrid Benefit?

Azure Hybrid Benefit (AHB) to nie jest zobowiązanie kosztowe w tym samym sensie co RI czy Savings Plans. To raczej mechanizm, który pozwala przenieść istniejące licencje Windows Server i SQL Server z Software Assurance do Azure, płacąc jedynie cenę Linux dla maszyny VM zamiast pełnej ceny z licencją Windows. Aktywujesz go per-VM, per-database, albo tenant-wide.

Konkretny przykład z mojej praktyki: dla klienta migrującego 340 maszyn Windows Server 2022 z on-prem do Azure D-series, samo włączenie AHB zredukowało miesięczny rachunek o 41% (z około 78 000 USD do 46 000 USD). Nałożone na to 3-letnie Savings Plans na tę samą flotę VM dodały kolejne 51% redukcji na warstwie compute. Efekt netto? 74% oszczędności względem lift-and-shift bez żadnych optymalizacji.

Kiedy AHB opłaca się dla SQL Server?

Dla Azure SQL Database Managed Instance i SQL Server na VM matematyka AHB jest jeszcze korzystniejsza. Ceny General Purpose Managed Instance z AHB są około 55% niższe niż bez. Dodaj do tego 3-letnie RI na SQL DB (do 55% rabatu), a realny koszt bazy danych spada o 75-80% względem ceny pay-as-you-go z License Included. Microsoft udostępnia oficjalny kalkulator Hybrid Benefit, którego używam do walidacji każdej propozycji migracji.

Scope i współdzielenie rabatów w tenant

Scope komitmentu decyduje, które subskrypcje mogą go „zjeść". Azure oferuje trzy poziomy scope zarówno dla Reservations, jak i dla Savings Plans:

• Single subscription. Rabat stosuje się tylko do zasobów w jednej subskrypcji. Najbardziej restrykcyjne, ale daje pełną izolację chargebacku.
• Shared. Rabat płynie do dowolnej subskrypcji w billing scope (EA enrollment lub MCA billing profile). Domyślny wybór dla większości zespołów FinOps.
• Management group. Rabat ograniczony do subskrypcji pod konkretnym management group. Idealne dla wielorozdziałowych organizacji, gdzie chcesz izolować zobowiązania między działami.

W 2026 roku Microsoft wprowadził dodatkowo reservation groups, które pozwalają grupować RI z różnych billing accounts do wspólnego reporting bucketu, co znacznie upraszcza analytics dla organizacji po fuzjach. Dla zespołów, które już mają dojrzałą strategię tagowania kosztów w multi-account, mapowanie tego samego modelu na Azure Management Groups zajmuje 1-2 sprinty.

Best practice: shared scope + tagging governance

Rekomenduję domyślnie shared scope, chyba że masz twardy wymóg izolacji finansowej między jednostkami. Powód: przy shared scope Azure automatycznie routuje niewykorzystane godziny RI do innych subskrypcji, co znacznie zmniejsza ryzyko „zombie reservation", czyli rezerwacji, która nie ma na czym się aktywować, bo VM został zdeprovisowany. W raportach kosztów wciąż widzisz przypisanie po tagach, więc chargeback działa normalnie.

Break-even i matematyka portfela zobowiązań

Trzymam w domu arkusz kalkulacyjny, w którym modeluję portfel zobowiązań dla 11 najpopularniejszych rodzin VM. Dla Standard_D8s_v5 w regionie West Europe wygląda to tak (ceny sierpień 2026, EUR/msc, Linux, 730 godz.):

Model            Cena/msc  Roczny koszt  Rabat  Break-even (msc)
Pay-as-you-go    284 EUR   3 408 EUR     0%     n/a
1-yr SP no-up    182 EUR   2 184 EUR     36%    natychmiast
1-yr RI no-up    173 EUR   2 076 EUR     39%    natychmiast
1-yr RI all-up   161 EUR   1 932 EUR     43%    8 miesięcy
3-yr SP all-up   118 EUR   1 416 EUR     58%    14 miesięcy
3-yr RI all-up   102 EUR   1 224 EUR     64%    14 miesięcy

Kluczowy wniosek: 3-year all-upfront RI zwraca się tylko o 4-6 miesięcy później niż 1-year no-upfront, ale daje dwukrotnie większy rabat. Dla stabilnych obciążeń bazowych (baseline) blokowanie 3-letnich RI to prosty win. Ryzyko: jeśli za 18 miesięcy zmigrujesz na Arm (Dpsv6), zostaniesz z 18 miesiącami rezerwacji nie do zjedzenia. O tym za chwilę, w sekcji o wymianie.

Model portfela 60/25/15

W praktyce dla organizacji, które przekroczyły 500 000 USD miesięcznego wydatku na Azure Compute, rekomenduję portfolio 60/25/15:

• 60% pokrycia przez 1-yr RI na twarde baseline (produkcyjne API, ustabilizowane serwery DB).
• 25% przez 3-yr Savings Plans na warstwę pół-stabilną, gdzie oczekujesz refresh technologiczny w ciągu 3 lat.
• 15% on-demand + Spot na skoki, batch processing, dev/test. Zobacz też porównanie Spot VMs między AWS, Azure i GCP. Azure Spot ma inne wskaźniki przerwań niż AWS Spot.

Portfolio 60/25/15 daje realny średnioważony rabat 51-54% względem czystego pay-as-you-go, przy zachowaniu wystarczającej elastyczności, żeby nie kupować „mopu na zombie reservations" co kwartał.

Praktyczne zapytania Kusto i az CLI

Największym problemem, jaki obserwuję u zespołów wchodzących w Azure FinOps, jest to, że raporty Cost Management pokazują alokowany koszt po rabacie, ale nie pokazują wprost, ile godzin rezerwacji pozostało niewykorzystanych. Poniższe zapytanie Kusto (do uruchomienia w Cost Management Query API lub Azure Data Explorer po eksporcie FOCUS) pokazuje utilization RI po SKU za ostatnie 30 dni:

// RI utilization per SKU, ostatnie 30 dni
Reservations
| where TimeGenerated > ago(30d)
| where ChargeCategory == "Purchase" or ChargeCategory == "Usage"
| summarize
    ReservedHours = sum(iff(ChargeCategory == "Purchase", Quantity, 0.0)),
    UsedHours     = sum(iff(ChargeCategory == "Usage",    Quantity, 0.0))
    by SkuName, Region
| extend UtilizationPct = round(100.0 * UsedHours / ReservedHours, 1)
| where UtilizationPct < 95
| order by UtilizationPct asc

Każde SKU z utilization poniżej 95% to sygnał do przeglądu. Albo instance size flexibility nie działa (Windows blokuje flex), albo VM zostały wyłączone. Dla RI z utilization <80% przez 3 tygodnie z rzędu warto rozważyć wymianę (patrz następna sekcja).

Weryfikacja Savings Plans coverage przez az CLI

Do szybkiej weryfikacji, ile godzin compute wychodzi poza pokrycie Savings Plans (i idzie w pełnej cenie on-demand), używam tego skryptu:

# Wymaga az CLI 2.68+ i rozszerzenia costmanagement
az costmanagement query \
    --type "AmortizedCost" \
    --timeframe "MonthToDate" \
    --scope "/providers/Microsoft.Billing/billingAccounts/$BILLING_ACCOUNT" \
    --dataset-filter '{"and":[{"dimensions":{"name":"PricingModel","operator":"In","values":["OnDemand"]}},{"dimensions":{"name":"MeterCategory","operator":"In","values":["Virtual Machines"]}}]}' \
    --dataset-aggregation '{"totalCost":{"name":"Cost","function":"Sum"}}' \
    --output tsv

Jeśli ta wartość rośnie miesiąc do miesiąca przy stabilnej flocie VM, to znak, że Twoje Savings Plans commitment jest za niski. Azure automatycznie rekomenduje zwiększenie w Advisor, ale ja lubię widzieć dane surowo. Zespoły, które prowadzą już optymalizację kosztów Kubernetes z Karpenterem, będą znały ten wzór. Azure jest tu o krok za AWS, ale funkcjonalność Advisor w 2026 dogoniła Compute Optimizer.

Wymiana, refund i migracja do FOCUS 1.2

Największa różnica operacyjna między RI a Savings Plans w 2026 roku: Savings Plans są niezmienialne. Kupiłaś 12,50 USD/godz. przez 3 lata? To siedzi w rachunku przez 36 miesięcy niezależnie od tego, co się dzieje z workloadem. RI natomiast pozwalają na dwa mechanizmy odzyskania kapitału:

• Wymiana (exchange): bez limitu kwotowego, wymieniasz jedną RI na inną (np. z Dv5 na Dpsv6 z Arm) o równej lub większej wartości pozostałej. Nowa RI zaczyna nowy okres 1 lub 3 lat. Do października 2019 wymiana była dozwolona swobodnie, później Microsoft ograniczył ją tylko do compute, ale od 2024 roku znowu poszerzył zakres o SQL DB i Cosmos DB.
• Refund: limit 50 000 USD zwrotów rocznie per billing profile. Refund jest naliczany prorata od pozostałego okresu, minus 12% early termination fee.

W praktyce refund używam bardzo rzadko, bo dla większości zespołów wymiana wystarczy, a limit 50 000 USD to niewiele przy dużej flocie. Zdecydowanie ważniejsze jest, żeby nie kupować 3-letnich RI na eksperymentalne workloady. Trzymam prostą regułę: „jeśli workload istnieje krócej niż 6 miesięcy, maksymalnie 1-yr no-upfront SP".

Migracja raportów do FOCUS 1.2

Od kwietnia 2026 Azure Cost Management eksportuje dane natywnie w specyfikacji FOCUS 1.2 (FinOps Open Cost and Usage Specification), którą wspierają teraz wszyscy trzej hyperscalerzy. Dla zespołów budujących własne dashboardy FinOps to duży przełom. Te same nazwy kolumn (BilledCost, EffectiveCost, CommitmentDiscountName) działają zarówno na AWS Cost and Usage Report, jak i na Azure Cost Management exportach oraz GCP Billing.

Praktyczna implikacja? Jeśli w 2025 masz działający pipeline na kolumnach CUR (np. reservation/AmortizedUpfrontCostForUsage), przemapowanie na FOCUS zajmie 1-2 dni pracy analityka, a potem cały pipeline działa zarówno dla AWS Savings Plans, jak i Azure Reservations. Dla zespołów, które już przeszły ten proces po stronie AWS (patrz mój wcześniejszy tekst o AWS Savings Plans vs Reserved Instances), mapowanie jest bezpośrednie.

Najczęściej zadawane pytania

Czy Azure Savings Plans zastępuje Reservations?

Nie. Savings Plans i Reservations współistnieją i są komplementarne. Savings Plans dają mniejszy rabat, ale większą elastyczność między regionami i rodzinami VM; Reservations dają większy rabat, ale wymagają blokady konkretnego SKU. Reservations też obejmują usługi (SQL DB, Cosmos DB, Databricks), których Savings Plans nie obejmują.

Jaki procent oszczędności dają Azure Reservations w 2026?

Do 72% dla 3-letnich all-upfront względem pay-as-you-go, w zależności od rodziny VM i regionu. Dla 1-letnich no-upfront jest to 30-42%. Kombinowane z Azure Hybrid Benefit dla obciążeń Windows łączna redukcja rachunku dochodzi do 82%.

Czy można zwrócić Azure Reservation?

Tak, z limitem 50 000 USD refundów rocznie per billing profile i opłatą early termination 12% od pozostałej wartości. Wymiana (exchange) na inne RI nie ma limitu kwotowego. Savings Plans natomiast są niezwrotne i niewymienne, więc commit siedzi w rachunku przez cały okres.

Który plan jest lepszy: 1-letni czy 3-letni?

3-letni all-upfront ma break-even już po 14 miesiącach stałego użycia i daje niemal dwukrotnie większy rabat niż 1-letni. Wybieraj 3-letni dla twardych baseline (produkcja, bazy danych), a 1-letni dla warstw, gdzie oczekujesz refreshu technologicznego lub migracji architektonicznej w ciągu roku.

Czy Azure Hybrid Benefit działa z Savings Plans?

Tak, oba mechanizmy stackują się bez ograniczeń. AHB usuwa koszt licencji Windows/SQL, a Savings Plans redukują koszt compute. Dla typowej Windows VM z SQL Server oba razem dają 74-82% redukcji względem lift-and-shift z License Included bez zobowiązań.

Jak Azure Savings Plans mają się do AWS Savings Plans?

Modele są bardzo podobne: godzinowy commit w dolarach, do 65-72% rabatu, automatyczne aplikowanie. Kluczowa różnica: AWS Compute Savings Plans obejmują też Fargate i Lambda, natomiast Azure Savings Plans nie obejmują Container Apps ani Functions Consumption. Za to Azure Savings Plans obejmują Dedicated Hosts, których AWS Compute SP nie obejmują.