AWS Elastic Beanstalk

Проблема: в нашу компанию CelerFide, которая занимается разработкой Java backend'a, где я являюсь CEO, пришли со следующей прооблемой: небольшим командам сложно и дорого поддерживать собственный кластер Kubernetes, но при этом нужен надёжный хостинг для веб‑приложений.

Решение: мы перешли на AWS Elastic Beanstalk — управляемую платформу, которая берёт на себя инфраструктуру, а разработчикам остаётся только писать код.

В статье рассказываем, как устроен Beanstalk, почему он оказался дешевле Kubernetes, с какими нюансами мы столкнулись и какие есть российские аналоги.

Минимальный порог входа. Загружаем архив или Docker‑образ — платформа сама создаёт виртуальные машины, балансировщик и настраивает мониторинг.
Платим только за железо. За сам Beanstalk денег не берут: в счёте остаются лишь виртуальные машины, диски и балансировщик.
Готовые «движки». Java, Python, Node.js, .NET и другие популярные стеки уже настроены и регулярно получают обновления безопасности.
Заказчик захотел не иметь DevOps в штате для поддержки кластера Kubernetes.

Окружение. Создаёт группу авто‑масштабирования, балансировщик и виртуальные машины.
Файл настройки (.ebextensions). Определяет переменные окружения, пакеты, скрипты и правила масштабирования.
Стратегии обновления. Можно выбрать постепенный откат, добавление временной группы, неизменяемый деплой или «синий‑зелёный» перенос трафика.
Мониторинг. Встроенный дашборд Beanstalk и графики CloudWatch показывают загрузку CPU и ошибки 5xx.

Elastic Beanstalk полагается на Auto Scaling Group AWS, поэтому умеет горизонтально расти так же, как «чистые» EC2‑флоты:

Метрики триггера. Доступны CPU‑процент, входящий / исходящий трафик и Requests Per Target (если используется ALB). Можно настроить любую пользовательскую метрику CloudWatch.
Политики. Поддерживаются целевая нагрузка, пошаговое и расписное масштабирование. Пара кнопок — и приложение само держит 50 % CPU или, например, добавляет три экземпляра перед вечерним пиком по пятницам.
Скорость. Новая машина поднимается за 2–3 минуты (запуск EC2 + инициализация приложения). Чтобы ускорить, можно создать собственный AMI с уже прогретым кэшем.
Пределы. По умолчанию одно окружение поддерживает до 200 экземпляров (лимит можно повысить через поддержку AWS). Для мгновенных всплесков «в разы за секунды» лучше подходит Lambda.
Worker‑окружения. Для фоновых задач есть тип «Worker» — масштабируется по длине очереди SQS, не мешая веб‑слою.

Сложность конфигурации. Вместо сотен строк Helm‑скриптов на каждый сервис теперь одна команда eb deploy.
Обновления платформы. Раньше дежурили, чтобы обновлять управляющие узлы Kubernetes; сейчас кликаем «Update» в консоли Beanstalk и ждём пару минут.
Мониторинг. Связка Prometheus + Grafana сменилась на встроенные графики CloudWatch.
Онбординг. Новичок тратит не три дня, а полдня, чтобы разобраться, как выкладывать сервисы.
Финансовый результат. Инфраструктурные расходы снизились примерно на 40 %, а время вывода новых функций заметно сократилось.

Elastic Beanstalk. Около 77 долларов в месяц за две виртуальные машины t3.medium и один балансировщик.
Amazon EKS. При тех же компонентах выходит примерно 150 долларов, потому что добавляется фиксированная плата 0,10 $/ч за управляющие узлы кластера.
AWS Lambda. Если функция вызывается редко (например, 3 млн раз по 200 мс), счёт будет около 5 долларов.

Beanstalk почти вдвое дешевле EKS, когда сервис работает круглосуточно, а Lambda выгодна только при малом количестве коротких вызовов.

Почему так? Beanstalk развёртывает приложение напрямую на EC2 и не использует EKS. Вы не платите за control‑plane, а одного балансировщика хватает на всё окружение.

EKS остаётся лучшим выбором, если нужны возможности «чистого» Kubernetes:

Нестандартные ворклоады: Stateful Set, Daemon Set, CronJob, sidecar‑паттерны.
Service Mesh (Istio, Linkerd), продвинутое трассирование и свой Prometheus‑кластер.
Тонкая сеть: CNI‑плагины, NetworkPolicy, PodSecurityPolicy.
Портируемость: Helm‑чарты можно развернуть в любом другом Kubernetes‑кластере.
Смешанные нагрузки: Spark, Kafka, ML‑джобы и стриминговые сервисы.

Важно: Beanstalk не прячет Kubernetes «под капотом». Контейнеры работают либо на Docker‑хостах EC2, либо в режиме Amazon ECS.

Что запускали: REST‑службу для CRM‑портала (Java + PostgreSQL).
Процесс выкладки: код проходит тесты в GitHub Actions → образ отправляется в Beanstalk → сначала деплой в тестовое окружение, затем «синий‑зелёный» свитч на продакшен.
Масштабирование: если CPU выше 60 % — добавляется машина; ниже 30 % — убирается.
Подводные камни: при большой базе данных перенос трафика может занять время; нет тонких политик безопасности на уровне контейнеров.

Cloud.ru Service Stage. Ближе всего к Beanstalk: загружаем контейнер, получаем URL, доступны откаты и синие‑зелёные релизы.
Yandex Cloud Serverless Containers. Запускает контейнеры по событию и тарифицирует поминутно — удобно для нерегулярных нагрузок.
Selectel и VK Cloud. Предлагают управляемый Kubernetes и базовые PaaS‑сервисы, но полного аналога Beanstalk у них пока нет.

Начинайте с одного окружения, разделите на тест и прод позже.
Для старта хватит экземпляра t3.medium в режиме Unlimited — временные пики покрываются «бесплатно».
Описывайте настройки в .ebextensions, тогда перенос на другой аккаунт займёт минуты.
Следите за показателем LCU у балансировщика: он растёт вместе с нагрузкой.
Обновляйте платформу Beanstalk хотя бы раз в квартал, чтобы получать патчи безопасности.

AWS Elastic Beanstalk избавил нашу команду от рутины с виртуальными машинами и кластером Kubernetes, помог ускорить релизы и уменьшить ежемесячные счета. Он отлично подходит небольшим и средним проектам с постоянной нагрузкой.

Как мы упростили размещение сервисов и сократили расходы

О чём эта статья и какую боль она лечит

1. Зачем нам понадобился Elastic Beanstalk

2. Как это работает внутри

Масштабирование под нагрузкой

3. Что изменилось после перехода

4. Деньги: Beanstalk против EKS и Lambda

Когда выбрать EKS вместо Elastic Beanstalk

5. Наш боевой пример

6. Российские альтернативы

7. Советы тем, кто хочет попробовать

8. Итоги