Вы написали сервис — теперь его надо где-то запустить, чтобы он работал круглосуточно и был доступен из интернета. В AWS для этого есть не один способ, а целых четыре, и каждый решает задачу «куда поселить код» по-своему. Новичка это сбивает с толку: какой выбрать и почему их так много?
Хорошая новость — выбор подчиняется простой логике. Все четыре варианта — это лестница от «полного ручного управления» до «вообще не думаю о серверах». Чем выше по лестнице, тем меньше у вас забот, но тем больше ограничений и (иногда) выше цена. Разберём каждую ступеньку на понятных аналогиях, а в конце дадим таблицу-шпаргалку и разбор типичных ошибок.
EC2 — виртуальные машины
EC2 (Elastic Compute Cloud) — это виртуальный компьютер в облаке. Представьте, что вы арендуете пустой системный блок: на нём есть операционная система, а всё остальное вы ставите и настраиваете сами. Установить рантайм, накатить обновления безопасности, поднять ваше приложение, перезапускать его если упало, добавлять новые машины при росте нагрузки — всё это ваша забота.
За это вы получаете максимальный контроль. Нужна конкретная версия ядра Linux, особое железо (GPU для машинного обучения), или вы переносите старое приложение «как есть» — EC2 даёт такую свободу.
Платой за свободу становится объём ручной работы. Запускать новый сервис «прямо на EC2 руками» сегодня почти никто не советует: это всё равно что собирать мебель без инструкции, когда рядом стоит готовый шкаф. Масштабирование настраивается через Auto Scaling Groups — механизм, который сам добавляет и убирает машины по нагрузке, но и его нужно сконфигурировать.
Запустить виртуальную машину можно из консоли в браузере, но в реальных проектах это делают командой или описанием в коде. Минимальный пример через AWS CLI:
aws ec2 run-instances \
--image-id ami-0abcdef1234567890 \
--instance-type t3.micro \
--key-name my-key
Здесь image-id — образ операционной системы, instance-type — размер машины (сколько процессора и памяти), key-name — ключ для входа по SSH. Уже из этого видно: про каждую такую деталь придётся думать вам.
ECS — контейнеры без Kubernetes
Сначала про контейнеры. Контейнер — это коробка, в которую упаковано ваше приложение вместе со всем, что ему нужно для работы (рантайм, библиотеки, настройки). Коробка одинаково запускается на ноутбуке и в облаке — «у меня работало, а на сервере нет» исчезает как класс. Самый популярный формат таких коробок — Docker.
ECS (Elastic Container Service) — это собственный сервис AWS для запуска контейнеров. Он берёт на себя роль управляющего: следит, чтобы нужное число копий приложения было запущено, распределяет к ним трафик, перезапускает упавшие. Ключевые понятия здесь два:
- task definition — рецепт: какой контейнер запускать, сколько ему дать памяти и процессора;
- service — указание «держи N работающих копий и балансируй между ними нагрузку».
У ECS есть два режима запуска. Можно крутить контейнеры на ваших EC2-машинах (тогда сами машины — снова ваша забота), а можно на Fargate — это режим, где вы вообще не видите серверов: говорите «запусти контейнер с такими-то ресурсами», и AWS сам находит, где его разместить. Fargate сильно упрощает жизнь: нет машин, которые надо патчить.
Плюс ECS — простота. Здесь нет сложных концепций Kubernetes (никаких CRD, Helm, операторов), а интеграция с остальным AWS работает из коробки: права доступа через IAM, балансировщик ALB, логи в CloudWatch. Минус — привязка к одному облаку. Знания и конфиги ECS не переедут в другое облако, а сторонних инструментов вокруг ECS заметно меньше, чем вокруг Kubernetes.
EKS — managed Kubernetes
Kubernetes (часто пишут k8s) — это открытый стандарт оркестрации контейнеров: тот же «управляющий», что и ECS, но не привязанный к AWS и с огромной экосистемой вокруг. Его сложность в том, что им надо управлять — а это отдельная работа.
EKS (Elastic Kubernetes Service) снимает часть этой ноши: AWS берёт на себя control plane — мозг кластера, который принимает решения о размещении контейнеров. А вот узлы (ноды, где реально крутятся контейнеры) остаются на вас — либо как managed node groups (AWS помогает их обновлять), либо снова на Fargate.
EKS выбирают, когда в компании уже есть опыт с Kubernetes или нужна переносимость между облаками: всё, что вы знаете про k8s, здесь применимо дословно. Если хотите глубже разобраться в самом Kubernetes — начните с основ, деплоя и конфигурации и эксплуатации.
Честная оговорка: кластер остаётся кластером. Обновления версий, дополнения (аддоны), настройка прав через IRSA, сетевые плагины — эта работа никуда не девается, её становится лишь меньше. Без человека, который этим занимается, кластер за год обрастает непропатченными версиями и заброшенными компонентами.
Lambda — функции
Lambda — это «код без серверов вообще». Вы загружаете кусок кода (функцию), а AWS сам запускает его в ответ на событие: пришёл файл в хранилище, прилетело сообщение в очередь, наступило время по расписанию. Платите только за миллисекунды, пока код реально работал; в простое — почти ноль.
Это идеально для клея между сервисами: обработать загруженную картинку, среагировать на сообщение, запустить задачу по расписанию, принять редкий веб-хук. Когда событий нет — вы не платите ни за что.
Lambda и тяжёлые сервисы: где проходит граница
Запустить полноценный backend-сервис целиком в Lambda технически можно, но это плавание против течения. Главная причина — холодный старт (cold start). Когда функцию долго не вызывали, при следующем вызове AWS поднимает её с нуля: для тяжёлого рантайма (например, среды с большим набором зависимостей, которая при запуске поднимает весь контекст приложения) это занимает секунды. Для синхронного API это задержка, которую пользователь видит своими глазами.
Лекарства есть, но каждое возвращает ту сложность, от которой Lambda обещала избавить:
- provisioned concurrency — заранее оплаченные «прогретые» экземпляры, которые всегда наготове;
- минималистичные рантаймы без тяжёлых фреймворков;
- SnapStart — снимок уже прогретого процесса, который восстанавливается за десятки миллисекунд (поддерживает Java, Python и .NET).
Дальше идут другие ограничения. Максимум 15 минут на один вызов — длинную задачу так не выполнить. Модель «один запрос — один экземпляр» ломает привычные пулы соединений к базе данных: каждый экземпляр открывает своё соединение, и база захлёбывается — приходится ставить прослойку вроде RDS Proxy. Отладка и локальный запуск тоже сложнее, чем у контейнеров.
Простое правило: Lambda — для событийного клея и редких задач; постоянный сервис с трафиком — в контейнер. Идея «перепишем все сервисы на функции» почти всегда оказывается дороже и медленнее, чем выглядела на презентации. Подробнее о serverless-подходе — в статье про serverless.
Сравнение и как выбрать
| EC2 | ECS/Fargate | EKS | Lambda | |
|---|---|---|---|---|
| Профиль | Особые требования | Постоянные сервисы, команда без k8s | Постоянные сервисы, есть опыт k8s | События, клей, расписание |
| Ручной труд | Весь на вас | Минимальный | Нужны люди под платформу | Почти нулевой |
| Переносимость | Высокая | Низкая (только AWS) | Высокая | Низкая |
| Дружелюбность к рантайму | Полная | Полная | Полная | С оговорками (cold start) |
| Цена при постоянной нагрузке | Низкая (с резервированием) | Средняя | Средняя | Высокая |
| Цена при редких вызовах | Платите за простой | Платите за простой | Платите за простой | Около нуля |
Ориентир для большинства команд: есть опыт Kubernetes — берите EKS; нет, и второе облако не нужно — ECS/Fargate; для событийного кода рядом — Lambda точечно. EC2 — только когда есть явная причина, которую вы можете записать и обосновать.
Запуск сервиса — это лишь начало. Дальше встаёт вопрос, как доставлять туда новые версии кода без простоя: про это — статьи о принципах пайплайнов и стратегиях релизов.
Где это применяется
Этот выбор делает каждая команда при запуске первого сервиса в AWS, и он определяет всю дальнейшую эксплуатацию — поэтому ошибиться здесь дорого. Вот что чаще всего идёт не так у новичков:
- Lambda как универсальная архитектура. Сто функций вместо пяти сервисов превращаются в запутанный клубок: один запрос пользователя проходит через десяток функций, каждая со своим холодным стартом, а проследить путь запроса почти невозможно.
- EKS «потому что модно». Кластер без человека, который им занимается, деградирует за год. Если выделенной команды под платформу нет — ECS честнее и спокойнее.
- EC2 со «своим Docker» в 2026. Самодельный оркестратор из bash-скриптов и systemd — это тот же ECS, только написанный плохо и без поддержки.
- Забыть выключать ненужное. Fargate и Lambda дороже за единицу ресурсов, но дешевле в простое; стейджи и песочницы, которые молотят на EC2/EKS по ночам и выходным, — прямой слив бюджета. Про это подробнее — в статье об оптимизации затрат.
Что изучить дальше:
- Основы AWS — как устроены аккаунты, регионы и базовые сервисы.
- IAM — права доступа, которые сервис получает в каждом из вариантов запуска.
- Масштабирование и доступность — как переживать рост нагрузки и отказы.
- Managed-данные — где будут жить базы данных и очереди, к которым обращается сервис.
- Интеграция с AWS SDK — код обращения к сервисам AWS почти одинаков во всех четырёх вариантах.