Google Cloud Run против AWS Lambda — что выбрать для нового проекта в 2026?

[rotov]

Стартуем новый проект — REST API, Python, трафик непредсказуемый (стартап, может быть 100 req/день, может быть 100k). Бюджет ограничен. Команда знает оба облака поверхностно. Смотрим на Lambda vs Cloud Run. Читал сравнения, но они в основном 2024-2025 года. Что актуально сейчас? Особенно интересует реальная разница в стоимости при низком и среднем трафике.

[timur12]

На низком трафике Cloud Run выигрывает за счёт concurrent requests. Один инстанс Cloud Run может обрабатывать до 1000 одновременных запросов (настраивается). Lambda — один инстанс, один запрос. Если у тебя 100 одновременных запросов, Lambda поднимет 100 инстансов, Cloud Run — 1. Это напрямую влияет на стоимость и на cold starts.

[tayheba]

@rotov, Lambda удобнее интегрируется с остальным AWS: EventBridge, SQS, S3 triggers, API Gateway — всё через консоль за 5 минут. На GCP это тоже есть (Pub/Sub, Cloud Scheduler), но документация хуже и learning curve ощутимее, если команда не знает GCP. Если остальная инфра на AWS — Lambda естественный выбор.

[dmsmith]

Мы полгода назад выбирали. Остановились на Cloud Run по одной причине — деплой Docker-контейнера. Один Dockerfile, один образ, тест локально через docker-compose, деплой в Cloud Run. С Lambda нужен SAM или Serverless Framework, и всё равно поведение локально и в проде отличается. Для питонщиков без глубокого DevOps-опыта Cloud Run проще.

[alansmit]

По ценам на июнь 2026: Lambda — $0.20 за млн запросов + $0.0000166667 за GB-сек. Cloud Run — $0.0025 за vCPU-сек + $0.00000250 за GB-сек. При высоком concurrent трафике Cloud Run дешевле в 3-5 раз из-за мультиплексирования. При редких коротких задачах Lambda может быть дешевле. Для вашего случая (стартап, непредсказуемый трафик) я бы смотрел на Cloud Run.

[Omoto]

Добавлю: Cloud Run в 2026 поддерживает GPU-инстансы (L4, T4) — если вдруг понадобится ML-инференс, не придётся переезжать. У Lambda с GPU история пока скромнее. Ещё Cloud Run умеет request-based и instance-based биллинг — можно переключаться в зависимости от паттерна нагрузки.

[depechie]

@timur12, Идея верная, но с concurrency=1000 на Python жирный нюанс. Эта цифра реально работает только если приложение async (FastAPI на uvicorn без блокирующих вызовов). Если внутри синхронный код, gunicorn с воркерами и GIL — ты не отдашь 1000 параллельно, упрёшься в CPU и запросы встанут в очередь внутри инстанса. Тогда concurrency крутят вниз, под число воркеров (8-16-80), и преимущество над Lambda по числу инстансов уже не такое драматичное. 1000 — это про I/O-bound, а не универсальная настройка.

[tastee]

@dmsmith, Про Docker соглашусь, но разрыв с Lambda тут подсократился — Lambda давно умеет container images до 10 ГБ, можно катить тот же Dockerfile без SAM-специфики. Чего у Lambda всё равно нет — честного локально=прод: lifecycle инстанса, заморозка/разморозка, лимит 15 минут и поведение под нагрузкой локально нормально не воспроизвести. В Cloud Run docker-compose на машине реально ближе к тому что будет в проде.

[ohavt]

Момент мимо которого тред прошёл — cold start при нуле трафика. У стартапа со 100 req/день инстанс будет регулярно скейлиться в ноль, и первый запрос после простоя ловит холодный старт на обоих. На Cloud Run это лечится min-instances=1 и стоит копейки — один тёплый инстанс на минимальном CPU. На Lambda — provisioned concurrency, и вот она уже заметно дороже. Если важна стабильная latency на первом запросе, закладывайте это в расчёт сразу, а не потом.