Як знизити витрати на AWS: RI та Savings Plans на практиці

Чому рахунок за хмару зростає за стабільного навантаження

Рахунок за хмару зростає не тому, що зросло навантаження, — платформа за замовчуванням продає все за фактом споживання.

В AWS інстанси та диски тарифікуються як разове споживання: це чесно для піків, але за постійного, рівномірного навантаження ви щогодини платите максимальну ставку. Розрив між такою ставкою та резервуванням закривається не інженерним рішенням, а зобов’язанням на строк.

Друге джерело переплати — відсутність покриття резервами. Нові сервіси запускаються, і ніхто не звіряє їх із уже придбаними зобов’язаннями: частина парку йде за зниженою ставкою, а поруч працюють такі самі інстанси за повною.

Окрема історія — розкид ресурсів за регіонами та зонами доступності: однотипне навантаження купується за різними умовами, бо резерв в одному регіоні не покриває інший.

Reserved Instances закривають саме цей розрив: ви фіксуєте сімейство, розмір і регіон та отримуєте знижену ставку за зобов’язання. Savings Plans гнучкіші — покривають споживання незалежно від сімейства та регіону, але дають менший дисконт.

Сенс не в тому, щоб купити більше, а в тому, щоб покриття збіглося з реальним профілем навантаження.

Нижче розбираємо, як рахувати це покриття, де виникає переплата і як вибудувати процес, за якого зростання рахунку за хмару зупиняється за того самого навантаження.

Ефект резервування: що змінюється в рахунку та плануванні

Резервування знімає волатильність не з усього рахунку, а з тієї частини навантаження, яка повторюється з місяця в місяць.

У Amazon Web Services для цього є Reserved Instances і Savings Plans — різні механіки з однією логікою: зобов’язання на строк в обмін на ставку нижчу за оплату на вимогу. Ефект перевіряється за чотирма пунктами, і кожен видно в рахунку без складної аналітики.

• Покриття базового навантаження. Беремо мінімум споживання за довгий період — саме його закриває зобов’язання. Усе, що вище за базову лінію, залишається на оплаті на вимогу, тому резерв не перетворюється на баласт під час спаду активності.
• Зниження вартості години на покритому відрізку. Ставка години падає щодо оплати на вимогу — на практиці це діапазон 30–60%, і він проявляється на довгому вікні, а не за один місяць. Savings Plans дають ту саму логіку, але прив’язуються до обсягу споживання, а не до конкретного сімейства інстансів.
• Передбачуваність платежу. Фіксована погодинна плата за зобов’язання переводить змінну статтю в постійну: бюджет на обчислювальні ресурси планується від періоду до періоду, а не від факту.
• Стійкість до сезонних піків. Зобов’язання не обмежує масштабування — пік понад резерв закривається оплатою на вимогу, без перегляду домовленостей. Спад, навпаки, не залишає зайвих зобов’язань, якщо базову лінію брати за нижньою межею.
• Менше ручних розборів рахунку. Покрита частина перестає бути набором змінних рядків: розбіжність плану й факту видно в одному місці, звірка займає хвилини замість годин.

Критерій простий: якщо сходяться хоча б три пункти з чотирьох, покриття вибрано правильно. Переглядаємо його разом із розбором рахунку в міру зміни профілю навантаження — зазвичай раз на квартал.

Reserved Instances чи Savings Plans: що вибрати

Різниця між двома механіками — не в розмірі знижки, а в тому, що саме ви фіксуєте. Reserved Instances прив’язаний до сімейства екземплярів і регіону, а гнучкий план на обчислювальні ресурси покриває сумарний обсяг обчислень за годину незалежно від сімейства та регіону.

Другий рівень рішення — режим оплати. Навантаження зазвичай розкладають за кількома варіантами одразу: базу закривають резервом, а піки залишають на оплату за фактом, щоб не платити за невикористані години.

Обмеження резерву проявляються під час відхилення від прогнозу: невикористана година не переноситься на наступний період, а повернути аванс не можна.

Гнучкий план знімає прив’язку до сімейства, але прогноз обсягу все одно потрібен — за переоцінки покриття частина зарезервованого обсягу витрачається марно.

Тому варіанти порівнюють за фактичним споживанням за довгий період, а не за середнім завантаженням за тиждень: розбіжність у покритті між режимами стає помітною саме на горизонті кількох місяців.

Як ми впроваджуємо резервування: етапи інженерної роботи

Резервування окупається лише там, де зобов’язання прив’язані до реального профілю споживання — узяті «на око» Reserved Instances дають переплату за невикористані години. Тому впровадження ведемо як інженерний проєкт із фіксованими кроками та перевірюваним результатом на кожному.

1. Аудит рахунків і профілю навантаження — вивантажуємо деталізацію споживання за кілька місяців і розбираємо її за типами інстансів, регіонами, зонами та часом доби. Окремо позначаємо добові піки й разові навантаження: під них резерв не беруть.
2. Розрахунок частки покриття — рахуємо, яка частина навантаження стабільна і яку частку закривати зобов’язаннями. Частину залишаємо незарезервованою під зростання та піки.
3. Схема резервів — підбираємо комбінацію: жорсткі резерви під незмінні ресурси, гнучкі плани під те, що мігрує між сімействами та регіонами.
4. Налаштування й облік — застосовуємо резерви на рівні організації, розносимо за проєктами через теги та вмикаємо оповіщення про утилізацію, щоб команда бачила простоюючі зобов’язання.
5. Перевірка на модельних сценаріях — проганяємо зростання навантаження, зміну сімейства інстансів, відмову зони та сезонний спад. Де з’являється переплата, правимо схему до продакшену.
6. Передача документації — віддаємо команді замовника регламент: як резерви відображаються в рахунку, коли продовжувати, за якими метриками стежити за покриттям і що робити за зміни архітектури.

На виході зобов’язання прив’язані до реального споживання, а рішення про продовження та перегляд схеми ухвалюються за цифрами, а не за інтуїцією.

Політики покриття резервами та звітність щодо використання

Резерв окупається лише там, де збігається з фактичним профілем навантаження. Якщо покриття з’їхало вбік, частина резервів простоює, а найважча частина трафіку знову тарифікується на вимогу.

Тому разом із налаштуванням ми передаємо контур управління покриттям — набір документів, за якими ваша команда веде його далі самостійно. Нижче те, що залишається в замовника на руках.

• Схема покриття — які сімейства інстансів, регіони та типи резервів закривають яку частку базового навантаження, з розбивкою за сервісами й середовищами.
• Конфігурації резервів — перелік із параметрами: клас, платформа, строк, зона, варіант оплати та обґрунтування вибору кожного набору.
• Правила перегляду частки — цільове покриття, допустиме відхилення та тригери перегляду: зростання кількості вузлів, зміна сімейства, запуск нового сервісу.
• Звіт про використання — відсоток покриття, частка невикористаного резерву, динаміка за тижнями та розбіжність із цільовим значенням.
• Регламент реакції — хто і в який строк перераховує покриття за зміни навантаження, що вважається штатним, а що потребує переузгодження резервів.
• Відповідальні та періодичність — хто веде звіт, хто затверджує перегляд частки і як часто проводиться звірка з фактичним споживанням.

Документи тримаємо в репозиторії поруч з інфраструктурним кодом: новий інженер входить у тему за ними, а не за листуванням. Формат і глибину підганяємо під те, хто буде вести покриття — ваша команда чи ми на підтримці.

Кейс: як змінився рахунок після переходу на резерви

Клієнт — сервіс із вираженим добовим профілем: базове навантаження тримається рівно, піки припадають на короткі вікна.

Парк працював за моделлю «плати за фактом» в Amazon Web Services: зобов’язань не було, але платіж повторював профіль трафіку, а інженери вручну гасили й піднімали вузли перед кожним піком.

Що було і що змінили

Розібрали парк на два шари. Під базову частину зі стабільним профілем узяли резерви — Reserved Instances на весь горизонт планування, під навантаження з плаваючим споживанням — Savings Plans, залишок залишили «за фактом» під піки.

Зобов’язання рахували за метриками споживання за кілька місяців із запасом на зростання: перебрати — платити за простій, недобрати — втрачати знижку на найдорожчому шарі.

За квартал платіж перестав бути сюрпризом: базова частина перейшла в передбачуваний рядок бюджету, а гнучкість збереглася — зобов’язання покривають лише те навантаження, яке й так не змінювалося.

Клас відмов виду «забутий вузол, що розрісся вночі» зник разом із лімітами й алертами на бюджет, а час інженерів, що звільнився, пішов на оптимізацію застосунку, а не на ручне правлення парку.

Чим Reserved Instances відрізняються від оплати за фактом споживання

Оплата за фактом — погодинна тарифікація запущеного ресурсу: ставка залежить від регіону, сімейства й розміру інстанса, операційної системи та моделі тенантності.

Reserved Instances в AWS — це передплачене зобов’язання на рік або три: резервується не конкретна машина, а профіль ресурсу, і знижка до погодинної ставки тим вища, чим жорсткіша фіксація.

Зональний резерв прив’язаний до зони доступності та типу інстанса — поїхало навантаження в іншу зону, і оплачена година згоряє.

Регіональний м’якший: він діє в межах регіону й дає розмірну гнучкість усередині сімейства, коли один великий інстанс замінюється двома середніми без втрати покриття; конвертований допускає зміну сімейства та операційної системи.

Покриття рахується в нормалізованих одиницях: оплачені години зіставляються з фактичним споживанням за ту саму годину.

Дивитися потрібно на дві метрики — частка покриття показує, яка частина навантаження закрита резервом, утилізація — яка частина оплачених годин реально витрачена. Утилізація нижче 90% означає, що передплата частково пішла марно.

Гнучкість проти ціни розводять за шарами. Стандартний RI дає максимальну знижку, але майже не допускає змін; Savings Plans поступаються в розмірі знижки, зате ширші за сервісами, що покриваються, і не прив’язані до сімейства інстансів. Стабільне ядро вигідніше закривати жорстким резервом, різнорідні контури — гнучким планом.

Залишкове навантаження залишається погодинним. Резервом закривають базовий рівень, який працює цілодобово: веб-шар, базу даних, чергу.

Піки, нічні пакетні завдання та сезонні тестові контури дешевше тримати за фактом — передбачити їх не можна, а оплачений простій коштує дорожче за отриману знижку.

Часті технічні питання щодо резервування потужностей

Резервування потужностей впроваджують не заради самого резерву, а щоб зафіксувати нижню межу навантаження — ту, що тримається цілодобово.

Тому сумніви тут технічні: як поводитиметься резерв за зміни сімейства інстансів, як порахувати реальну частку покриття, куди дівається невикористаний залишок. Нижче — п’ять питань, які ставлять найчастіше.

Як рахується частка покриття?

Частка покриття — відношення годин, закритих резервом, до загальних годин роботи парку. Рахуємо її за кожним сімейством і регіоном окремо: усереднення за всім обліковим записом приховує перекіс, коли один сервіс перекритий майже повністю, а другий — ні.

Куди дівається невикористаний залишок?

Невитрачений залишок у кінці періоду не повертається й не переноситься. Тому цілимося в покриття базового навантаження, а пікові години закриваємо на вимогу — за спаду навантаження резерв не починає простоювати.

Скільки займає перехід і чи потрібна зупинка сервісів?

Зупинка не потрібна: резерв застосовується до вже працюючих інстансів, перестворювати парк або змінювати образи не потрібно. Зміни враховуються з початку наступної години, а відкат — це звичайна відмова від продовження.

Чи сумісне резервування з автомасштабуванням?

Сумісне, але резервом закриваємо лише стабільне ядро. Автомасштабування обслуговує піки вище ядра, резерв — базові години: разом це дає рівний рахунок і прибирає ризик простоюючих потужностей.

Обговоримо задачу: розберемо ваш профіль навантаження

Щоб оцінка спиралася на факти, а не на припущення, нам потрібен зріз того, як застосунок живе в AWS зараз. Ми зіставляємо фактичне споживання з графіком навантаження й шукаємо розрив: де ресурси простоюють, а де зарезервовано з надлишком. Нижче — що надіслати, щоб обговорення задачі одразу перейшло в план та оцінку.

• Вивантаження рахунків за 3–6 місяців у CSV: розбивка за сервісами, регіонами й типами інстансів, окремими рядками — резерви та Savings Plans.
• Схема сервісів: що з чим обмінюється даними, де зберігається стан, що масштабується автоматично, а що живе в одному екземплярі.
• Графік навантаження: добовий і тижневий профіль із піками й провалами, сезонні сплески, фонові завдання, які можна зсунути за часом.
• Вимоги до доступності: допустиме вікно простою, чи потрібна відмовостійкість за зонами, які сценарії деградації прийнятні.
• Обмеження за регіонами: де мають розташовуватися дані, які регіони вже задіяні, чи є вимоги до затримки відгуку.
• Чинні зобов’язання: які резерви та Savings Plans активні, на який строк і яку частку споживання покривають.

З цим набором ми рахуємо, яке покриття зобов’язаннями дає ефект без втрати гнучкості, і повертаємося з планом: що змінювати одразу, а що — у міру закінчення поточних строків.