Стратегии и най-добри практики 12 мин четене

Savings Plans срещу Reserved Instances: Пълно ръководство за AWS, Azure и GCP (2026)

Научете как да изберете между Savings Plans и Reserved Instances при AWS, Azure и GCP. Сравнение, стратегия за комбиниране и практически примери с CLI и Terraform за оптимизация на облачните разходи.

Editorial Team

Защо ангажиментите за облачни разходи са толкова важни

През 2026 г. глобалните разходи за публични облачни услуги вече надхвърлят 1 трилион долара. Само си помислете — трилион. При такива мащаби дори няколко процента разлика в цената могат да означават стотици хиляди долари годишна икономия за средноголяма организация.

Savings Plans и Reserved Instances са двата основни модела за ценообразуване, базирано на ангажименти, предлагани от AWS, Azure и GCP. Правилният избор между тях (или по-точно — правилната комбинация) може да намали облачната ви сметка с до 72%.

Честно казано, темата изглежда сложна на пръв поглед, но всъщност не е чак толкова страшна, когато разберете основните принципи. Нека разгледаме как работят двата модела при всеки от трите големи доставчика и каква стратегия за комбиниране има смисъл.

AWS: Savings Plans срещу Reserved Instances

Какво представляват AWS Reserved Instances (RI)

Reserved Instances изискват ангажимент за използване на конкретен тип инстанция на определена цена за 1 или 3 години. AWS предлага два вида:

  • Standard RI — предлагат най-висока отстъпка (до 72%), но са най-ограничени. Не могат да бъдат конвертирани, но пък могат да се препродават на AWS Reserved Instance Marketplace.
  • Convertible RI — предлагат по-ниска отстъпка (до 54%), но позволяват смяна на инстанцията (фамилия, ОС, наемател), стига новата конфигурация да е на равна или по-висока стойност.

Reserved Instances покриват EC2, RDS, ElastiCache, Redshift, OpenSearch, MemoryDB и DynamoDB. Една важна особеност, която мнозина пропускат — RI предлагат резервация на капацитет (Capacity Reservation). Това е гаранция, че AWS ще осигури наличност на инстанциите в конкретна зона на достъпност, което е критично за production натоварвания.

Какво представляват AWS Savings Plans

Savings Plans работят по доста различен принцип. Вместо да се ангажирате с конкретна инстанция, вие се ангажирате за определен почасов разход ($/час) за 1 или 3 години. AWS предлага четири типа:

  • Compute Savings Plans — до 66% отстъпка. Покриват EC2, Fargate и Lambda. Не изискват избор на конкретна фамилия инстанции, регион или ОС — пълна гъвкавост.
  • EC2 Instance Savings Plans — до 72% отстъпка. Изискват избор на фамилия инстанции и регион, но позволяват смяна на размер, ОС и наемател.
  • SageMaker Savings Plans — до 64% отстъпка за ML натоварвания в SageMaker.
  • Database Savings Plans — до 35% отстъпка за RDS и Aurora (да, само 35%, ще обясня защо това е важно по-нататък).

Сравнителна таблица: AWS RI срещу Savings Plans

ХарактеристикаReserved InstancesSavings Plans
Тип ангажиментКонкретна конфигурация на инстанцияФиксиран почасов разход ($/час)
Максимална отстъпкаДо 72% (Standard RI)До 72% (EC2 Instance SP)
ГъвкавостНиска (Standard) до Средна (Convertible)Висока (Compute SP)
Покрити услугиEC2, RDS, ElastiCache, Redshift и др.EC2, Fargate, Lambda, SageMaker, RDS
ПрепродажбаДа (Standard RI на Marketplace)Не
Резервация на капацитетДаНе
Опции за плащанеAll Upfront, Partial, No UpfrontAll Upfront, Partial, No Upfront

Как AWS прилага отстъпките

Ето нещо, което много хора не осъзнават веднага — редът на прилагане има значение. AWS първо прилага отстъпките от Reserved Instances, след това от EC2 Instance Savings Plans, после от Compute Savings Plans и чак накрая начислява On-Demand тарифи за остатъка. Разбирането на тази йерархия е ключово за правилното планиране.

# Пример: Проверка на покритието чрез AWS CLI
# Преглед на текущото използване на Savings Plans
aws savingsplans describe-savings-plans-utilization \
  --time-period Start=2026-03-01,End=2026-03-07 \
  --output table

# Преглед на текущото покритие на Reserved Instances
aws ce get-reservation-utilization \
  --time-period Start=2026-03-01,End=2026-03-07 \
  --output table

# Получаване на препоръки за Savings Plans
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT \
  --lookback-period-in-days SIXTY_DAYS

Промени в политиката на AWS за 2025-2026

Тук нещата стават интересни. Има няколко важни промени, за които трябва да знаете:

  • Януари 2024 г. — AWS забрани на клиенти от Enterprise Discount Program (EDP) да продават дисконтирани RI на Marketplace. Ако разчитахте на тази опция — съжалявам, вече не е налична.
  • Юни 2025 г. — AWS ограничи RI и SP до „единен краен клиент". Доставчиците на управлявани услуги (MSP) и дистрибуторите вече не могат да споделят RI и SP между различни крайни клиенти в рамките на една организация.

Добрата новина? Тези промени засягат основно MSP и дистрибуторите. Ако сте стандартна организация, която споделя RI/SP в рамките на собствената си консолидирана фактурна група — нищо не се променя за вас.

Azure: Reserved Instances срещу Savings Plans

Azure Reserved Instances

Azure Reserved VM Instances предлагат отстъпка до 72% в сравнение с pay-as-you-go цени при ангажимент за 1 или 3 години (а за някои услуги — и 5 години). Като при AWS, изискват конкретен тип VM, размер и регион.

Но ето една ключова разлика спрямо AWS, която обичам при Azure: предлагат еднакви отстъпки независимо дали плащането е изцяло предварително или на месечни вноски. При AWS колкото повече платите предварително, толкова по-голяма е отстъпката. При Azure — няма значение. Комбинирането с Azure Hybrid Benefit може да увеличи спестяванията до 80%.

Azure Savings Plans

Azure Savings Plans for Compute предлагат отстъпка до 65% при ангажимент за фиксиран почасов разход за 1 или 3 години. Отстъпките се прилагат автоматично за всички допустими compute услуги, независимо от размера на инстанцията, ОС или регион.

Едно важно ограничение, което трябва да имате предвид: Azure Savings Plans не могат да бъдат модифицирани или отменени. Неизползваният капацитет просто се губи. Така че внимавайте с размера на ангажимента.

Сравнителна таблица: Azure

ХарактеристикаAzure Reserved InstancesAzure Savings Plans
Максимална отстъпкаДо 72%До 65%
Тип ангажиментКонкретен VM тип/размер/регионФиксиран почасов разход ($/час)
ГъвкавостНискаВисока
ОтмянаОграничени опцииНе може
Hybrid BenefitДа (до 80% комбинирано)Да
 
# Azure CLI: Преглед на препоръки за резервации
az consumption reservation recommendation list \
  --scope Shared \
  --look-back-period Last60Days \
  --resource-type VirtualMachines

# Преглед на текущите резервации
az reservations reservation-order list --output table

# Azure Cost Management: Анализ на спестяванията от резервации
az costmanagement query \
  --type Usage \
  --timeframe MonthToDate \
  --dataset-filter "{\"dimensions\":{\"name\":\"PricingModel\",\"operator\":\"In\",\"values\":[\"Reservation\"]}}"

Google Cloud: Committed Use Discounts (CUD)

GCP използва малко по-различна терминология, но по принцип концепцията е сходна. Предлагат се два типа ангажименти:

  • Resource-Based CUD — ангажимент за конкретни ресурси (vCPU, памет, GPU) в определен регион. Предлагат по-висока отстъпка.
  • Spend-Based CUD — ангажимент за фиксиран почасов разход, подобно на AWS Compute Savings Plans. Предлагат отстъпка до 55% за 3-годишен ангажимент.

GCP има и един приятен бонус — Sustained Use Discounts (SUD). Това са автоматични отстъпки за ресурси, използвани повече от 25% от месеца. Не се изисква ангажимент, просто се прилагат автоматично. Удобно, нали?

# gcloud CLI: Преглед на текущите ангажименти
gcloud compute commitments list --format="table(name,region,status,plan,startTimestamp,endTimestamp)"

# Създаване на Resource-Based CUD за 1 година
gcloud compute commitments create my-commitment \
  --region=europe-west1 \
  --resources=vcpu=16,memory=64GB \
  --plan=twelve-month

# Преглед на препоръки за ангажименти от Recommender API
gcloud recommender recommendations list \
  --project=my-project \
  --location=europe-west1 \
  --recommender=google.compute.commitment.UsageCommitmentRecommender \
  --format="table(name,description,primaryImpact.costProjection)"

Мулти-облачно сравнение: Обща таблица

Нека видим как трите доставчика се сравняват директно — ето една таблица, която спестява доста четене:

ХарактеристикаAWS RI / SPAzure RI / SPGCP CUD
Макс. отстъпка (RI/резервация)72%72%~55% (Resource CUD)
Макс. отстъпка (SP/гъвкав план)66-72%65%~55% (Spend CUD)
Срок1 или 3 години1, 3 или 5 години1 или 3 години
Автоматични отстъпкиНеНеДа (SUD)
Marketplace за препродажбаДа (Standard RI)НеНе
Влияние на метода на плащанеДа (повече upfront = повече отстъпка)Не (еднаква отстъпка)Не

Практическа стратегия: Как да комбинирате RI и SP

Добре, стигнахме до най-важната част. Най-добрите FinOps практики през 2026 г. препоръчват многослоен подход и от моя опит — той наистина работи.

Стъпка 1: Оразмерете преди да се ангажирате

Това е може би най-важният съвет в цялата статия. Преди да закупите RI или SP, задължително направете right-sizing на инфраструктурата си.

Защо? Ако се ангажирате с голям Savings Plan и после намалите EC2 флота си, ще плащате за капацитет, който не използвате — в продължение на 1-3 години. Не е приятна ситуация. Правилната последователност е: Right-size → след това се ангажирайте с новия, по-нисък baseline.

Стъпка 2: Ангажирайте се консервативно

Ангажирайте се с 80% от минималното си потребление, а не от средното. Останалите 20% оставете на On-Demand цени. Да, губите малко от потенциалната отстъпка, но печелите гъвкавост — и спокойствие.

Стъпка 3: Наслоете ангажиментите

Тук идва истинската магия. Комбинирайте различните типове за максимална ефективност:

  1. Слой 1 — Базова линия с EC2 Instance Savings Plans (или RI за Azure/GCP): Покрийте 50-60% от стабилното натоварване с ангажимент, носещ до 72% отстъпка.
  2. Слой 2 — Compute Savings Plans за вариращо натоварване: Покрийте допълнителни 20-30% с по-гъвкав ангажимент, носещ до 66% отстъпка.
  3. Слой 3 — Спот инстанции за толерантни към прекъсвания задачи: Използвайте спот инстанции за batch обработка, CI/CD и тестови среди.
  4. Слой 4 — On-Demand за остатъка: Оставете 10-20% на On-Demand за неочаквани натоварвания и бързо мащабиране.
# Terraform пример: Закупуване на EC2 Instance Savings Plan
resource "aws_savingsplans_savings_plan" "ec2_baseline" {
  savings_plan_offering_id = data.aws_savingsplans_offering.ec2_sp.offering_id
  commitment               = "10.00"  # $/час
  term                     = "ONE_YEAR"
  payment_option           = "PARTIAL_UPFRONT"

  tags = {
    Environment = "production"
    ManagedBy   = "finops-team"
    Strategy    = "layer-1-baseline"
  }
}

# Terraform пример: Azure Reservation
resource "azurerm_consumption_budget_reservation" "vm_ri" {
  name             = "prod-d4sv5-westeurope"
  reservation_type = "VirtualMachines"
  sku              = "Standard_D4s_v5"
  location         = "westeurope"
  term             = "P1Y"
  quantity         = 10

  tags = {
    environment = "production"
    managed_by  = "finops-team"
  }
}

Стъпка 4: Използвайте RI за бази данни

Това е нещо, което мнозина пропускат. AWS Savings Plans не покриват RDS, ElastiCache или Redshift в достатъчна степен (новите Database Savings Plans дават едва 35% отстъпка). За бази данни използвайте Reserved Instances — те предлагат до 72% отстъпка. Разликата е огромна.

Стъпка 5: Мониторинг и оптимизация

Не купувайте RI/SP и не ги забравяйте. Редовно проверявайте утилизацията на ангажиментите си — целта е над 80%. Инструменти като AWS Cost Explorer, Azure Cost Management и GCP Billing Reports предлагат вградени препоръки, така че нямате оправдание да не го правите.

Кога да изберете Reserved Instances

RI имат смисъл в следните ситуации:

  • Имате стабилни, предвидими натоварвания, които няма да се променят в следващите 1-3 години
  • Искате резервация на капацитет (гаранция, че инстанциите ще са налични)
  • Планирате да използвате AWS RI Marketplace за препродажба при промяна на нуждите
  • Основните ви разходи са за бази данни (RDS, ElastiCache, Redshift)
  • Работите с конкретна фамилия инстанции и регион без планове за миграция

Кога да изберете Savings Plans

А Savings Plans са по-подходящи, когато:

  • Натоварванията ви се променят — мигрирате към контейнери, serverless или нови типове инстанции
  • Използвате множество AWS услуги (EC2, Fargate, Lambda)
  • Искате по-проста администрация без постоянно следене на конкретни конфигурации
  • Организацията ви е в процес на модернизация и архитектурните промени са чести
  • Предпочитате гъвкавост пред максимална отстъпка

Често допускани грешки

Виждал съм тези грешки отново и отново — опитайте се да ги избегнете:

  1. Прекомерен ангажимент: Закупуване на RI/SP за средното потребление вместо за минималното. Ако намалите ресурсите си, ще плащате за неизползван ангажимент месеци наред.
  2. Липса на right-sizing преди ангажимент: Ангажимент за преоразмерени инстанции означава, че плащате по-малко за нещо, от което изобщо не се нуждаете. Да, спестявате процент, но хвърляте пари.
  3. Игнориране на Convertible RI: Много екипи избират само Standard RI заради по-голямата отстъпка. Разбираемо е, но не отчитат риска от архитектурни промени — а те се случват по-често, отколкото очаквате.
  4. Неизползване на многослоен подход: Разчитане само на един тип ангажимент вместо комбиниране на RI, SP и спот инстанции. Балансът е ключов.
  5. Забравяне на бази данни: Savings Plans не покриват напълно RDS. Използвайте отделни RI за бази данни — повярвайте ми, разликата от 35% срещу 72% отстъпка си заслужава допълнителното усилие.

Често задавани въпроси

Каква е разликата между Savings Plans и Reserved Instances?

Накратко: Reserved Instances изискват ангажимент за конкретна конфигурация (тип инстанция, регион, ОС), докато Savings Plans изискват ангажимент за фиксиран почасов разход. Savings Plans са по-гъвкави — отстъпката се прилага автоматично дори при смяна на типа инстанция или услугата. Но RI предлагат допълнителни предимства като резервация на капацитет и възможност за препродажба.

Мога ли да използвам Savings Plans и Reserved Instances едновременно?

Да, и всъщност точно това е препоръчителната стратегия. AWS прилага първо отстъпките от RI, след това от EC2 Instance SP, и накрая от Compute SP. Така можете да използвате RI за стабилния baseline и SP за вариращото натоварване, за да постигнете максимално покритие.

Какво става ако не използвам пълния ангажимент по Savings Plan?

Плащате пълния ангажиран почасов разход, независимо дали го използвате — тук няма изненади. Затова е толкова критично да се ангажирате с 80% от минималното, а не средното потребление. При AWS неизползваният SP не може да бъде препродаден (за разлика от Standard RI).

Кои облачни услуги не се покриват от Savings Plans?

При AWS, Savings Plans не покриват напълно RDS, ElastiCache и Redshift (Database SP предлагат само 35% отстъпка, докато RI за тези услуги дават до 72%). Storage, мрежови разходи и повечето managed услуги не се покриват от нито един ангажимент. При Azure, Savings Plans покриват единствено compute разходи.

Как промените в политиката на AWS от 2025 г. влияят на моята организация?

Ако сте стандартна организация, използваща RI/SP в рамките на собствената си консолидирана фактурна група — може да си отдъхнете, промените не ви засягат. Те влияят основно на MSP и дистрибутори, които споделяха RI/SP между различни крайни клиенти. Единственото нещо, което може да ви засегне, е ограничението за продажба на дисконтирани RI на Marketplace, ако сте EDP клиент.

За Автора Editorial Team

Our team of expert writers and editors.

Свързани Статии

Стратегии и най-добри практики

Оптимизация на разходите за облачно съхранение: Lifecycle Policies за AWS S3, Azure Blob и GCP Cloud Storage (2026)

Научете как да намалите разходите за облачно съхранение с 40–80% чрез lifecycle policies при AWS S3, Azure Blob Storage и GCP Cloud Storage. Практическо ръководство с работещи конфигурации и Terraform примери за 2026 г.

Editorial Team 14 мин четене
Стратегии и най-добри практики

Тагване на облачни ресурси за Cost Allocation: Ръководство за AWS, Azure и GCP (2026)

Научете как да изградите и автоматизирате стратегия за тагване на облачни ресурси и cost allocation в AWS, Azure и GCP. Практическо ръководство с Terraform, SCP, Azure Policy и BigQuery примери за 2026.

Editorial Team 18 мин четене
Стратегии и най-добри практики

Спот инстанции в AWS, Azure и GCP: Как да спестите до 90% от облачните разходи

Практическо ръководство за спот инстанции в AWS, Azure и GCP с Terraform примери, Kubernetes конфигурации за EKS/AKS/GKE и стратегии за управление на прекъсванията. Спестете до 90% от облачните разходи.

Editorial Team 12 мин четене