EKS cost audit: 12 вещей, которые стоит проверить, пока счёт за Kubernetes не вышел из-под контроля
С Amazon EKS часто бывает очень прозаичная история. Кластер подняли, сервисы крутятся, релизы едут, всё вроде нормально. А потом приходит счёт, и оказывается, что инфраструктура дорожает заметно быстрее, чем вы ожидали. Обычно это не одна большая ошибка. Это набор мелких перекосов, которые долго никто не трогал.
Здесь важно, что это не просто редакторский пересказ на тему FinOps. У AWS уже есть довольно внятный набор материалов по теме. Есть Best Practices по cost optimization для EKS. Есть отдельный Cost Optimization Framework. И есть практический разбор data-driven EKS cost optimization, где мысль очень простая: не начинайте с ножниц, начните с понимания нагрузки.
Это и есть главное, что изменилось. У команд больше нет оправдания в духе "мы не понимаем, с чего начать cost audit в EKS". AWS уже довольно прямо показала, где чаще всего теряются деньги.
С чего вообще начинать EKS cost audit
Самая частая ошибка — сразу открывать счёт и искать, что бы срочно отключить. AWS в своём practical guide предлагает идти в другом порядке: сначала понять поведение workloads, потом разбирать цену.
Это важный разворот. Пока команда не знает:
- какие сервисы реально нагружены;
- какие просто занимают место;
- где есть запас по CPU и memory;
- какие среды почти не используются;
- что можно перевести на другой тип вычислений,
любой cost cutting превращается в угадайку.
12 вещей, которые стоит проверить в первую очередь
Ниже не волшебная формула и не обещание "минус 40% за вечер". Это просто рабочий чеклист, который удобно взять за основу для внутреннего аудита затрат в EKS.
1. Requests и limits вообще похожи на реальное потребление?
Это первое, что стоит проверять почти всегда. Если requests задраны "с запасом", scheduler резервирует больше ресурсов, чем сервису реально нужно. В итоге кластеры пухнут, а производительности это не добавляет.
2. Есть ли сервисы, которые живут на нодах почти вхолостую?
Когда в кластере много микросервисов, легко не заметить, что часть из них почти ничего не делает, но стабильно держит CPU и память под себя. Такие вещи редко выглядят драматично по отдельности. Но в сумме они легко превращаются в заметную строку расходов.
3. Правильно ли настроен autoscaling?
Сам факт, что у вас включён autoscaling, ещё ничего не гарантирует. Он может масштабировать слишком рано, слишком поздно или слишком грубо. В AWS Prescriptive Guidance по cost optimization для EKS это отдельно подчёркивается: scaling-политика должна учитывать поведение workloads, а не просто существовать "для галочки".
4. Где у вас production, а где дорогой тестовый зоопарк?
Очень часто деньги утекают не из production, а из review environments, старых стендов, временных namespaces и забытых внутренних сервисов. Они вроде бы нужны "иногда", но в счёте живут постоянно.
5. Действительно ли всем workload нужны On-Demand инстансы?
В AWS EKS best practices прямо рекомендуют смотреть, какие workloads можно уводить на Spot. Но здесь важно не переусердствовать: если сервис критичен к прерываниям, дешевле не всегда значит лучше.
6. Не живёте ли вы на одном типе нод просто по привычке?
У многих команд mix инстансов складывается исторически. Что когда-то подняли, на том и сидят. Потом оказывается, что часть задач лучше чувствовала бы себя на другом семействе, другой архитектуре или вообще на другом классе вычислений.
7. Есть ли смысл в Karpenter, или он у вас просто "установлен"?
Karpenter может сильно помочь с эффективным подбором нод, но сам по себе он расходы не лечит. Если workloads описаны грубо, requests неверные, а политика выбора capacity не продумана, экономии не будет, просто масштабирование станет более автоматическим.
8. Не переплачиваете ли вы за storage?
Когда говорят про Kubernetes cost, все обычно смотрят на compute. Но EBS volumes, snapshots и неаккуратное хранение тоже quietly съедают деньги. Если volume давно не нужен, но живёт, он продолжает стоить столько же, как и полезный.
9. Что у вас происходит с network cost?
Cross-AZ traffic, data transfer и шумная сервисная сетка легко дают неприятный хвост в счёте. Это особенно заметно у SaaS-продуктов с большим количеством внутренних вызовов между сервисами.
10. Видно ли стоимость хотя бы на уровне namespace или сервиса?
Пока весь EKS выглядит как одна большая сумма, команда спорит на уровне ощущений. Как только появляется разбивка по namespace, service, tenant или среде, разговор становится предметным.
11. Понимаете ли вы unit economics своей платформы?
Полезно считать не только "сколько стоит кластер", но и сколько стоит:
- один активный клиент;
- одна тысяча операций;
- один tenant;
- один продуктовый модуль.
Тогда видно не просто "инфраструктура дорогая", а где именно она начинает съедать маржу.
12. Есть ли у вас регулярный цикл аудита, а не разовая акция?
Вот это часто самое важное. Если cost audit делается один раз после шока от инвойса, результат долго не живёт. Через пару месяцев кластер снова разрастается, временные решения становятся постоянными, и всё возвращается на круги своя.
Что AWS советует делать после первичного аудита
Если собрать все три основных материала AWS вместе, логика получается довольно приземлённая.
Сначала:
- разберите workloads;
- измерьте реальное потребление;
- найдите idle и oversized части;
- разделите критичные и некритичные сервисы.
Потом:
- корректируйте requests и limits;
- улучшайте autoscaling;
- подбирайте более подходящий mix capacity;
- переносите часть нагрузки туда, где она дешевле безопасно живёт;
- пересматривайте storage и network patterns.
И только после этого имеет смысл делать более агрессивные шаги.
Где команды чаще всего ошибаются
У этой темы есть несколько очень типичных провалов.
Первый — пытаться "сэкономить на Kubernetes", не понимая, как живёт сам продукт.
Второй — лечить стоимость только через compute и не смотреть на storage, сеть и test environments.
Третий — думать, что Spot, Karpenter или Fargate сами по себе уже означают зрелый cost optimization.
Четвёртый — не связывать техническую стоимость с продуктовой экономикой. Пока платформа живёт отдельно от unit economics, решения будут либо слишком осторожными, либо слишком резкими.
Для кого эта статья особенно полезна
Прежде всего для тех, у кого уже есть:
- SaaS на
AWS; - несколько production и non-production сред;
- Kubernetes не как эксперимент, а как повседневная платформа;
- растущий счёт, который уже начинает мешать экономике продукта.
На уровне поиска статья закрывает нормальные запросы: EKS cost audit, как снизить расходы EKS, Kubernetes cost optimization, FinOps для SaaS, как проверить лишние расходы AWS.
Если у команды задача шире и речь идёт не только про один кластер, а про системную автоматизацию платформы, аналитики и инфраструктурных процессов, это уже стыкуется с интеграцией ИИ в бизнес-процессы.
FAQ
С чего начать EKS cost audit, если времени мало?
С реального потребления ресурсов, requests/limits и списка idle workloads. Это почти всегда даёт первые находки быстрее всего.
Spot — это обязательный шаг?
Нет. Это хороший инструмент, но не универсальное решение. Для части сервисов он подходит, для части нет.
Главная ошибка какая?
Резать расходы вслепую, не понимая, какие сервисы действительно важны и как они используют кластер.
Когда cost audit стоит считать успешным?
Когда счёт снижается без деградации надёжности и команда понимает, почему экономия получилась, а не просто радуется случайному падению суммы.