Оптимізація хмарних витрат на AWS

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

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

Чому рахунки AWS виходять з-під контролю

AWS максимально спрощує запуск ресурсів. Потрібен новий сервер? Один клік. Більше сховища? Готово за секунди. Ця зручність чудово підходить для швидкості, але погано позначається на контролі витрат. Інженери виділяють те, що потрібно просто зараз, і забувають про це.

З часом проблема наростає. Тестові середовища, якими вже ніхто не користується, продовжують працювати. Розробники піднімають потужні інстанси для експериментів і ніколи їх не зменшують. Старі снепшоти та резервні копії осідають в S3. І ось ви вже платите за сотні ресурсів, які нікому не потрібні.

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

Починаємо з прозорості

Оптимізувати те, чого не бачиш, неможливо. Перший крок – зрозуміти, куди йдуть гроші. AWS Cost Explorer дає базову картину, але потрібно копати глибше. Тегуйте всі ресурси послідовно, щоб відстежувати витрати за командами, проєктами або середовищами.

Більшість компаній виявляють, що значна частина рахунку припадає на ресурси, про існування яких ніхто й не здогадувався. Осиротілі томи, прикріплені до вимкнених інстансів. Load balancer’и, що маршрутизують трафік у нікуди. NAT-шлюзи в регіонах, де нічого не запущено. Лише прибирання очевидного «сміття» може скоротити витрати на 10-15%.

Налаштуйте сповіщення про незвичні патерни витрат. Якщо рахунок за ніч злетів на 30%, ви хочете дізнатися про це негайно, а не за три тижні. CloudWatch може надсилати сповіщення при перевищенні порогових значень, даючи шанс розібратися в проблемі до того, як вона стане дійсно дорогою.

Reserved Instances та Savings Plans

Якщо ваші навантаження працюють цілодобово, платити за тарифами on-demand просто марнотратно. Reserved Instances та Savings Plans пропонують суттєві знижки – до 72% – в обмін на зобов’язання використовувати ресурси протягом одного або трьох років.

Головна умова тут – зобов’язання. Потрібно чітко розуміти свій базовий рівень використання. Починайте консервативно: зарезервованими інстансами покривайте стабільне навантаження, а on-demand залишайте для пікового трафіку.

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

Spot Instances для відповідних навантажень

Spot Instances – це незадіяні потужності AWS, що продаються з великою знижкою, зазвичай 70-90% від ціни on-demand. Компроміс у тому, що AWS може відкликати їх із попередженням за дві хвилини. Для правильних навантажень це цілком прийнятна угода.

Пакетна обробка, аналіз даних, CI/CD-пайплайни та рендеринг чудово працюють на Spot. Такі задачі легко переживають переривання і можуть перезапускатися. Запустіть їх на Spot, і витрати на обчислення впадуть суттєво без жодних реальних втрат.

Навіть stateful-додатки можуть використовувати Spot, якщо підійти до цього розумно. Поєднуйте Spot з on-demand в auto-scaling групі: Spot для основної частини потужностей, on-demand як страховка на випадок відкликання. Такий гібридний підхід значно скорочує витрати, зберігаючи при цьому надійність.

Оптимізація сховища, яка справді має значення

Витрати на сховище підкрадаються непомітно, бо ціна за гігабайт виглядає мізерною. Але помножте її на терабайти даних, що щомісяця зростають, і сховище стає вагомою статтею витрат.

Почніть із класів сховища S3. Більшість компаній зберігає все в S3 Standard і більше не повертається до цього питання. Перенесіть дані, до яких рідко звертаються, у S3 Standard-IA або Glacier. Налаштуйте lifecycle-політики для автоматичного переміщення об’єктів у міру старіння.

EBS-томи – ще одна точка економії. Надмірно виділені томи щодня витрачають гроші даремно. Якщо ви створили томи на 500 ГБ, а використовуєте лише 100, зменшіть їх. Переходьте з GP2 на GP3: вони дешевші й дозволяють виділяти IOPS незалежно від розміру.

Агресивно видаляйте снепшоти. Автоматизовані системи резервного копіювання безперервно їх створюють, але ніхто ніколи не видаляє старі. Залишайте лише те, що потрібне для комплаєнсу та відновлення після збоїв, усе інше – під видалення.

Мережеві витрати, які ховаються на видному місці

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

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

VPC endpoints усувають плату за передачу даних для сервісів AWS. Замість того щоб трафік виходив у відкритий інтернет і повертався назад, він залишається всередині мережі AWS. Налаштуйте endpoints для S3, DynamoDB та інших сервісів, якими активно користуєтеся.

Висновок

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

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