20 способів оптимізації витрат на AWS, які легко допоможуть заощадити 80+ % бюджету

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

Вітання!

Мене звати Федір Компанієць, я CEO та співзасновник cервісної компанії Gart Solutions, яка спеціалізується саме на DevOps. З інженерної точки зору я AWS Cloud Architect та IT Solutions Consultant.

За моїми спостереженнями та практикою консультацій щодо оптимізації затрат на хмарні сховища, зокрема AWS, я дуже часто натрапляю на кейс, коли велика частина можливих оптимізаційних рішень, які принесуть так звані quick wins, перебувають саме в квадранті «легко реалізувати — хороший потенціал економії».

Тому я вирішив поділитися частиною простих у реалізації методів оптимізації витрат на AWS, які вам допоможуть заощаджити 80+% бюджету.

1. Надавайте перевагу покупці зарезервованих інстансів (reserved instances)

Потенціал економії: до 72%

За покупку зарезервованих інстансів по передплаті (навіть частковій) надається знижка саме на довгострокову оренду від одного до трьох років. Оскільки досить часто для багатьох компаній (особливо українських) планування на рік — це вже довгострокова перспектива, резервувати ресурси на 1-3 роки тягне за собою ризики, але і винагороду максимально можливого розміру знижки — 72%.

Усі цінові пропозиції актуальні на даний момент можна перевірити на офіційному сайті — Amazon EC2 Reserved Instances.

2. Купуйте Saving Plans (замість On-Demand)

Потенціал економії: до 72%

Існує три типи планів заощадження: Compute Savings Plan, EC2 Instance Savings Plan, SageMaker Savings Plan.

  • AWS Compute Savings Plan — це опція від Amazon Web Services, яка дозволяє користувачам отримувати знижки на використання обчислювальних ресурсів у обмін на зобов’язання використовувати певний обсяг ресурсів протягом визначеного періоду (зазвичай один або три роки). Цей план дозволяє гнучко використовувати різні обчислювальні послуги, як-от EC2, Fargate та Lambda за зниженими цінами.
  • AWS EC2 Instance Savings Plan — це програма від Amazon Web Services, яка пропонує знижені тарифи на використання вичключно EC2-інстансів. EC2 Instance Savings Plan конкретно орієнтований на використання EC2-інстансів. Він забезпечує знижки для конкретного сімейства інстансів, незалежно від регіону.
  • AWS SageMaker Savings Plan — план дозволяє користувачам отримувати знижки на використання SageMaker у обмін на зобов’язання використовувати певний обсяг обчислювальних ресурсів протягом визначеного періоду (зазвичай один або три роки).

Знижка надається на один та три роки з можливістю повної, часткової передоплати або без передоплати. EC2 може допомогти заощадити до 72%, але він розповсюджується тільки на EC2.

3. Використовуйте різні класи збереження для S3 (зокрема Intelligence Tier)

Потенціал економії: від 40% до 95%.

AWS пропонує багато можливостей для зберігання даних на різних рівнях доступу. Наприклад, S3 Intelligent-Tiering автоматично зберігає об’єкти на трьох рівнях доступу: один рівень, оптимізований для постійного доступу, на 40% дешевший рівень, оптимізований для періодичного доступу, і на 68% дешевший рівень, оптимізований для даних, до яких рідко звертаються (наприклад архів).

S3 Intelligent-Tiering має таку ж ціну за 1 ГБ, як і S3 Standard — 0,023 USD.

Однак головна перевага Intelligent Tiering полягає в тому, що вона може автоматично переміщати об’єкти, які не використовувалися протягом певного періоду, на нижчі рівні доступу.

Кожні 30, 90 та 180 днів Intelligent Tiering автоматично переміщує об’єкт на наступний рівень доступу, ця функція може заощадити компанії від 40% до 95%. Це означає, що для деяких об’єктів (наприклад для архіву) доречно платити лише $0,0125 USD за 1 ГБ або ж $0.004 за 1 ГБ порівняно зі стандартною ціною 0,023 USD.

Інформація щодо цінових пропозицій Amazon S3.

4. Регулярно перевіряйте дешборд рівня оптимізації — AWS Compute Optimizer

Потенціал економії: у більшості випадків — досить суттєвий.

Інформаційна панель AWS Compute Optimizer  це інструмент, який дозволяє користувачам оцінювати та визначати пріоритети оптимізації для своїх ресурсів AWS.

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

Інформаційна панель охоплює різні типи ресурсів, як-от: EC2 instances, Auto Scaling groups, Lambda functions, Amazon ECS services on Fargate, Amazon EBS volumes.

Наприклад, AWS Compute Optimizer відтворює інформацію недостанього, або надмірного використання ресурсів віділених для ECS Fargate-сервісів або Labda-функцій:

5. В EKS запустіть POD на AWS Fargate замість вузлів EC2, якщо вони недозавантажені

Якщо ваші ноди EKS недовикористовуються більшу частину часу, має сенс розглянути можливість використання профілів Fargate. З AWS Fargate ви будете платити за певну кількість ресурсів пам’яті / процесора, які вам потрібні для вашого POD, замість того, щоб платити за повну віртуальну машину EC2.

Наприклад застосунок, розгорнутий у Kubernetes кластері, що керується за допомогою Amazon EKS (Elastic Kubernetes Service). Застосунок має змінний трафік, з піковими навантаженнями в певні години дня або тижня (маркетплейс або інтернет-магазин), і ви хочете оптимізувати витрати на інфраструктуру. Для вирішення цієї задачі, необхідно створити Fargate Profile, який визначає, які PODs мають запускатися на Fargate. Налаштувати Kubernetes Horizontal Pod Autoscaler (HPA), щоб автоматично масштабувати кількість реплік PODs, засноване на їх використанні ресурсів (наприклад, використанні CPU або пам’яті).

6. Управляйте навантаженням у різних ваших регіонах

Потенціал економії: в більшості випадків — досить суттєвий.

Під час управління робочим навантаженням у кількох регіонах важливо враховувати різні аспекти, як-от теги розподілу витрат, бюджети, нотифікації та відновлення даних (cost allocation tags, budgets, notifications, and remediation).

  • Cost Allocation Tags — дозволяють вам класифікувати та відстежувати ваші витрати на основі різних найменувань, наприклад: програма, середовище, команда або проєкт.
  • AWS Budgets дозволяють визначати порогові значення витрат і отримувати сповіщення, коли ваші витрати перевищують визначені порогові значення. Ви можете створювати бюджети спеціально для вашого робочого навантаження або розподіляти бюджети на певні послуги чи теги розподілу витрат.
  • Notifications — налаштуйте сповіщення коли ваші витрати наближаються або перевищують визначених порогових значень. Сповіщення допоможуть вам вчасно вжити заходів для оптимізації витрат і запобігти перевитратам.
  • Remediation — впроваджуйте механізми для виправлення витрат на основі вимог вашого робочого навантаження. Це може включати автоматизовані дії або ручне втручання для розв’язання питань, пов’язаних з витратами.
  • Регіональні відмінності — враховуйте регіональні особливості в ціноутворенні та витратах на передачу даних під час розробки архітектури робочих навантажень.
  • Reserved Instances and Savings Plans — використовуйте зарезервовані екземпляри або планування збережень, щоб отримати економію коштів.
  • AWS Cost Explorer — використовуйте інструмент для візуалізації та аналізу ваших витрат. Cost Explorer дає уявлення про ваше використання та тенденції витрат, дозволяючи визначати області з високими витратами та потенційні можливості для економії коштів.

7. Перехід до Graviton (ARM)

Потенціал економії: до 30%.

Graviton використовують серверні ARM-процесори Graviton, розроблені компанією Amazon. Нові процесори та екземпляри будуть корисні для різноманітних застосувань, зокрема «високопродуктивні обчислення, пакетна обробка, автоматизація проєктування електронних пристроїв (EDA), мультимедійне кодування, наукове моделювання, розподілену аналітику та виведення результатів машинного навчання на системах на базі процесора».

Сімейство процесорів базується на архітектурі ARM. Тобто вони, швидше за все, будуть системою на кристалі (SoC). Це означає нижчі витрати на енергоспоживання, при цьому пропонуючи задовільну продуктивність для більшості клієнтів. Найважливішими перевагами AWS Graviton є зниження витрат, низька затримка, краща масштабованість, підвищена доступність і безпека.

8. Використання spot-інстансів замість on-demand

Потенціал економії: до 30%.

Використання spot-інстансів — це, по суті, обмін ресурсами. Коли у Amazon є багато ресурсів, що простоюють, ви можете встановити максимальну ціну, яку ви готові заплатити за них. Єдине, що за відсутності вільних потужностей, запитувані ресурси не будуть вам надані.

Але тут є ризик, що у разі якщо попит різко зросте і спотова ціна перевищить встановлену вами максимальну ціну, ваш спот буде розірвано.

Spot-iнстанси працюють за принципом аукціону, тому ціна на них не фіксована. Ми говоримо, скільки ми готові максимально заплатити, а AWS вже вирішує, кому надати обчислювальні потужності. Якщо ж ми готові платити $0.1 за годину, а ринкова ціна — $0.05, то ми будемо платити саме $0.05.

9. Використовуйте Interface Endpoints чи Gateway Endpoint, щоб заощадити на витратах на трафік (S3, SQS, DynamoDB, тощо)

Потенціал економії: залежить від навантаження.

Інтерфейсні кінцеві точки працюють на основі AWS PrivateLink і дозволяють отримати доступ до сервісів AWS через приватне мережеве з’єднання без виходу в Інтернет. Використовуючи Interface Endpoints, ви можете заощадити на витратах на передачу даних, пов’язаних з трафіком.

Використання Interface Endpoints чи Gateway endpoint справді може допомогти заощадити на витратах на трафік під час доступу до таких сервісів, як Amazon S3, Amazon SQS і Amazon DynamoDB з вашому Віртуальної приватної хмари Amazon (VPC).

Ключові моменти:

  • Amazon S3: за допомогою інтерфейсної кінцевої точки для S3 ви можете отримати приватний доступ до S3-відер без витрат на передачу даних між вашим VPC та S3.
  • Amazon SQS: кінцеві точки інтерфейсу для SQS дозволяють безпечно взаємодіяти з чергами SQS в межах вашого VPC, уникаючи витрат на передачу даних для зв’язку з SQS.
  • Amazon DynamoDB: використовуючи кінцеву точку інтерфейсу для DynamoDB, ви можете отримати доступ до таблиць DynamoDB у вашому VPC без витрат на передачу даних.

Крім того, інтерфейсні кінцеві точки дозволяють вам отримати приватний доступ до служб AWS, використовуючи приватні IP-адреси в межах вашого VPC без необхідності використання трафіку інтернет-шлюзу. Це дозволяє усунути витрати на передачу даних для доступу до таких сервісів, як-от S3, SQS і DynamoDB, з вашого VPC.

10. Оптимізуйте розмір іміджів, щоб вони завантажувалися швидше

Потенціал економії: залежить від навантаження.

Оптимізація іміджів за розміром допоможе вам заощадити різними способами.

  1. Зменшити витрати на ECR, зберігаючи менші екземпляри.
  2. Тримати менші обсяги EBS на нодах EKS.
  3. Пришвидшити час запуску контейнерів і, зрештою, швидше виконувати завдання.

Методи оптимізації:

  • використання оптимального іміджу в роботі, наприклад, в деяких ситуаціях буде достатньо Alpine;
  • видалення з іміджу зайвих даних та пакетів;
  • багатоетапна збірка іміджу — використання декількох інструкцій FROM;
  • використання .dockerignore дозволить уникнути додавання зайвих файлів;
  • зменшення кількості інструкцій, оскільки кожна інструкція є додатковою вагою хешу, групуємо інструкції за допомогою оператора &&;
  • виносимо шари, що часто змінюються, в кінець докерфайлу.

11. Використовуйте LB, щоб заощадити на вартості IP-адреси

Потенціал економії: залежить від навантаження.

Починаючи з лютого 2024 року, Amazon починає виставляти рахунок за кожну публічну IP-адресу — IPv4. Використання балансувальника навантаження (load balancer) може допомогти заощадити на витратах на IP-адресу, використовуючи загальну IP-адресу, мультиплексування трафіку між портами, алгоритмів балансування навантаження та обробки SSL/TLS.

Об’єднуючи декілька сервісів та інстансів під однією IP-адресою ви можете досягти економії коштів, одночасно ефективно керуючи вхідним трафіком.

12. Налаштуйте сервіси, щоб отримати вищу продуктивність (MySQL, PostgreSQL, тощо)

Потенціал економії: залежить від навантаження.

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

Одними з найбільш ефективними можуть бути такі налаштування:

  • використання оптимізованих для баз даних інстансів: наприклад, інстанси класу R5 або X1 є оптимізованими для роботи з базами даних;
  • вибір типу сховища: General Purpose SSD (gp2) зазвичай дешевший, ніж Provisioned IOPS SSD (io1/io2);
  • AWS RDS Auto Scaling: автоматичне збільшення або зменшення розміру сховища залежно від потреб.

Якщо вам вдастся оптимізувати навантаження на базу даних, це може дати вам можливість використовувати менші розміри інстансів без шкоди для продуктивності.

13. Регулярно оновлюйте інстанси (краща продуктивність і менша ціна)

Потенціал економії: невеликий.

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

Візьмемо Memory Optimize інстанси і на їхньому прикладі порівняємо зміну ціни, залежно від актуальності того чи іншого інстансу:

Тип Інстансу

Покоління

Опис

Ціна On-Demand для ’Large’ Інстансу (USD/год)

m6g.large

Новіші

Інстанси засновані на процесорах ARM, покращення продуктивності та енергоефективності

$0.077

m5.large

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

$0.096

m4.large

Старіші

Добрий баланс між CPU, пам’яттю та мережевими ресурсами

$0.10

m3.large

Старі

Одне з попередніх поколінь, менш ефективні від m5 та m4

Not avilable

14. Використовуйте RDS Proxy для зменшення навантаження на RDS

Потенціал економії: невеликий.

RDS Proxy використовується для розватаження серверів та баз данних RDS шляхом перевикористання наявних з’єднань замість створення нових. Крім того, RDS proxy покращує failover під час переключення резервної read replica ноди у master.

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

Під час пікових навантажень база даних RDS може зіткнутися з проблемами продуктивності та доступності через велику кількість одночасних підключень та запитів. Це може призвести до затримок у відповідях або навіть до недоступності сервісу.

RDS Proxy буде управляти пулами підключень до бази даних, значно зменшуючи кількість прямих підключень до самої бази даних.

Завдяки ефективному управлінню підключеннями, RDS Proxy забезпечує більш високу доступність та стабільність, особливо під час пікових періодів.

Використовуючи RDS Proxy навантаження на RDS зменшується, а відповідно зменшуються і затрати.

15. Визначте політику зберігання в CloudWatch

Потенціал економії: залежить від навантаження, може бути суттєвим.

Політика зберігання в Amazon CloudWatch визначає як довго дані повинні зберігатися у CloudWatch Logs, перш ніж вони будуть автоматично видалені.

Вказівка правильної політики зберігання важлива для ефективного керування даними та оптимізації витрат. Хоча опція «Ніколи» доступна, вона, як правило, не рекомендується для більшості випадків використання через потенційні витрати та проблеми з управлінням даними.

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

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

16. Налаштуйте AWS Config для моніторингу лише потрібних вам подій

Потенціал економії: залежить від навантаження.

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

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

17. Використовуйте політики життєвого циклу для S3 та ECR

Потенціал економії: залежить від навантаження.

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

Ці політики міграції об’єктів можна ідентифікувати за періодами зберігання об’єктів. Ви можете вказати політику для всього S3-bucket або для певних префіксів. Вартість міграції даних протягом життєвого циклу визначається вартістю завантаження. Налаштувавши політику життєвого циклу для ECR, ви можете уникнути зайвих витрат на зберігання докер-образів, які вам більше не потрібні.

18. Переключіть EBS на використання типу сховища GP3

Потенціал економії: 20%.

За замовчуванням AWS створює томи EBS gp2, але майже завжди слід віддавати перевагу gp3 — останньому поколінню томів EBS, яке за замовчуванням забезпечує більше IOPS і є дешевше.

Наприклад, у регіоні US-east-1 ціна тома gp2 становить $0,10 за гігабайт-місяць наданого сховища, а для gp3 — $0,08/ГБ на місяць. Якщо на вашому акаунті 5 ТБ обсягу EBS, ви можете заощадити $100 на місяць просто перейшовши з gp2 на gp3.

19. Змініть формат публічних IP адрес з IPv4 адреси на IPv6

Потенціал економії: в залежності від навантаження.

Починаючи з 1 лютого 2024 року AWS почне виставляти рахунок за кожну публічну IP-адресу IPv4 в розмірі $0,005 за IP-адресу на годину. Наприклад, візьмемо 100 публічних IP-адрес EC2 x $0,005 за публічну IP-адресу на місяць x 730 годин = $365,00 на місяць.

Ця цифра не виглядає величезною (не прив’язуючи її до можливостей компанії), однак це може додати значних витрат на мережу. Так, найкращий час для переходу на IPv6 був пару років тому або ж зараз.

Ось деякі ресурси про цей останній апдейт, які покажуть вам, як можна використовувати IPv6 з широко розповсюдженими сервісами — AWS Public IPv4 Address Charge.

20. Співпрацюйте через посередників — професіоналів в AWS та партнерів, щоб отримати не лише експертизу, а й знижку

Потенціал економії: ~5% від суми контракту за рахунок знижки

  • AWS Partner Network (APN) Discounts. Як члени AWS Partner Network, компанії-партнери можуть отримувати спеціальні знижки, які вони можуть передати своїм клієнтам. Партнери, які досягли певного рівня в програмі APN, часто мають доступ до кращих цінових пропозицій.
  • Custom Pricing Agreements. Деякі партнери AWS можуть мати можливість укласти угоди про спеціальне ціноутворення з AWS, які дозволяють їм пропонувати унікальні знижки своїм клієнтам. Це може бути особливо актуально для компаній, що займаються консалтингом або інтеграцією систем.
  • Reseller Discounts. Як перепродавці AWS послуг, партнери можуть закуповувати сервіси за оптовими цінами і продавати їх клієнтам з націнкою, але все ще зі знижкою від стандартних цін AWS. Вони можуть також запропонувати пакетні пропозиції, що включають AWS сервіси та їх власні додаткові послуги.
  • Credit Programs. AWS часто пропонує кредитні програми або ваучери, які партнери можуть передавати своїм клієнтам. Це можуть бути промокоди або знижки на певний термін.

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

Ви також можете звернутися до мене чи до інших спеціалістів за аудитом, комплексом робіт з оптимізації чи просто порадою.

Висновок

Оптимізаця витрат — це завжди комплекс заходів і постійний контроль за інфраструктурою.

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

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

Буду радий відповісти на всі ваші коментарі та питання.

👍ПодобаєтьсяСподобалось17
До обраногоВ обраному22
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

ще можно додати пункт
21. Не завжди використовуйте сервіси від AWS, дуже багато є альтернатив які можуть бути аби дешевше або мати більше функціоналу."
Наприклад:
Error handling:
AWS: CloudWatch + AWS Bot + Slack
3rd party: Sentry + Slack
або
File storage:
AWS: S3
3rd party: Wasabi
або
Serverless DB:
AWS: AWS Aurora
3rd party: Neon.tech

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

Коли радите альтернативи, будь ласка, завжди добавляйте наскільки це збільшує час&витрати на операційку&документацію&Онбординг.
Якщо проект буде використовувати такі технології як ви написали, то, потрібно буде адмінів/девопсів ледь не половину від всього штату людей. Це саме стосується новомодних переїздів на власний датацентр.
Також не забувайте про зручність використання. Коли у вас все на амазоні траблшутинг, видача нових кредлів, майже всі операції займають хвилини.

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

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

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

з тих що я перерахував взагалі не треба девопси, це все SaaS які інтегруються в декілька кліків, але згоден що це треба також враховувати

Основна проблема що багато хто думає що я взяв AWS і все, використовує тільки що він дає, але на практиці у AWS багато «сирих» сервісів, а також Амазону важко конкурувати з рішеннями які мають вузьку специалізацію, наприклад error handling:
Sentry, альтернатива якому customized CloudWatch Logs, яка ніяк не може конкурувати з Sentry за наявністю фіч. Або NewRelic, DataDog vs CloudWatch, це ж взагалі різного рівня сервіси.
Або тей ж самий AWS CodePipeline з GitHub Actions, CircleCI, etc

Я б ще доповнив наступним пунктом: оптимізація та менеджент AWS Support Plan, оскільки це дуже не дешева фіча але інколи потрібна . aws.amazon.com/...​support/pricing/?nc1=h_ls

www.thefrugalarchitect.com

Вернер на re:invent про те ж саме розповідав, але якось взагалі, стаття краще бо практичніше.

Я б додав ще дивитись у бік serverless, у тому числі бази.

Ще за рахунок автоматизації гетерогенної інфраструктури нам вдається економити на тих сервісах, які дешевші у інших провайдерів ніж у aws, наприклад у cloudflare краще cdn, edge, monitoring, dns, waf і практично безкоштовно зараз.

Загалом стаття і перелічені пункти файні, яб доповнив важливими пункатими:
1. Scheduled TurnOff/TurnOn для NonProd environments. Якщо Дев команда знаходиться в одній таймзоні то можна серйозно зекономити якщо, наприклад, скейлити AutoScaling групу інстасів/кластеру/RDS на якому у вас раняться сервіси до 0 вночі і на вихідних.
2. Статику виносити на S3 Bucket&CloudFront. Щоб не ранилися на сервісах
3. Де можна юзайте API Gateway/Lambda/Lambda Edge — тут вит платите лише за використання сервісу, навіть якщо у вас багато конфігурацій, особливо це відчувається на NonProd environments де дуже часто велике недовикористання ресурсів.
4. Якщо у вас CI/CD агенти є на EC2 то мігруйте на CodeBuild
5. CloudWatch покриває потреби 99% проектів щодо Моніторингу і Логування, не використовуйте thirdparties.
6.

політику життєвого циклу

використовуйте не лише для s3&CloudWatch Logs&ECR а і для Бекапів Баз даних, Снапшотів

Дякую. Особливо за 5й пункт :) . Дійсно CloudWatch дуже потужний і має всі необхідні інтеграції «from the box». Єдине що, репрезентацію метрик, я всеж теки б виніс до якоїсь Kibana.

Єдине що, репрезентацію метрик, я всеж теки б виніс до якоїсь Kibana.

Нда, готові метрики це якийсь позор. Щоб якось відфільтрувати реквести в OpenSearch по response code, треба на саппорт писати. Ну а що, відображення реквестів по групам ( 2хх, 4хх, 5хх) — це ж цілком достатньо, кому потрібно більше, 404 і 429 це ж практично одне і те ж. ))

Вам не кажется что что-то пошло не так?
Как так получилось что облачные провайдеры сумели обольстить и подсадить на сервис, на котором мы теперь учимся экономить.
При том что сервера сами по себе стоят уже достаточно дешево.
Где открытое ПО для облачных решений?

Где открытое ПО для облачных решений?

пан мабуть взагалі не в темі
якого відкритого пз не вистачає — убунту на серверах?
+ у амазона є бібліотеки з відкритим вихідним кодом для маніпуляцій з їх сервісами
для пайтона це boto3 наприклад.
Те, що вони беруть за кожен чих гроші — так беруть, але тут така справа —не хочеш не користуйся.
І потім, амортизацію заліза та електрику ніхто не скасовував.
Як я пам’ятаю, інстанс ес2 найменьший коштує пів центи за годину ( плюс вони звичайно докидують своїх додаткових нарахувань. ) ну нехай буде 1 цент на годину.
Я не впевнений, що ви впораєтеся із задачею підтримування власного сервера за цей 1 цент/год.
( а ще гугл пропонує свої подібні сервіси десь на 20 відсотків дешевше , але то таке —до слова )
якось так.

При том что сервера сами по себе стоят уже достаточно дешево

Сервери самі по собі не несуть жодної користі хай вони хоч і безкоштовні будуть. Так само, як і freeware. А от сервіси на базі freeware, що виконуються на серверах, вже мають цінність. І підтримка цього коштує грошей. І для бізнесу managed-сервіси від клауд-провайдерів обходяться дешевше, чим підтримка in-house командою на своїх чи «дешевих» серверах в ДЦ.

Где открытое ПО для облачных решений?

Всюди.

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

по количеству однотипных комментариев, вырывающих слова из контекста, понятно что уровень дискуссии на доу пока слабоват

AWS — это что? Магия какая-то? я и указываю на отсутствие софта, который мог бы управлять железом по тому же самому принципу что и AWS, но не в облаке, а на выделенных серверах. Допустим там не будет такой эффективности использование железа, но этим можно пренебречь, все равно ничего в принципе нет. Есть open stack, но это технология, а не продукт

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

А на правді треба вчитися всім: і босам і інженерам

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

😆😆😆 таки є правда)

часто незавадить ’незамилений’ погляд збоку.

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

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