Kubernetes → ECS Fargate: кейс упрощения инфраструктуры

Разбор кейса: упрощение инфраструктуры путём перехода с Kubernetes на ECS Fargate для NetworkLessons

Рене Моленар создал NetworkLessons.com — одну из самых полных обучающих платформ для подготовки к сертификациям Cisco. Тысячи участников используют его видеокурсы, пробные экзамены и форум сообщества, чтобы развивать карьеру в сетевых технологиях.

Когда Рене обратился ко мне, он хотел модернизировать свою AWS-инфраструктуру. Он экспериментировал с Kubernetes для контейнеризации рабочих нагрузок, но обнаружил, что операционные издержки отнимают время от главного — создания контента для участников платформы.

Проблема

За годы работы AWS-окружение Рене накопило технический долг:

  • Ручные конфигурации AWS, созданные через консоль и CloudFormation, которые становились всё сложнее поддерживать

  • Только производственная среда — без безопасного места для тестирования изменений перед развёртыванием

  • Неудачный эксперимент с Kubernetes, который поглощал больше времени на управление кластером, чем экономил

  • Устаревшая инфраструктура, которую трудно было обновлять без риска простоя

История с Kubernetes — одна из самых распространённых, что я слышу. Команды переходят на K8s в ожидании операционной простоты, но обнаруживают, что обменяли сложность приложения на сложность инфраструктуры. Для соло-основателя, сосредоточенного на создании контента, поддержка Kubernetes-кластера была попросту неверным компромиссом.

Решение: от сложности Kubernetes к простоте AWS CDK

В сотрудничестве с Рене я разработал полный план модернизации инфраструктуры через миграцию в AWS, который вернул ему время и обеспечил более надёжную и экономичную платформу.

Многоаккаунтная архитектура

Первым шагом стало внедрение правильной многоаккаунтной архитектуры с разделением аккаунтов:

  • Главный аккаунт для управления DNS через Route53

  • Производственный аккаунт для работающей платформы

  • Тестовый аккаунт (совершенно новый) для безопасных экспериментов

Звучит просто, но Рене запускал всё в одном производственном аккаунте. Каждое изменение несло риск. Теперь, благодаря делегированию Route53 между аккаунтами, он может тестировать изменения инфраструктуры в изолированной среде, не затрагивая production.

Миграция с Kubernetes на ECS Fargate

Kubernetes — мощный инструмент, но эта мощь сопряжена с операционной сложностью: обновления кластера, управление пулами узлов, сетевые плагины и постоянный мониторинг control plane. Для обучающей платформы, которая должна работать надёжно, эти издержки не добавляли ценности.

Я перенёс контейнеризированные рабочие нагрузки на ECS Fargate, который предоставляет преимущества оркестрации контейнеров без необходимости управлять кластером. Платформа WordPress и система экзаменов теперь работают как отдельные сервисы на общем Application Load Balancer. Задачи WordPress cron выполняются через запланированные задачи Fargate, заменяя постоянно работающие cron-контейнеры.

Ключевое отличие: в ECS Fargate AWS управляет базовой инфраструктурой. Никаких узлов для патчинга, никаких версий кластера для обновления, никакого планирования мощностей для control plane. Рене получает изоляцию контейнеров и масштабирование без операционного налога Kubernetes.

Интеллектуальная оптимизация затрат

Вот где инфраструктура как код (Infrastructure as Code) действительно раскрывается. Я реализовал автоматизированное управление расходами, которое было бы утомительно поддерживать вручную:

  • Автоматическое отключение тестовой среды после рабочих часов и в выходные дни (полностью автоматизировано через IaC)

  • NAT-инстансы в тестовой среде вместо NAT Gateway (существенная ежемесячная экономия)

  • Планировщики инстансов для EC2 и RDS, которые останавливают непроизводственные ресурсы

  • Уведомления AWS Budget для обнаружения неожиданных трат до того, как они станут проблемой

Тестовая среда фактически не стоит ничего ночью и в выходные, потому что ничего не работает.

Полная инфраструктура как код

Всё окружение теперь описано в AWS CDK на TypeScript. Каждый VPC, группа безопасности, определение контейнера и Lambda-функция существуют в версионируемом коде.

GitHub Actions управляет развёртываниями через федерацию OIDC, исключая необходимость хранить учётные данные AWS. Изменения проходят через pull request’ы, проверяются и деплоятся автоматически.

Автоматизация бизнес-логики

Помимо инфраструктуры, платформа требовала десятков Lambda-функций для автоматизации различных операционных задач. Используя пользовательский Lambda-конструкт в CDK, я создал более 20 функций без дублирования шаблонного кода. Каждая функция наследует единую конфигурацию для логирования, обработки ошибок и подключения к VPC.

Этот подход делает добавление новой автоматизации простым: опишите бизнес-логику, а конструкт позаботится об остальном. Задачи, которые Рене раньше выполнял вручную, теперь работают автоматически в фоновом режиме.

Безопасность и надёжность

Production работает с защитой корпоративного уровня:

  • WAF v2 на CloudFront и Application Load Balancer

  • Multi-AZ RDS для высокой доступности базы данных

  • Шифрование везде (EBS, RDS, EFS)

  • Интеграция с PagerDuty для немедленного оповещения

  • Автоматические резервные копии с заданными политиками хранения

Результаты

Преобразование принесло именно то, что было нужно Рене:

  • Инфраструктура остаётся актуальной автоматически через CI/CD-пайплайн

  • Безопасная тестовая среда для проверки изменений перед развёртыванием в production

  • Предсказуемые расходы благодаря автоматическому планированию и уведомлениям о бюджете

  • Никакой борьбы с Kubernetes

  • Время на создание контента вместо управления инфраструктурой

«Дэнни профессионально оценил мой существующий стек и полностью переработал его в соответствии с лучшими практиками AWS. Вся инфраструктура теперь определена как код, что делает её невероятно простой в обслуживании. Всё автоматически поддерживается в актуальном состоянии через пайплайн, что устраняет ручную работу и потенциальные ошибки из моей прежней настройки.»

 — Рене Моленар, основатель NetworkLessons.com

От ручного управления к современной AWS: успешная миграция в облако

Платформа Рене теперь работает на инфраструктуре, такой же надёжной, как его обучение, благодаря сервису миграции в AWS. Сложность Kubernetes ушла в прошлое — её заменили управляемые сервисы, которые масштабируются автоматически. Ручная работа с консолью AWS исчезла — её заменил код, который документирует сам себя и деплоится предсказуемо.

Самое главное — Рене может сосредоточиться на том, что у него получается лучше всего: создавать первоклассный контент по сертификациям Cisco для своих участников.

Логотип сообщества DEV
© 2026 meganuke