Оптимізуємо витрати в AWS

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Вітаю! Я Володимир, DevOps Team Lead в Alpacked. Незалежно від того, наскільки ефективно ми економимо, завжди наступає момент, коли клієнт просить знайти ще більше можливостей для оптимізації витрат. Іноді для нього це важливіше, ніж будь-які технічні досягнення.

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

Reserved Instances

Reserved Instances — це, мабуть, перше, що спадає на думку, коли мова заходить за економію грошей. Reserved Instances бувають двох типів (більше інформації в офіційній документації).

Standard RIs

1. Ви можете отримати аж до 72% знижки в порівнянні зі звичайними інстансами On-Demand.
2. Привʼязуються до конкретного регіону та instance type.
3. Дозволяють запускати різні instance type в межах однієї Instance family (купивши 10 штук c6g.xlarge, можна також запустити 20 штук c6g.large).

Convertible RIs

1. Менша знижка (до 54%) але більше можливостей.
2. Завжди можна змінити instance type, family, os.

Всі ці великі знижки отримуються, якщо ви одразу платите за 3 роки, на практиці ж клієнти не хочуть нічого платити наперед, і обирається No Upfront (де не треба нічого платити) план зі знижкою в ±30%.

Давайте я наведу приклад для інстансу c6a.xlarge в регіоні us-east-1. Для порівняння, ось ціни (на зображенні я рахую процент від on-demand ціни):

• On-Demand ціна: 0,153$/h;
• Spot ціна: 0,076$/h.

Тож, обравши по мінімуму 12 місяців, Standard клас, з No Upfront планом — ми отримаємо 0.101$/h що є знижкою в 34% в порівнянні з On-Demand ціною. Але зверніть увагу, що обравши Spot, ви отримуєте ще більшу знижку в розмірі 50% (про споти ми поговоримо трішки пізніше).

Додаткові рекомендації:

1. Порахуйте всі інстанси on-demand та їх типи, які ви використовуєте у кожному регіоні. Це допоможе зрозуміти, які саме RIs вам треба купити.
2. Визначтесь з instance family (c5, c6, r6i...) які у вас використовуються (наприклад, c6a.xlarge та c6a.4xlarge — це одна і та ж family).
3. Продавайте RIs, якщо вони вам не потрібні.
4. Краще взяти вісім штук c6a.large, ніж одну штуку 4xlarge (швидше продасте).
5. Активно моніторте Reservations utilization report в Billing and Cost Management.

Savings Plans

Savings Plans — схожий на Reserved Instances, але є одна відмінність: ви не можете продати план, який купили на рік. Також є два типи.

Compute Savings Plans

1. Можна отримати до 66% знижки (знову ж таки, залежить від деяких факторів).
2. Дозволяють використовувати будь-які EC2-інстанси, незалежно від регіону та instance type.
3. Позиціюють себе як максимальна свобода.
4. Оплата відбувається за $/h.

EC2 Instance Savings Plans

1. Знижки до 72%.
2. Прив’язані до конкретного instance family у певному регіоні (це ж Reserved Instances, ні?).
3. Позиціюють себе як рішення для стабільних навантажень.

Якщо з другим типом все більш менш зрозуміло (але я все одно наведу приклад), то з першим, compute — ні.

Щоб трішки прояснити, треба відкрити Billing and Cost Management -> Savings Plans -> Recommendations та подивитись що нам рекомендує Amazon.

В моєму випадку, якщо я закомічу $7,892/h, то отримаю аж 19% знижки, плюс не зможу це скасувати цілий рік. Дуже апетитно (ні). Звичайно, якщо вибрати три роки, All upfront, то знижка буде значно більшою, але камон, зараз все так швидко змінюється, що через пів року може бути інша картина, і ви будете просто так платити Amazon (було таке декілька разів).

З EC2 Instance Savings Plans більш адекватно, за той же c6a, але в Франкфурті та лише за $0,216/h ми отримаємо аж 32% знижки, що ± теж саме, як Reserved Instances

Як на мене, краще обрати RIs та отримати ± ті ж самі знижки, з можливістю продати в будь-який момент часу.

Spot Instances

Spot Instances — це самий сік, найдешевші, не треба нічого купувати, платиш лише за реальне використання як і on-demand (але так, з невеликими обмеженнями).

Ось вам ключові особливості в порівнянні з on-demand (взяв з офіційної документації):

Якщо взяти за основу той же c6a.xlarge інстанс в регіоні us-east-1, то побачимо, що пропонується знижка в 45-50%:

Переваги:

1. Велика економія. Низькі ціни які дозволяють суттєво знизити витрати на інстанси (обіцяють знижки аж до 90%, Ris та Saving plans до таких показників далеко.).
2. Гнучкість. Ідеально підходять для stateless та non-critical-застосунків, які можуть бути перервані та відновлені без значного впливу на робочий процес.

Недоліки:

1. Непередбачуваність. Через можливість припинення роботи інстансів потрібно бути готовим до термінейта в будь-який момент.
2. Палки в колеса. Недостатня кількість instance type в конкретній availability zone (більше інфи).

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

Уявімо ситуацію, у вас EKS кластер у якого є ASG зі spot-інстансами. В рандомний момент приходить AWS і каже — «мені потрібна твій одяг (інстанс)», і починається термінейт-процес. Кінець...

Що можна зробити, щоб максимально захистити себе від несподіваних термінейтів (якщо у вас cluster-autoscaler):

1. В ASG прописати декілька instance type (c5.xlarge, c5a.xlarge, c5d.xlarge). Це робиться для випадку, якщо в Amazon закінчиться один тип. Тоді ASG зможе підняти інстанс з іншим типом.
2. Встановити AWS Node Termination Handler, який моніторить статус-ноди, та запускає drain-ноди, яка буде скоро видалена, щоб поди могли нормально завершити свою роботу.

Якщо у вас Karpenter, то взагалі нічого робити не треба, він сам це контролює (якщо ви все правильно налаштували).

Інструменти оптимізації бюджетів в AWS

Їх багато: Cost Explorer, Budgets, Trusted Advisor, Compute Optimizer, Pricing Calculator, Cost Anomaly Detection, Service Catalog.

AWS Cost Explorer (аналіз та візуалізація витрат):

• Візуалізує витрати через графіки та звіти за різними критеріями: сервіси, акаунти, регіони.
• Аналізує зміни витрат з часом для розуміння динаміки використання ресурсів.
• Прогнозує майбутні витрати на основі поточних даних.

AWS Budgets (дозволяє створювати та керувати бюджетами):

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

AWS Trusted Advisor (рекомендації щодо покращення використання ресурсів, продуктивності та безпеки):

• Надає рекомендації щодо оптимізації витрат, таких як використання Reserved Instances або Spot Instances.
• Пропонує поради щодо підвищення продуктивності інфраструктури.
• Дає рекомендації для покращення безпеки ресурсів та забезпечення безперебійної роботи систем.
• Моніторить використання сервісів і попереджає про наближення до встановлених лімітів.

AWS Compute Optimizer (аналіз використання ресурсів та рекомендації для оптимізації):

• Рекомендує найкращі instance type на основі їх продуктивності.
• Виявляє недовикористані ресурси, які можна зменшити або видалити для зниження витрат.
• Аналізує продуктивність ресурсів і пропонує шляхи її покращення.

Мені, наприклад, вистачає Cost Explorer, щоб продивитись витрати, проаналізувати рекомендації, та зробити припущення, як можна оптимізувати інфраструктуру так, щоб зекономити клієнту (трохи) більше грошей. Також періодично дивлюсь на Total forecasted cost for current month, щоб помітити момент, коли щось йде не так.

Поради для оптимізації витрат в AWS

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

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

     

   • За що саме ми платимо в Data Transfer:

     

   • Або, за які instance family ми платили три місяці тому:

     

2. Думайте про кост-оптимізацію на початку створення інфраструктури, це допоможе вам зекономити багато часу в майбутньому.
3. CloudWatch може коштувати набагато більше, ніж ви того очікуєте, особливо коли у вас увімкнені audit, access-логи, та багато метрик.
4. По можливості створюйте VPC Private Links, іноді це може зберегти багато грошей на трафіку всередині регіону. Особливо, коли у вас ElasticSearch і ви робите бекапи на S3, який знаходиться в тому ж регіоні.
5. Якщо можна скейлити вниз нонпродові оточення в неробочі часи — робіть це.
6. Іноді не має сенсу тримати великі database instance type на нонпродах, бо не має такого навантаження, як на продах.
7. Якщо вам треба написати тікет в сапорт — ви завжди можете змінити сапорт-план на потрібний, і не платити за нього місяцями просто так.
8. Використовуйте Lifecycle Rules всюди — S3, ECR, Snapshots, etc, щоб контролювати кількість ресурсів та не платити за ті, що вже давно не актуальні. Нащо вам імейджі в ECR за 2021 рік? :)
   • АЛЕ, якщо у вас S3-бакет з access, audit, cloudtrail-логами, та ви думаєте про Glacier Flexible Retrieval storage class — то краще не треба. Чому? Тому що коли ви надумаєте видалити цей бакет, заплатите Amazon не одну тисячу доларів.

     

9. Старі та непотрібні KMS ключі витрачають гроші (це помітно, коли їх багато). Іноді їх страшно видаляти, бо виявиться, що якийсь ресурс їх використовує (а ви не можете швидко перевірити, які ключі використовуються, а які — ні).
10. Аналізуйте різні instance type, іноді за ті ж гроші (або навіть дешевше) можна взяти більше Memory.

    

11. Перевіряйте Spot-ціну в кожній AZ, іноді вигідніше взяти RIs:

    

12. Requests/Limits застосунків в кубері можуть бути неадекватними. Аналізуйте метрики, іноді це може зменшити кількість воркер-нод в декілька разів:

    

    

13. Скільки б ви не робили кост-оптимізацію — клієнт все одно прийде та попросить зекономити більше грошей.

До речі, наостанок покажу реальний приклад кост-оптимізації одного з клієнтів. Одразу скажу, що я дуже пишаюсь цим прикладом, бо цей проєкт (на мою думку) був найкращим з погляду економії і багато чого вдалось покращити. Тож, до оптимізації:

Та після:

Висновок

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

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

Головне — постійно прагнути до оптимізації, адже навіть невеликі поліпшення можуть мати значний вплив на рахунок AWS за наступний місяць.

Post Disclaimer: Я хотів би підкреслити, що рекомендації та приклади, подані у цій статті, не є універсальними рішеннями та повністю залежать від конкретних обставин проєкту. Все, що я написав, є результатом мого багаторічного досвіду та випробувань. Тепер моя черга почитати ваші рекомендації в коментарях :)

Дякую!