«Куда деплоить сервис в AWS» — развилка с четырьмя ветками, и выбирается она по тому же принципу, что и остальные архитектурные развилки: не по моде, а по профилю задачи и цене эксплуатации.
Четыре варианта
EC2 — виртуальные машины. Полный контроль и полная ответственность: ОС, патчи, докер, рестарты, масштабирование через Auto Scaling Groups — всё ваше. Сегодня это выбор для особых случаев: специфичные требования к железу/ОС, перенос существующей инсталляции как есть. Новый сервис деплоить «на EC2 руками» — добровольно вернуться в эпоху до контейнеров.
ECS — контейнеры без Kubernetes. Оркестратор AWS: task definition (аналог Deployment), service (реплики + балансировка), запуск на своих EC2 или на Fargate — serverless-узлах, где про ноды не думают вовсе. Сильно проще Kubernetes концептуально (нет CRD, helm, операторов) и глубоко интегрирован с AWS (IAM task roles, ALB, CloudWatch из коробки). Цена — vendor-специфичность: знания и манифесты ECS не переносимы, экосистема инструментов несравнимо беднее.
EKS — managed Kubernetes. AWS держит control plane, ноды — managed node groups или Fargate. Вся k8s-серия применяется как есть; компании со своим k8s-опытом и multi-cloud амбициями выбирают его почти автоматически. Цена — кластер остаётся кластером: апгрейды, аддоны, IRSA, сетевые плагины — платформенная работа никуда не девается, она лишь уменьшается.
Lambda — функции. Код без серверов вовсе: событие → исполнение → оплата за миллисекунды. Идеальна для глю-кода: обработчик S3-события, реакция на SQS, крон-задачи, нечастые вебхуки.
Lambda и JVM: честные границы
Spring Boot-сервис в Lambda — возможно, но против шерсти. Холодный старт JVM с контекстом Spring — секунды; для синхронного API это видимая пользователю задержка. Лечения существуют — SnapStart (снимок прогретой JVM), provisioned concurrency (оплаченные тёплые экземпляры), GraalVM native image — но каждое добавляет сложности ровно там, где Lambda обещала простоту. Дальше — лимит времени исполнения (15 минут), модель «один запрос — один экземпляр» (пулы соединений к БД мгновенно становятся проблемой — нужен RDS Proxy), отладка и локальный запуск хуже контейнерных.
Честное правило: Lambda — для событийного глю-кода и редких задач; постоянный сервис с трафиком — в контейнер. «Перепишем все микросервисы на лямбды» — почти всегда дороже и медленнее, чем выглядело на слайде.
Критерии выбора
| EC2 | ECS/Fargate | EKS | Lambda | |
|---|---|---|---|---|
| Профиль | Особые требования | Постоянные сервисы, команда без k8s | Постоянные сервисы, команда с k8s | События, глю-код, крон |
| Эксплуатация | Вся ваша | Минимальная | Платформенная команда нужна | Почти нулевая |
| Переносимость | Высокая | Низкая (AWS-only) | Высокая | Низкая |
| JVM-дружелюбность | Полная | Полная | Полная | С оговорками (cold start) |
| Цена при постоянной нагрузке | Низкая (с резервированием) | Средняя | Средняя | Высокая |
| Цена при редких вызовах | Платите за простой | Платите за простой | Платите за простой | Около нуля |
Дефолт для команды этой программы: EKS, если в компании уже есть Kubernetes-практика; ECS/Fargate, если нет и multi-cloud не нужен; Lambda — точечно для событийного кода рядом. EC2 — по явной причине, записанной в ADR.
Типичные ошибки
- Lambda как универсальная архитектура. Сто лямбд вместо пяти сервисов: распределённый монолит с холодными стартами, где трассировка одного запроса проходит через десяток функций.
- EKS ради строчки в резюме платформы. Кластер без платформенной команды деградирует за год: непропатченные версии, аддоны-сироты. Без выделенных людей ECS честнее.
- EC2 со «своим докером» в 2026. Самодельный оркестратор из bash и systemd — это ECS, написанный плохо и без поддержки.
- Игнорировать выключение. Fargate/Lambda дороже за единицу ресурса, но дешевле за простой; стейджи и песочницы, работающие ночью и в выходные на EC2/EKS, — прямой слив бюджета.
Что почитать дальше
- Fundamentals — IAM-роли, которые сервис получает в каждом из вариантов.
- Kubernetes-серия — если выбор пал на EKS, всё там применимо дословно.
- Managed-данные — вторая половина выбора: где живут БД и очереди.
- Интеграция из Spring — код один и тот же во всех четырёх вариантах.