AWSDevOpsKubernetesECSEKS

ECS vs EKS: почему «стандарт индустрии» стоит 30% времени команды

3 мин чтения English

Выбираем: ECS или EKS?
Команда: “Давайте K8s. Это же стандарт. Переносимость. Опыт в резюме.”
Через 3 месяца считаем, во что это обошлось.

Вы понимаете, да?
Модно, молодежно, все вот это вот…
Инфра - AWS. Микросервисы, контейнеры!

Это нормально.

Варианта в целом два:

  • ECS Fargate: AWS-специфичный, managed
  • EKS: Kubernetes, “стандарт индустрии” (чувствуете сарказм, да?)

Народ выбирает EKS. Аргументы:

  • “K8s знают все, найти людей проще”
  • “Переносимость: завтра на GCP переедем за день”
  • “Гибкость: любые варианты деплоя”

Звучит разумно? Поехали, давайте посчитаем.

Что же мы получим через 3 месяца разработки

EKS control plane: $73/месяц. Это фиксированно.

Минимум 3 ноды для стабильности control plane. Даже если нагрузка - один сервис на самом маленьком инстансе.

Что у нас теперь есть:

  • Ingress: NGINX Ingress Controller или ALB Ingress. Настройка, обновления, мониторинг.
  • Networking: VPC CNI, security groups, pod-to-pod routing.
  • Monitoring: Prometheus + Grafana или покупать Datadog.
  • Logging: Fluentd/Fluent Bit → CloudWatch/S3.
  • RBAC: Service accounts, IAM roles for service accounts (IRSA), namespace isolation. В ECS - IAM task role, всё.
  • DNS: CoreDNS, настройка, отладка.
  • Обновления: Кластер, ноды, аддоны, CNI плагины. Каждый квартал.

Время инженера: ~20-30% уходит на поддержку кластера. Не на фичи, на инфраструктуру.

В ECS это было бы:

  • Ingress: ALB, всё.
  • Networking: Работает по умолчанию.
  • Monitoring: CloudWatch из коробки.
  • Logging: Один параметр в task definition.
  • RBAC: IAM task role, всё.
  • DNS: Route 53 и service discovery, работает.
  • Обновления: AWS делает сам.

Про “переносимость”

“Завтра переедем на GCP” - красиво звучит. В реальности:

Managed K8s отличаются:

  • EKS использует AWS Load Balancer Controller (CRD под AWS ALB/NLB)
  • GKE использует Google Cloud Load Balancer (другие CRD)
  • Bare metal - вообще свои Ingress

Если делать “чистый K8s” для переносимости:

  • Не использовать managed Load Balancers → сложнее
  • Не использовать IAM integration → ещё один слой авторизации
  • Не использовать провайдерские storage classes → свой Persistent Volume provisioner

Это увеличивает сложность в 1.5-2 раза.

Вопросы:

  • Вы реально планируете мигрировать? Когда?
  • У вас есть критерии, при которых вы переедете?
  • Окупится ли самоограничение или проще допилить, когда понадобится?

Большинство компаний никогда не переезжают. Vendor lock-in страшнее в теории, чем на практике.

Аналогия

Видел историю: начальник решил работать напрямую с фабриками в Китае, чтобы избежать наценки посредника (15%).

В итоге контейнер простоял в порту одну неделю из-за забытых таможенных документов. Штрафы стоили как два месяца поставок с посредником.

С EKS похоже:

Вы “избегаете” vendor lock-in, получаете “гибкость”. Но платите временем инженеров, стабильностью, скоростью разработки.

Посредник (в данном случае AWS ECS) берёт “наценку”, но решает проблемы за вас.

Преимущества ECS

ECS Fargate:

  • Деплой за <10 минут (task definition → service → URL)
  • Мониторинг из коробки (CloudWatch)
  • Автоскейлинг настраивается за 5 минут
  • Обновления - AWS делает сам
  • Networking - работает по умолчанию

Стоимость: только за контейнеры. Нет control plane, нет “минимум 3 ноды”.

Ограничения:

  • Привязка к AWS
  • Меньше гибкости (нет Helm, Operators, сложных patterns)
  • Чистый compute - дороже за “единицу”

Но для очень многих проектов этого хватает.

Когда EKS оправдан

Честно? Не знаю.

Может быть:

  • Высоконагруженный проект с десятками сервисов и сложными deployment patterns
  • Команда уже знает K8s и не хочет переучиваться (серьезно? пять минут чтения-сравнения конфига?)
  • Реальная мультиоблачность (не “может быть переедем”, а уже работаете в нескольких облаках)

Но даже тогда вопрос: окупается ли сложность?

Для большинства проектов EKS - это overengineering. “Правильная” архитектура, которая стоит 30% времени команды.

Еще раз:

“K8s - это стандарт” - не аргумент для выбора.

ECS проще, дешевле и быстрее в разработке. EKS гибче, но дороже в обслуживании.

Проектирование архитектуры с учётом стоимости владения (не только счет от aws, но и время команды) избавляет от таких сюрпризов. Но большинство узнают о них через некоторое время после запуска.

Почти всегда “проще и чуть дороже” лучше, чем “правильно, но сложно”.

P.S. “Гибкость” и “переносимость” звучат хорошо в презентациях. В реальности они стоят 20-30% времени команды. Это точно того стоит?