Варианты вычислений: EC2, ECS/Fargate, Lambda, App Runner
Вычисления в AWS — это спектр от наибольшего контроля и операций к наименьшим: EC2, ECS-на-EC2, Fargate, Lambda, App Runner. Выбирай по форме нагрузки, а не по хайпу, и закладывай ловушки каждого уровня.
Команда выкатывает сервис генерации превью на Lambda, потому что «serverless дешевле». Полгода всё работает прекрасно — пока маркетинговая акция не заливает аплоады, несколько 4K-исходников не выталкивают обработку за 15 минут, и функция начинает падать по таймауту посреди задачи без частичного результата. Хуже того, функции живут в VPC, чтобы достучаться до приватной базы, поэтому каждый cold start теперь ещё и ждёт подключения сетевого интерфейса (ENI). Решением было не «дожать» Lambda. Решением было признать, что нагрузка переросла уровень — стала долгой, тяжёлой, постоянной — и перенести её в Fargate-таск. Выбор вычислений — это выбор ограничений, и ограничения необязательными не бывают.
Спектр: контроль против операционной нагрузки
Каждый вариант вычислений AWS лежит на одной оси. На одном конце — EC2, голые виртуальные машины. Ты получаешь полную операционную систему, root-доступ, любой тип инстанса вплоть до GPU и bare-metal и полный контроль. Цена этого контроля — ты владеешь всем выше гипервизора: патчинг ОС, autoscaling-группа, проводка балансировщика, планирование ёмкости и дежурство, когда хост деградирует. EC2 — это фундамент, на котором стоит всё остальное, и он никуда не девается: Fargate и Lambda — это та же EC2-ёмкость, которой AWS управляет за тебя.
На шаг внутрь — ECS на EC2: ты по-прежнему запускаешь и оплачиваешь EC2-инстансы (контейнерные хосты), но ECS планирует твои контейнеры на них. Ты отдал оркестрацию контейнеров и оставил управление нодами. Ещё шаг — и ноды исчезают: ECS или EKS на Fargate — это serverless-контейнеры. Нет инстанса, который надо патчить, масштабировать или подгонять по размеру: ты объявляешь vCPU и память таска, AWS находит ёмкость, и ты платишь за таск по времени его работы. Ты отдаёшь доступ к хосту (нет SSH, нет daemonset, нет GPU) в обмен на то, чтобы больше никогда не думать о ноде.
Дальше — Lambda: ты не отгружаешь даже контейнерный хост или долгоживущий процесс — ты отгружаешь функцию. AWS запускает её в ответ на событие (HTTP-запрос через API Gateway, загрузку в S3, сообщение SQS), масштабирует от нуля до тысяч одновременных выполнений автоматически и тарифицирует по миллисекундам выполнения. Платой служит жёсткая форма: максимум 15 минут на выполнение, cold start, когда нужно поднять новое окружение выполнения, и событийная модель программирования. На дальнем конце — App Runner: укажи на образ контейнера или репозиторий, и он соберёт, задеплоит, отбалансирует, терминирует TLS и автомасштабирует веб-сервис за тебя. Это наименьшая операционная нагрузка и наименьшая гибкость: управляемый фасад ровно для одной формы — stateless HTTP-сервиса.
Четыре измерения, которые решают уровень
Не сравнивай их по названиям — сравнивай по поведению. Их разделяют четыре измерения, и ответы нагрузки указывают прямо на уровень.
Операционная модель — кто владеет ОС и парком. EC2: ты, целиком. ECS-на-EC2: ты владеешь хостами, AWS планирует контейнеры. Fargate/Lambda/App Runner: AWS владеет хостом; ты владеешь только своим кодом и его конфигом.
Модель масштабирования — как ёмкость следует за нагрузкой. EC2 масштабируется autoscaling-группой — ты задаёшь политики, а новые инстансы поднимаются и прогреваются минутами. Fargate масштабирует таски (всё ещё десятки секунд на старт таска). Lambda масштабируется одновременными выполнениями почти мгновенно и уникально масштабируется до нуля — в простое ты не платишь ничего. App Runner автомасштабирует concurrency по запросам за тебя.
Модель тарификации следует за масштабированием. EC2 тарифицирует за инстанс-час работы независимо от загрузки (on-demand, или куда дешевле через Savings Plans / Spot). Fargate тарифицирует за выделенные vCPU и память таска на всё время его жизни. Lambda тарифицирует за запрос плюс GB-секунды фактического выполнения, округляя до миллисекунды — в простое действительно ноль. App Runner тарифицирует за provisioned + active compute.
Латентность / поведение cold start — то, о чём команды забывают. У EC2 и постоянно работающих Fargate-тасков нет cold start на запрос — они уже прогреты. Lambda платит cold start (десятки мс для лёгкого рантайма, до секунд для тяжёлого JVM/.NET или большого пакета) каждый раз, когда нужно создать новое окружение выполнения, и платит дополнительную латентность cold start, если функция в VPC и должна подключить ENI. App Runner держит тёплый пул, но может уменьшать число provisioned-инстансов, со своим прогревом на холодном пути.
| Измерение | EC2 | Fargate | Lambda | App Runner |
|---|---|---|---|---|
| Операционная нагрузка | Наибольшая — ты патчишь ОС | Низкая — без нод | Низкая — только код | Наименьшая — управляемый |
| Масштабирование | ASG, минуты на старт | За таск, ~десятки сек | За выполнение, почти мгновенно, до нуля | По запросам, управляемое |
| Тарификация | За инстанс-час (Spot/SP дешевле) | За vCPU + память таска | За запрос + GB-сек (ноль в простое) | Provisioned + active compute |
| Cold start | Нет (тёплый парк) | Нет, если запущен | Да — хуже в VPC, хуже для JVM/.NET | Тёплый пул; прогрев при scale-up |
| Жёсткие лимиты | Нет (хост твой) | Нет GPU, нет доступа к хосту | Макс. 15 мин, 10 ГБ памяти, нет GPU | Только HTTP-веб-сервис |
▸Почему это работает
«Serverless» — это не одно и то же. Fargate — serverless-контейнеры: ты всё равно выделяешь vCPU/память на таск, и таск работает непрерывно, пока существует, поэтому у него нет cold start на запрос, но и сам до нуля он не масштабируется. Lambda — serverless-функции: масштабируется до нуля и тарифицируется по миллисекундам, но платит cold start и упирается в 15 минут. Они решают разные задачи: Fargate убирает управление нодами для постоянной или долгой работы; Lambda убирает стоимость простоя для всплесковой или событийной работы. Тянуться к «serverless», не уточняя, к какому, — обычно значит выбрать неверный трейдофф.
Выбор по форме нагрузки
Сеньоры не выбирают любимый уровень и не гнут под него нагрузки; они читают нагрузку и дают ей выбрать. Несколько канонических форм:
Постоянный высоконагруженный сервис — занятый API, обрабатывающий тысячи запросов в секунду круглосуточно, — хочет EC2 или Fargate. При постоянной высокой утилизации тарификация за инстанс или за таск выгоднее, чем за запрос у Lambda, а у тёплого парка нет налога cold start. Бери EC2, когда нужен контроль на уровне инстанса или самые дешёвые постоянные вычисления через Spot/Savings Plans; бери Fargate, когда не хочешь управлять нодами.
Всплесковая или событийная нагрузка — обработчик вебхуков, пайплайн по триггеру S3, cron-задача, трафик, почти нулевой ночью, — хочет Lambda. Scale-to-zero значит, что в провалах ты не платишь ничего, а масштабирование за запрос гасит всплески, которые иначе заставили бы autoscaling-группу держать запас впрок. Только держи каждый вызов коротким и stateless.
Простое контейнерное веб-приложение, которое ты не хочешь обслуживать — внутренний инструмент, небольшой продуктовый сервис, пет-проект, который не должен превратиться в операционную работу, — хочет App Runner (или Fargate, если нужен больший контроль). Запушил образ — получил URL, автомасштабирование и TLS в комплекте.
А всё, что требует контроля на уровне ОС или GPU — сервис с настройкой ядра, кастомный сетевой стек, ML-инференс или обучение на GPU, софт с bare-metal-лицензированием, — обязано использовать EC2. У Fargate нет GPU и доступа к хосту, а у Lambda нет ни того, ни другого плюс стена в 15 минут, поэтому они просто выбывают.
Ночной батч-джоб обрабатывает очередь больших медиафайлов; отдельные файлы транскодируются 25–40 минут, а большую часть дня очередь пуста. Выбери вычисления.
Нагрузка работает непрерывно с высоким, почти постоянным трафиком 24/7. Какая модель тарификации, скорее всего, дешевле всего?
Твои Lambda-функции в VPC, чтобы достучаться до приватной базы RDS, и тормозят на первом запросе после простоя. Самая вероятная причина?
- 01Разложи спектр вычислений AWS от наибольшего контроля к наименьшему и то единственное, что отдаёшь на каждом шаге.
- 02Дай правило выбора уровня под нагрузку с каноническими формами и ловушками.
Вычисления AWS — единый спектр от наибольшего контроля и операций к наименьшим: EC2 даёт голые VM и полный контроль ценой владения ОС, масштабом и патчингом; ECS на EC2 отдаёт планирование контейнеров, но оставляет управление нодами; Fargate — serverless-контейнеры без нод под управлением, с тарификацией за vCPU и память таска; Lambda — событийные функции, масштабирующиеся до нуля и тарифицируемые по миллисекундам, но с потолком 15 минут и платой за cold start; App Runner — полностью управляемый веб-сервис, самый простой в эксплуатации и наименее гибкий. Выбирай по форме нагрузки на четырёх измерениях — операционная модель, масштабирование, тарификация и латентность cold start. Постоянный высокий трафик тяготеет к EC2 или Fargate; всплесковая или событийная работа — к scale-to-zero у Lambda; простое веб-приложение, которое не хочешь обслуживать, — к App Runner или Fargate; а всё, что требует GPU или контроля на уровне ОС, вынуждает EC2, потому что у Fargate нет GPU и доступа к хосту, а Lambda добавляет стену в 15 минут и латентность cold start (хуже внутри VPC). Навык не в том, чтобы любить один уровень, — а в том, чтобы прочитать нагрузку и принять ограничения самого дешёвого уровня, в который она реально помещается. Теперь, когда увидишь, что команда по умолчанию тянется к Lambda, твой первый вопрос: какова длительность, форма трафика и нужен ли контроль ОС? Три ответа выбирают уровень раньше, чем написана первая строчка инфраструктурного кода.
Практика
Начни сверху. Задачи идут от простого к сложному: вспомнить факт, применить к случаю, затем senior-уровень. Открой, попробуй, потом открой ответ.
Что-то непонятно?
Задай вопрос по этому уроку. Вопросы анонимны и попадают напрямую автору — урок станет лучше.