AWS виставляє рахунок за on-demand цінами, доки ви не зафіксуєте зобов'язання. Reserved Instances (RI) та Savings Plans (SP) — механізм цієї фіксації. При правильному аналізі економія на EC2, RDS, Lambda становить 40–72% порівняно з on-demand. При неправильному — гроші заморожені в резервації, яка не використовується. Щомісячний рахунок за хмару може містити приховані резерви: типова компанія витрачає на 30–40% більше, ніж потрібно, через неоптимальне використання резервування. На одному з проєктів із щомісячним рахунком $50 000 ми знизили витрати до $25 000 після впровадження SP. Наша команда вже понад 5 років допомагає компаніям скорочувати хмарні витрати: понад 50 проєктів, середня економія 45%. Замовте аналіз вашого акаунта — оцінимо проєкт за 1 день.
Тому завдання не «купити RI», а «виявити стабільне базове навантаження і покрити його резерваціями, залишивши змінну частину на Spot або on-demand».
Reserved Instances та Savings Plans: ключові відмінності
Reserved Instances прив'язані до конкретного instance type, регіону (і опціонально — Availability Zone). Стандартні RI дають максимальну знижку, але не конвертуються. Convertible RI дозволяють змінювати instance family, OS, tenancy протягом терміну — корисно, якщо планується міграція на Graviton.
Savings Plans — більш гнучкий інструмент. Compute Savings Plans покривають EC2 (будь-який instance family, регіон, OS), Fargate та Lambda одним commitment у доларах на годину. EC2 Instance Savings Plans прив'язані до певного instance family в регіоні, але дають трохи більшу знижку.
Для більшості компаній зараз рекомендуємо Compute SP: гнучкість важливіша, особливо якщо планується перехід на Graviton або зміна instance types. Різниця в знижці між Compute та EC2 Instance SP — зазвичай 5–8%. Compute SP у 2 рази гнучкіший, ніж EC2 Instance SP, за рахунок покриття різних сервісів.
Як проаналізувати навантаження для Savings Plans?
Основний інструмент — AWS Cost Explorer з увімкненим Savings Plans Recommendations. Але рекомендації AWS за замовчуванням дивляться на останні 30 днів. Якщо останній місяць був нетиповим (свята, запуск маркетингової кампанії, навантажувальне тестування) — рекомендації будуть неточними.
Правильний підхід: аналізуємо 3–6 місяців історії. Будуємо percentile-розподіл споживання — p50 (медіана) — це приблизно те, що потрібно покрити резерваціями. Різниця між p50 та p90 — кандидат для Spot. Все вище p90 — on-demand або автоматичний scaling.
Базова нагрузка (p50) → Savings Plans / RI (1-year No Upfront)
Змінне навантаження (p50-p90) → Spot Instances + Spot Fleet
Піки (>p90) → On-demand (Auto Scaling)У Cost Explorer є ec2_instance_savings_plan_eligible_spend — дивимося цей показник у часі, а не добовий зріз.
Докладніше про процентилі
p50 — це значення, нижче якого лежить 50% спостережень. Наприклад, якщо за годину споживається 10 одиниць EC2, а наступної години — 20, то p50 = 15. Використовуйте p50 як базове навантаження для резервування. p90 — значення, нижче якого лежить 90% спостережень, його покривають Spot.Чому Compute Savings Plans часто вигідніші?
Вони покривають не лише EC2, а й Fargate, і Lambda. Якщо в архітектурі є контейнери або serverless, це дає єдиний підхід до оптимізації. Згідно з документацією AWS по Compute Savings Plans, одне зобов'язання покриває всі три сервіси, що спрощує управління. Для прикладу: компанія з 30% навантаження на ECS та 10% на Lambda може зекономити на всіх сервісах одним зобов'язанням, а не купувати окремі RI для різних типів інстансів.
Який варіант оплати обрати?
| Тип оплати | Додаткова знижка vs No Upfront | Коли вигідний |
|---|---|---|
| All Upfront | ~5% | При надлишку вільних коштів та стабільному навантаженні на 3 роки |
| Partial Upfront | ~2–3% | Компроміс: невелика економія без повної передоплати |
| No Upfront | базова | Оптимальний для більшості — гнучкість та відсутність капітальних витрат |
No Upfront — оптимальний для більшості випадків: немає прив'язки капіталу, при закритті акаунта або зміні архітектури втрати мінімальні.
Порівняння RI та SP
| Характеристика | Reserved Instances | Savings Plans |
|---|---|---|
| Гнучкість | Низька (прив'язка до instance type) | Висока (Compute SP покриває кілька сервісів) |
| Максимальна знижка | До 72% | До 72% (залежить від терміну та оплати) |
| Покриття | EC2, RDS, ElastiCache | EC2, Fargate, Lambda |
| Продаж на Marketplace | Так | Ні |
Термін: 1 рік vs 3 роки
1 рік — стандартний вибір. 3 роки дають ще більшу знижку (~15% зверху), але трирічний горизонт планування в cloud-інфраструктурі — рідкість. За три роки instance family може застаріти, регіон змінитися, архітектура зрушити в бік serverless.
Виняток — RDS RI для production баз даних. Якщо PostgreSQL або MySQL на RDS працює стабільно кілька років і планів по міграції немає — трирічний RI виправданий.
Покрокова інструкція: налаштування Savings Plans
- Зберіть дані: вивантажте Cost and Usage Reports за 3–6 місяців.
- Визначте базове навантаження: обчисліть p50 споживання EC2, Fargate, Lambda.
- Оберіть тип SP: Compute або EC2 Instance, виходячи зі стабільності навантаження.
- Оберіть термін та оплату: 1 рік, No Upfront для більшості.
- Придбайте SP через Console або AWS CLI.
- Налаштуйте алерти в Cost Explorer: сповіщення при coverage < 80%.
Що входить у нашу роботу з налаштування RI/SP
- Вивантаження та аналіз Cost and Usage Reports за 3–6 місяців
- Побудова рекомендацій з урахуванням фактичного utilization rate
- Оцінка невикористовуваних резервацій для продажу на Marketplace
- Оформлення покупки через Console або CLI
- Налаштування алертів для контролю coverage
- Документація щодо стратегії та план моніторингу
- Навчання команди роботі з Cost Explorer
- Підтримка при перегляді стратегії через 6 місяців
Орієнтовні терміни
Аналіз та підготовка рекомендацій — 1 день. Узгодження та покупка — ще півдня. Разом: 2–3 робочих дні з урахуванням ітерацій щодо обговорення стратегії з командою. Вартість розраховується індивідуально.
Хочете скоротити витрати на AWS на 40–72%? Замовте аналіз вашого акаунта — ми оцінимо проєкт за 1 день. Отримайте консультацію з оптимізації AWS-витрат прямо зараз.
