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

Усі статті, обговорення, новини про DevOps — в одному місці. Підписуйтеся на DOU | 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: Я хотів би підкреслити, що рекомендації та приклади, подані у цій статті, не є універсальними рішеннями та повністю залежать від конкретних обставин проєкту. Все, що я написав, є результатом мого багаторічного досвіду та випробувань. Тепер моя черга почитати ваші рекомендації в коментарях :)

Дякую!

👍ПодобаєтьсяСподобалось21
До обраногоВ обраному14
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Хотів би трошки додати.
1. Амазон не зацікавлений зменшувати ваші втрати, тому зменшити втрати можна через довготривале використання ресурсів (instance reservation, saving plans, тощо) або через vendor lock (наприклад використання RDS замість mysql/mariadb)
2. офіційнй рекомендації від амазона:
* динамічна інфраструктура (k8s, spot instance, autoscaling)
* міграція на гравітон (g* ec2)
* міграція на амазонівські сервіси замість selfhosted (vendor lock)
3. амазон не знає вашого продукту, і більшість з його рекомендацій це як «паління шлодить вашому здоровью» в нас було більше 5 сесій з іхніми архітекторами, з яких ми скоротили 3-4%.
4. найбільщш дорогі (у нас) області витрат — EC2, EBS, Traffic, S3.
4.1. EC2 — у нас статична ініраструктура, і більшість інстансів underprovisioned, через специфіки продукту.
4.2 міграція GP2->GP3 дозволила зекономити 15-20% на дисках. не рекомендую використовувати магнітні диски, через непередбачуванні latency. снепшоти коштують стільки, скільки й самі диски. видаляйте ті, які ваам не потрібні, або архівуйте.
4.3 трафік між AZ вразовується $.01 за гіг, шо може вилитися в копійку. за оастанні 3 роки, амазонка якщо лягав, то в усіх AZ. так шо пидтвердити ша мати декілька АZ має сенс — не можу. ми переробили наші беками, і зменшили interAZ трафік з $30 на день, до $5-6.
4.4. ви можете мігрувати ваші данні між тірами тільки в глибину. для міграції на поверхню (IA-Standard) ви фактично пересоздаєте обїекти. тут всі оптимізації очевидні, і додати мені нема чого.

Для нас, при нашіх обсягах, найбільш вигідне це поєднання ON-Prem+AWS+GCP+Azure. Але а нас свої клієнти, зі своїми потребами.

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

Дякую за увагу.

Якесь збочення спочатку обрати дорого провайдера, а потім шукати як зекономити. У Digital Ocean, наприклад, ціни on-demand такі самі як у амазона з saving plans і платою вперед. І супорт космос. Вже не кажу про всякі hetzner.

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

Якщо ви не економите

Якщо ви юзаєте ДО, хецнер — це економія по дефолту, де не треба платити наперед. Більше того — малі віртуалки на ДО on-demand дешевші за амазоновські зі скидками з апфронт пейментами.

DO і Hetner на цьому ринку це доганяючі

Відкрию секрет, ви можете юзати 2 клауда.

вони ніколи не стануть амазоном, ажуром чи гклаудом

Звичайно, бо тоді вони стануть таким самим гівном.

Вибачте, але порівнювати Hetzner з AWS, Azure чи GCP, це як порівнювати велосипед з автомобілем. Обидва мають і їдуть на колесах. Але є нюанс..
Якщо для вас чи вашого проекту клауд — це чисто про віртуалки, то так, Hetzner ваше все. Тобто велосипеда вам достатньо.
Існує купа проектів, які взагалі не мають віртуалок. Все крутиться на serverless. І ці проекти можуть посперечатися з приводу вартості ресурсів — чи платити за кілька годин в місяць фактичної роботи тієї ж AWS Lambda, чи тримати заради цього цілу віртуалку, яку ще й до того потрібно адмінити, оновлювати і т.д.
Я вже мовчу про managed сервіси, такі як RDS, EKS, SQS, SNS, SES та багато інших, які колосально знімають головну біль у порівнянні з self-managed. І бізнес може більше уваги приділяти продукту, а не питанням, чому у нас відвалилася база, чи недоступний кластер.
І наостанок, я багато бачив кейсів і сам приймав участь в проектах, коли переїжджали з того ж Hetzner, чи аналогів до AWS, Azure чи GCP. А от про зворотні міграції ще не доводилося чути. Наступні переїзди хіба вже між цією трійкою провайдерів. Ну або використання 2-х, а то і 3-х одночасно.

На доповнення наведу дуже маленький приклад вигоди serverless з одного з поточних проектів.
У мене є декілька невеликих задач, скриптів, які автомаизують мою щоденну рутину. Такі собі маленькі помічники. Щось працює по крону, а щось тригериться певними умовами чи івентами. В класичному варіанті мені для цього потрібно було підняти хоча б малесенький найдешевший сервачок (або «підселяти» до існуючих, що не дуже айс як на мене). Я тримаю це все на Lambda. Оплата в місяць за це = $0.00, тому що з легкістю «вписуюся» у ліміти free tier.

порівнювати Hetzner з AWS, Azure чи GCP, це як порівнювати велосипед з автомобілем

Дякую, кеп.

Якщо для вас чи вашого проекту клауд — це чисто про віртуалки, то так, Hetzner ваше все. Тобто велосипеда вам достатньо.

В статті вище, майже всі поради щодо оптимізації костів EC2, тому в треді мова саме про віртуалки.

І ці проекти можуть посперечатися з приводу вартості ресурсів — чи платити за кілька годин в місяць фактичної роботи тієї ж AWS Lambda

А можуть і не посперечатись. Рекомендую для гуглінга «aws lambda huge bill».

А от про зворотні міграції ще не доводилося чути.

Це тіки говорить про вашу обмежену вибірку.

Майже всі ці поради — з нормального курсу для SAA-C03. Але хто ж ті курси проходить нормально ... здають з результатом до 800 і най буде. Файна стаття-ілюстрація до розділу ’cost control’.

Пара файних і дійсно важливих моментів з практичного досвіду — з KMS — так, можна дійсно непогано нарватися. Трохи нерозкрита тема — spot instance — там є багато з чим бавитися, починаючи з того, що spot — то не про лінійну економію, то скорше про купівлю computational power у ті моменти, коли у AWS багато зайвих ресурсів, а у Вас є багато некритичної обчислювальної роботи. EKS на spot-ах — віддайте Karpenter-у і не лізьте туди руцями. А ще подумайте про пул на Graveton-ах... в залежності від задач від 5% до 60% як workload може працювати на arm64. RI — люди недооцінюють цей механізм, лікується декількома ситуаціями, коли поклав на вихідні оточення для data science і ... у понеділок зрання просто не можеш набрати потрібну кількість p4.12xlarge і data science група починає дивитися на тебе дуже недобро :-).

Дякую, не так часто я читаю статтю повністю.

Дякую за чудову статтю з наглядними прикладами. Цікаво, яким чином вдалось скоротити кости по ElastiCache? Обрали більш сучасний тип інстансу та додали autoscaling? Чи розглядали в якості альтернативи ElastiCache окремий сервіс Redis Enterprise ? Наперед дякую за відповіді

Привіт, Redis Enterprise не розглядали.
Це було давненько, але якщо не помиляюсь, то нам вдалось зменшити прайс на Redis наступним чином:
— Зменшити інстанс типи (як на продах, так і на нонпродах, бо навантаження по метрікам було не більше 10% за весь час)
— Купили RIs

Ще додам, переходьте на Graviton (arm) де можливо, та на ipv6 також де можливо.

Пробуйте використовувати гібрідні рішення, наприклад Cloudflare замість Cloudfront та Route53 та WAF.

Використовуйте http gw замість api gw якщо можливо.

Чим CloudFlare дешевший чи кращий ніж WAF?

У нього просто інший механізм ціноутворення. Якісь речі можна отримати безкоштовно або за $20 на міс., за які в aws треба платити

можете навести будь ласка конкретний приклад? Наприклад я хочу захистити базовими безкоштовними рулами ендпойнт лоадбалансера. Скільки це буде коштувати в Амазоні і в Cloudflare?
просто коли ми вже на 3 проектах мігрували з Cloudflare на WAF то чек завжди нижчав і щей ставало простіше, бо менше тулів треба менеджити а захист не слабшав.

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

Доповню про KMS keys.
1. У них є scheduled deletion, тобто можна вимкнути ключ і подивитися чи відстрелило щось і якщо так то скасувати видалення.
2. Треба бути з ними обережно, бо кожна активація ключа який був в PendingDeletion стані коштує як нова активація і коштує грошей. Я так колись випадково на $4k навидаляв ключів. AWS Support повернув кошти у якості виключення, але було неприємно.

Дякую за корисну інформацію, буду мати на увазі, що з KMS теж можна влетіти в копійочку)

Ничего нового...

Дякую за статтю. До оптимізації витрат можна ще додати scale up/down ресурсів для тест середовищ, наприклад, в одного клієнта розроблена власний сервіс, який по крону скейлить вниз всі кубернетес аплікації, контролери та EC2, вимикає RDS, після робить дисасоціацію впн та інше для не робочих годин і так само все відновлює для робочих годин. Це дозволяє додатково зекономити багато грошей :)

Ще б інтегрувати превью-оточення, які б підіймались тільки при потребі — ціни б не було)

Це добре працює, коли команда( і кастомер, котрий теж може взаємодіяти з платформою) в одній таймзоні, в інших же випадках вже краще якісь ephemeral environments, котрі, умовно, з Terraform/ CloudFormation розгортають середовище під тестування конкретної фічі та видаляють після роботи з ним

Дуже корисна стаття, дякую!

Дуже файна стаття, з усіма пунктами погоджуюся!
Що ще додавби: замість EC2 — Lambda + API Gateways + SQS+ CloudFront&S3 for static
Розшифрування: спілкуватися з розробниками і приймати участь у конфігурації архітектури щоб в подальшому більш раціонально використовувати ресурси. І не хостити абсолютно всі сервіси у докері, а, запушити статику в S3, якщо є можливість скористатися серверлес лямбдою.
Це може значно здешевити чек, але тут вже ’самостійно’ не переїдеш — потрібна кооперація з Девами і тестування щоб не просіла швидкість

Повністю підтримую, дякую 👍

Підписатись на коментарі