AWS Savings Plans vs RI: Гайд 2026

Оновлено: 5 червня 2026

Savings Plans і Reserved Instances: це два механізми знижок AWS за зобов'язання на 1 або 3 роки, які зменшують ціну on-demand на 27–72%. Якщо стисло, Compute Savings Plans майже завжди є кращим вибором за гнучкістю (працюють на EC2, Fargate, Lambda і змінюють регіон чи інстанс без обмежень), а Reserved Instances залишаються виправданими лише для RDS, ElastiCache, Redshift і OpenSearch, де Savings Plans поки не діють. У цьому посібнику я розкладу різницю по дев'яти параметрах, покажу реальні цифри з трьох рахунків, які скорочував у 2024–2026, і дам алгоритм покриття, який не залишить вас із простоюючим зобов'язанням.

Compute Savings Plans дають до 66% знижки і працюють для EC2, Fargate та Lambda без прив'язки до регіону чи сімейства інстансів.
EC2 Instance Savings Plans дають до 72% знижки, але блокують вас на конкретне сімейство в одному регіоні.
Reserved Instances у 2026 році актуальні лише для RDS, ElastiCache, Redshift, OpenSearch і DynamoDB (Reserved Capacity).
Точка беззбитковості 1-річного зобов'язання становить 7–8 місяців безперервного використання, 3-річного — приблизно 18 місяців.
Цільове покриття baseline становить 70–80%, не 100%: залиште місце для on-demand і Spot, інакше платитимете за простій.
Convertible RIs офіційно не deprecated, але AWS більше не рекомендує їх для нових покупок (Savings Plans мають той самий ефект і кращу ліквідність).

У чому різниця між Savings Plans і Reserved Instances?

Reserved Instance є зобов'язанням на конкретну конфігурацію (тип інстансу, ОС, регіон, тенантність) в обмін на знижку. Якщо ви купили m5.2xlarge Linux us-east-1, знижка застосовується тільки до інстансів, що відповідають цьому опису, або до інших розмірів того ж сімейства через instance size flexibility. Savings Plan натомість є зобов'язанням витрачати фіксовану суму на годину (наприклад, $12/год) на обчислення; AWS автоматично застосовує знижку до будь-якого Compute-споживання, що покривається планом, незалежно від типу інстансу, ОС чи регіону (для Compute SP).

Практична різниця, яку я бачу в кожному рахунку, проста: RI блокує архітектуру, а Savings Plan блокує бюджет. Якщо ви плануєте переходити з m5 на m7g (Graviton) у наступні 18 місяців, RI на m5 стане кулею в нозі: або платитимете повну ціну за m7g, або кисло використовуватимете старі інстанси, щоб не «спалити» зобов'язання. Compute Savings Plan покриє і те, і інше без жодного жесту з вашого боку. AWS офіційно називає Savings Plans «більш гнучкою моделлю ціноутворення», і це не маркетинг, а фактичний стан речей. Деталі типів описані в офіційній документації AWS Savings Plans.

Порівняльна таблиця: 9 параметрів вибору

Нижче наведено стиснений порівняльний фрейм, який я використовую на дзвінках з фінансовими директорами, коли треба за п'ять хвилин обґрунтувати, чому ми більше не купуємо Standard RIs.

Параметр	Compute Savings Plans	EC2 Instance SP	Standard Reserved Instances
Максимальна знижка	До 66%	До 72%	До 72%
Гнучкість регіону	Так, будь-який регіон	Ні, один регіон	Ні, один регіон
Зміна сімейства інстансів	Так (m5→c7g→r6i)	Ні, фіксоване сімейство	Ні, тільки розмір у сімействі
Покриває Fargate	Так	Ні	Ні
Покриває Lambda	Так	Ні	Ні
Покриває RDS/ElastiCache	Ні	Ні	Так (окремий RI)
Перепродаж на Marketplace	Ні	Ні	Так, Standard RI
Зобов'язання	$/год на 1 або 3 роки	$/год на 1 або 3 роки	Кількість інстансів × термін
Рекомендовано у 2026	За замовчуванням	Для стабільного GPU/HPC	Тільки для RDS-сімейства

Три типи Savings Plans і коли який брати

Отже, AWS пропонує три види Savings Plans, і вибір між ними важить більше, ніж вибір між SP і RI. Це Compute Savings Plans, EC2 Instance Savings Plans і SageMaker Savings Plans. У моїй практиці співвідношення в портфелі типового SaaS-клієнта складає приблизно 80/15/5 на користь Compute.

Compute Savings Plans (за замовчуванням)

Це найгнучкіший варіант. Зобов'язання у форматі «$X на годину» на 1 або 3 роки, з опціями оплати No Upfront, Partial Upfront і All Upfront. План покриває EC2 (включно з Windows і Bring-Your-Own-License), AWS Fargate і AWS Lambda. Навіть якщо ви мігруєте з EC2 на Fargate посеред терміну, знижка не зникає. У клієнта з річним рахунком $4.2M на EC2 ми витіснили 100% Standard RIs у Compute SP протягом 11 місяців і відразу заощадили ще $190K на тому, що тепер не довелося переплачувати за c7g-міграцію.

EC2 Instance Savings Plans (для дуже стабільного workload)

Дають на 6 п.п. більшу знижку, але вимагають фіксації сімейства інстансу і регіону. Беріть тільки тоді, коли в інстанс-сімействі лежить понад 60% вашого рахунку і ви впевнені, що архітектура не зміниться 12+ місяців. Класичний приклад: GPU-кластери на p4d чи p5, бо альтернативи на Graviton чи Inferentia ще не повністю замістили NVIDIA workload-и (детально про оптимізацію GPU-витрат я писав у матеріалі оптимізація витрат на GPU для AI/ML).

SageMaker Savings Plans

Покривають усі SageMaker-інстанси: Studio, Training, Processing, RealTime Inference, Asynchronous Inference. Якщо у вас ML-команда, що активно тренує моделі, і місячний SageMaker-рахунок перевищує $30K, цей план окупається за 3–4 місяці. Менше, ніж $30K на місяць? Беріть on-demand і моніторте через AWS Cost Explorer.

Коли Reserved Instances ще актуальні у 2026

Reserved Instances нікуди не зникли, бо Savings Plans не покривають базові керовані бази даних і кеші. У 2026 році я рекомендую розглядати RI лише для шести сервісів: Amazon RDS (включно з Aurora), ElastiCache (Redis і Memcached), Redshift, OpenSearch Service, DynamoDB Reserved Capacity і MemoryDB. Економія тут так само солідна: 30–60% на 1-річному no-upfront і 50–72% на 3-річному all-upfront.

Для RDS і Aurora врахуйте, що Reserved DB Instance прив'язаний до движка (PostgreSQL, MySQL, MariaDB, Oracle, SQL Server), класу інстансу і регіону. Якщо ви ще не на Graviton (db.r7g, db.m7g), спершу мігруйте, бо економія від Graviton додає ще 10–20% поверх RI, і її ніхто не відмінить. Я бачив рахунок, де ми зрізали $640K/рік просто комбінацією db.r5 у db.r7g плюс 3-year No Upfront RI.

Для DynamoDB Reserved Capacity ситуація особлива: воно покриває provisioned read/write capacity units, а не on-demand. Якщо ваш workload передбачуваний за RCU/WCU, RI окупається; якщо spiky, залишайтесь на on-demand і не торкайтеся RI. Офіційні нюанси описані в документації RDS Reserved DB Instances.

Розрахунок точки беззбитковості та реальна економія

Найчастіша помилка — купувати 3-річне All Upfront «бо знижка більша», без розрахунку точки беззбитковості. Чесно кажучи, я хапався за цей кейс щонайменше тричі в перші місяці у FinOps. Ось простий фреймворк, який я використовую перед кожним коммітом.

Формула: Break-even (місяців) = (Upfront + Discounted Hourly × 730 × Term) / (On-demand Hourly × 730)

Приклад на m6i.xlarge в us-east-1 (станом на травень 2026):

# On-demand: $0.192/год
# 1-year No Upfront Compute SP: $0.135/год (знижка 29.7%)
# 1-year All Upfront Compute SP: $0.117/год (знижка 39%) + $1024 upfront
# 3-year All Upfront Compute SP: $0.080/год (знижка 58.3%) + $2102 upfront

# Точка беззбитковості 1-year All Upfront:
# 1024 / (0.192 - 0.117) / 730 = 18.7 тижнів ≈ 4.3 місяця
# Тобто навіть якщо ви відключите інстанс через 5 місяців, ви все одно у плюсі.

# Точка беззбитковості 3-year All Upfront vs On-demand:
# (2102 + 0.080 × 730 × 36) / (0.192 × 730) = 17.8 місяців

Висновок, який підтвердився на двох десятках клієнтів: 1-year No Upfront окупається за 7–8 місяців безперервного використання, а 3-year за 17–19 місяців. Усе, що менше 18 місяців планованого життя сервісу, беріть на 1 рік, навіть якщо «3-year виглядає вигідніше». Гнучкість важливіша за зайві 5–10% знижки. Цей самий принцип ми застосовуємо при оптимізації витрат Kubernetes: комітити baseline, ходити в Spot для пікового навантаження.

Алгоритм покриття baseline 70/80

Цільове покриття зобов'язаннями становить 70–80% від стабільного baseline, а не 100% від загального використання. Ось як я це рахую за 30 хвилин у Cost Explorer.

Експортуйте 90 днів даних з Cost and Usage Report (CUR) у S3, а звідти в Athena або QuickSight.
Побудуйте годинний графік usage у normalized hours (NU); це нормалізована одиниця, яку AWS використовує для instance size flexibility.
Знайдіть 20-й перцентиль годинного використання, бо це ваш «безпечний baseline». Усе нижче цієї лінії гарантовано споживатиметься в наступному році.
Розрахуйте $/год для цього baseline за поточними on-demand цінами і помножте на 0.75 (це target commit для Compute Savings Plan).
Розбийте commit на дві покупки: 50% на 3-річний термін (захист найстабільнішої частини), 50% на 1-річний (буфер на випадок змін стратегії).
Решту 25–30% залишайте на on-demand і Spot. Це ваш простір для масштабування і для архітектурних експериментів.

Чи можна продати Savings Plan або скасувати зобов'язання?

Ні. Savings Plans неможливо продати, обміняти, скасувати чи перенести на інший AWS-акаунт поза вашою організацією. Standard Reserved Instances навпаки продаються на Reserved Instance Marketplace (тільки для акаунтів зі США з американською банківською адресою), з комісією AWS 12% від суми. Convertible RIs не продаються, але обмінюються на інші RI рівної або більшої вартості.

Це робить Savings Plans стратегічно ризикованішими для компаній, які можуть бути придбані або реструктуризовані: 3-річне зобов'язання на $50K/місяць означає $1.8M, які доведеться витратити, навіть якщо ви закриєте AWS-акаунт. Тому я не рекомендую брати 3-year All Upfront для проєктів зі строком життя меншим за 24 місяці або в умовах активного M&A.

Типові помилки, що з'їдають економію

За 7 років роботи з FinOps я бачив одні й ті ж граблі в кожному другому акаунті. Ось топ-5 і як їх обійти.

1. Покриття 100% замість 70–80%

Команди купують Savings Plan на весь поточний usage, забуваючи, що workload коливається. Через 3 місяці частина сервісів мігрує на serverless, частина вимикається, і ви платите за невикористовуваний commit. Утилізація падає до 85%, а ефективна знижка з 60% до 51%.

2. Ігнорування Graviton перед покупкою RI

Купити 3-year RDS RI на db.r5, а через місяць виявити, що db.r7g на 15% дешевший і на 20% швидший. Тепер у вас два варіанти: тримати застарілий клас 3 роки або жертвувати RI. Завжди мігруйте на Graviton ДО покупки RI, не після. (Я цей біль відчув на одному з рахунків клієнта в Берліні, і повірте, виправити постфактум було набагато дорожче, ніж зробити правильно з першого разу.)

3. Розкидання SP по linked-акаунтах

У AWS Organizations Savings Plans «течуть» між акаунтами через consolidated billing, але тільки якщо в payer-акаунті ввімкнено sharing. У 60% акаунтів, які я аудитував, sharing був вимкнений, і economy team з sandbox-акаунта «з'їдала» commit, призначений для production. Перевірте налаштування RI/SP sharing у AWS Organizations першим ділом.

4. Купівля 3-year All Upfront для стартапів

На посівній чи Series A стадії готівка важливіша за 5% додаткової знижки. Беріть 1-year No Upfront: гнучкіше, не висмоктує оборотний капітал, дозволяє pivotити архітектуру.

5. Відсутність моніторингу coverage і utilization

Налаштуйте AWS Budgets із сповіщеннями, коли coverage падає нижче 70% або utilization нижче 95%. Інакше дізнаєтесь про проблему лише в кінці кварталу, коли фінансовий контролер запитає, чому реальна знижка 38%, а не обіцяні 58%. Огляд автоматизованих сповіщень є в документації AWS Budgets.

Поширені запитання

Що краще: Savings Plans чи Reserved Instances у 2026 році?

Для EC2, Fargate і Lambda це Compute Savings Plans, без винятків. Для RDS, ElastiCache, Redshift, OpenSearch, DynamoDB Reserved Capacity і MemoryDB це Reserved Instances, бо Savings Plans на ці сервіси не поширюються. Convertible RIs у 2026 році практично втратили сенс.

Чи можна продати Savings Plan, якщо він більше не потрібен?

Ні. Savings Plans не продаються, не обмінюються і не скасовуються. Тільки Standard Reserved Instances можна перепродати на AWS RI Marketplace (доступно для акаунтів зі США з американською банківською адресою) з комісією AWS 12%.

Яка реальна економія від 3-річного Savings Plan?

3-year All Upfront Compute Savings Plan дає 50–58% знижки на типові інстанси (m6i, c6i, r6i) і до 66% на Graviton (m7g, c7g). Точка беззбитковості порівняно з on-demand становить приблизно 18 місяців, тому брати варто лише для workload-ів зі строком життя 24+ місяці.

Чи покривають Savings Plans GPU-інстанси типу p4d і p5?

Так, Compute Savings Plans покривають усі EC2-інстанси, включно з p4d, p5 і g5. Для дуже стабільного GPU-workload розгляньте EC2 Instance Savings Plans, бо вони дають додаткові 6 п.п. знижки, але блокують вас на конкретне сімейство і регіон.

Як уникнути ситуації, коли Savings Plan не використовується повністю?

Купуйте commit на рівні 70–80% від 20-го перцентиля годинного використання за останні 90 днів. Розбивайте покупку на 50% 3-year і 50% 1-year, увімкніть RI/SP sharing у AWS Organizations і моніторте utilization через AWS Budgets із порогом сповіщення 95%.