Serverless и традиционный VPS: когда «бессерверная» архитектура выходит дороже сервера

Serverless-платформы вроде AWS Lambda обещают революцию: платите только за реальное время выполнения кода, забудьте об управлении серверами, масштабируйтесь автоматически. Звучит как мечта для любого CTO. Но когда приходит счёт за месяц работы, многие обнаруживают неприятную правду: «бессерверная» архитектура может обходиться в разы дороже обычного VPS. Разбираемся, где проходит граница между экономией и переплатой.

Обещание и реальность: что такое serverless на самом деле

Serverless (Function-as-a-Service, FaaS) — это модель, при которой вы загружаете код в виде функций, которые запускаются по требованию. AWS Lambda управляет всеми ресурсами, необходимыми для выполнения функции, автоматически масштабируется от нуля до тысяч одновременных выполнений, взимая плату только за фактическое время вычислений.

Звучит идеально, правда? Но дьявол, как всегда, в деталях.

Cold starts: невидимая проблема латентности

Cold start происходит, когда AWS Lambda должен инициализировать новый контейнер для выполнения кода из-за отсутствия предварительно прогретых ресурсов. Этот процесс включает выделение ресурсов, настройку среды выполнения и загрузку пакета развёртывания, что может добавить значительную задержку — часто несколько секунд для некоторых языков, таких как Node.js или Python, и ещё дольше для других, таких как Java или .NET.

Cold path: 150–800ms дополнительной задержки от serverless cold starts после периодов простоя. Warm path: почти идентичная производительность после прогрева функций.

Конкретные цифры по языкам:

Python и Node.js обычно имеют более быстрые cold starts в диапазоне 200-400 миллисекунд, в то время как Java и C# исторически страдали от задержек cold start в диапазоне 500-700 миллисекунд
VPC делают cold starts в 4 раза хуже. Большие node_modules (>50MB) усугубляют задержки

Для пользовательских API, где каждая миллисекунда критична, это может быть катастрофой. Cold starts наиболее болезненны при работе с клиентскими потоками, где производительность критична, даже для 1% клиентов. Например, если у вас есть микросервисы для аутентификации или авторизации, которые должны работать с высоким уровнем параллелизма и завершать выполнение менее чем за десяток миллисекунд, дополнительные 1% с 0.5-1 секунды могут стать решающим фактором.

Ценообразование: когда цифры говорят правду

Некоторые провайдеры используют модель оплаты по факту:

$0.20 за 1 миллион запросов ($0.0000002 за запрос)
Месячная стоимость вычислений составляет $0.0000166667 за GB-секунду
Бесплатный tier: 1 миллион запросов и 400,000 GB-секунд в месяц

Звучит дёшево? Давайте посчитаем реальный пример:

Предположим, ваше приложение обрабатывает три миллиона запросов в месяц. Средняя продолжительность выполнения функции составляет 120 мс. Вы настроили функцию с 1536 МБ памяти на процессоре x86. Общее время вычислений (секунды) = 3 миллиона × 120ms = 360,000 секунд. Общее время вычислений (GB-s) = 360,000 × 1536MB/1024 MB = 540,000 GB-s. Общее время вычислений – бесплатный tier = 540,000 GB-s – 400,000 бесплатных GB-s = 140,000 GB-s.

Месячная стоимость вычислений = 140,000 × $0.0000166667 = $2.33

Выглядит выгодно! Но теперь сравним с VPS:

Приложение SaaS среднего размера, работающее 24/7, может стоить $20–$60/месяц на VPS, в то время как на serverless будет стоить намного больше.

Критический момент: это расчёт для переменной нагрузки. Для постоянной нагрузки математика меняется кардинально.

Когда serverless становится дорогим

Постоянная нагрузка — это любое приложение или сервис, которое должно быть постоянно доступно и работать. Это описывает ядро большинства веб-приложений. Запуск их на модели «оплата за миллисекунду» serverless — это место, где логика ломается, а затраты взрываются.

Lambda может работать максимум 15 минут. У них есть ограничения по памяти и размеру пакета. Вы привязаны к их конкретному способу ведения дел. VPS — это чистый холст.

Скрытые расходы: что не учитывают калькуляторы

Egress fees: налог на ваши данные

Самая болезненная «скрытая» стоимость — это egress fees (плата за передачу данных из облака).

AWS взимает значительно больше за передачу данных, чем конкуренты, при этом стоимость исходящих данных начинается с $0.09 за ГБ по сравнению с фиксированной ставкой DigitalOcean в $0.01 за ГБ для всех типов передачи данных. Сложная структура ценообразования AWS включает дорогостоящие межрегиональные сборы за передачу в размере $0.02 за ГБ, что означает, что вы платите дополнительно только за перемещение данных между разными зонами доступности AWS в вашей собственной инфраструктуре.

Реальная наценка поражает: Исследование от Cloudflare оценивает, что клиенты в США, Канаде и Европе платят в 80 раз больше затрат Amazon. Клиенты в Южной Америке платят в 21 раз больше затрат Amazon. Клиенты в Японии и Сингапуре платят в 17 раз больше затрат Amazon.

Provisioned Concurrency: плата за отсутствие cold starts

Provisioned Concurrency — это функция AWS Lambda, которая позволяет разработчикам указать количество экземпляров функций, которые всегда инициализированы и готовы к немедленному ответу на вызовы. Поддерживая указанное количество предварительно прогретых экземпляров, Provisioned Concurrency устраняет cold starts для этих экземпляров, обеспечивая стабильную и предсказуемую производительность. Хотя Provisioned Concurrency может значительно снизить задержку, она также влечёт дополнительные расходы, поскольку предварительно прогретые экземпляры оплачиваются независимо от того, активно ли они обрабатывают запросы.

Функция 1GB с 10 одновременными выполнениями, 5M ежемесячных вызовов по 200ms: Idle = $30.42, Execution = $97.22, Requests = $0.80 → Итого = $128.44/месяц против $17 стандартный Lambda.

Другие скрытые расходы

VPC Networking Costs: функции в VPC требуют ENI с потенциальными расходами: NAT Gateway ($0.045/час + $0.045/GB), VPC endpoints для сервисов AWS ($0.01/час + $0.01/GB) и PrivateLink для интеграций третьих сторон. Они могут превышать затраты на вычисления Lambda для архитектур с большой нагрузкой на VPC. CloudWatch Logs Storage: Lambda автоматически логирует в CloudWatch: $0.50/GB прием, $0.03/GB/месяц хранение. Подробное логирование для функций с большим объёмом (10M+ вызовов) может стоить $50-200/месяц.

Vendor lock-in: ловушка проприетарных сервисов

Различные платформы serverless, такие как AWS Lambda, Google Cloud Functions и Azure Functions, имеют свои собственные среды выполнения и API. Миграция serverless-приложений между этими платформами может быть сложной и трудоёмкой. Serverless-функции часто полагаются на триггеры событий от других сервисов в рамках того же облачного провайдера (например, AWS S3, DynamoDB). Перенастройка этих триггеров для работы с сервисами другого провайдера требует значительных усилий.

Истинная опасность lock-in, особенно с serverless, — это потенциал data lock-in. Данные обладают гравитацией. Они накапливаются. Данные экономически не мотивированы покидать платформу из-за структуры цен платформы. Это самая большая угроза выбору провайдера.

DHH отметил, что 37signals стоило «сотни тысяч долларов» переместить 6-7 петабайт данных из GCP из-за расходов на egress (хотя 37Signals смогли договориться об использовании кредитов для оплаты части расходов). «Вся эта идея о том, что облако даст вам мобильность, не была действительно правдой», — сказал DHH.

Кейс 37signals: $10M экономии за 5 лет

Самый громкий пример миграции с облака — это история компании 37signals (создатели Basecamp и HEY).

В 2022 году CTO 37signals Дэвид Хайнемайер Ханссон (создатель Ruby on Rails) начал уходить из AWS после ужаса от годовых расходов, превышающих $3.2 миллиона.

Результаты впечатляют:

«Наши расходы на облако уже снизились на 60%, с примерно $180,000 в месяц до менее чем $80,000», — написал DHH. «Нам не нужно напрягаться, чтобы увидеть, как возможная экономия поднимется до примерно $2 миллионов в год. Это будет $10 миллионов за пять лет».

В 2024 году он поделился результатами проекта по репатриации вычислений: после траты $700,000 на серверы Dell, которые выполняют рабочие нагрузки, ранее размещённые в AWS, счета за облако упали примерно на $2 миллиона в год.

«Мы ушли чуть более года назад, и команда, управляющая всем, всё та же. Не было скрытых драконов дополнительных рабочих нагрузок, связанных с выходом, которые потребовали бы нам раздуть команду, как предполагали некоторые наблюдатели, когда мы это объявили».

Что критично в этом кейсе

Удобство облака позиционирует вас для роста с мощностью по требованию, но делает это со значительными затратами. По мере того как бизнес созрел, его потребности в инфраструктуре стали более предсказуемыми и стабильными.

Мы всё ещё думаем, что облако имеет место для компаний, достаточно ранних в своём жизненном цикле, что расходы либо несущественны, либо риск того, что их не будет через 24 месяца, высок. Просто будьте осторожны, чтобы не смотреть на эти щедрые облачные кредиты как на подарок! Это крючок. И если вы слишком привяжетесь к их проприетарным управляемым сервисам или serverless-предложениям, вам будет очень трудно сбежать, когда счета начнут расти.

Когда serverless действительно имеет смысл

Не всё так плохо. Serverless блестяще работает в следующих сценариях:

1. Burst-трафик и event-driven задачи

Serverless автоматически масштабирует функции по запросу, поэтому графики масштабируемости благоприятствуют FaaS во время всплесков трафика.

Примеры:

Обработка загрузок файлов
Webhook-обработчики
Периодические задачи (резервное копирование, отчёты)
Image/video processing по требованию

2. Малый стабильный трафик

При малом трафике e-commerce приложение стоит ~$1.6/месяц (включая бесплатный tier), а блог ~$0.5$. Для сравнения, стоимость в месяц самого маленького EC2 VM, t3a.nano, составляет $3.43. Результат: Преимущество serverless.

3. Прототипы и MVP

Для стартапов в фазе валидации идеи serverless идеален:

Нулевые затраты на инфраструктуру до запуска
Быстрое развёртывание
Автоматическое масштабирование при успехе
Free tier покрывает большинство экспериментов

4. Непредсказуемая нагрузка

Такая непредсказуемость — это место, где облако сияет, предоставляя ресурсы, когда неясно, сколько серверов вам нужно. Например, при запуске HEY неожиданный приток 300,000 пользователей в течение трёх недель опроверг их шестимесячный прогноз в 30,000.

Когда VPS — правильный выбор

1. Постоянная 24/7 нагрузка

Сервис, который всегда работает, накапливает оплачиваемые миллисекунды каждую секунду каждого дня. Ваш месячный счёт становится пугающей переменной, которая может взлететь без предупреждения. High-RAM VPS имеет фиксированную месячную стоимость. Это предельная предсказуемость цен.

2. Long-running процессы

Lambda-функции могут работать максимум 15 минут. У них есть ограничения по памяти и размеру пакета. VPS — это stateful по своей природе, что означает, что ваши приложения могут хранить данные в памяти и работать столько, сколько вы хотите. Нужно запустить скрипт анализа данных, который занимает 3 часа? Нет проблем.

3. WebSocket и persistent connections

Serverless-функции stateless по определению. Если вашему приложению нужны:

WebSocket-соединения
Длительные HTTP-соединения
In-memory кэши
Shared state между запросами

VPS — единственный вариант.

4. Высокий объём данных

При больших объёмах данных egress fees становятся критичными:

Основные, часто упускаемые затраты облачных платформ — это «data egress» — плата, которую они взимают с вас за отправку данных из их сети. Если ваше приложение обслуживает большие файлы, генерирует отчёты или предоставляет API-ответы с большим объёмом данных, эти сборы за egress могут легко затмить ваши затраты на вычисления.

Для приложений, обслуживающих:

Видео-контент
Большие файлы
API с большими payload
Backup/restore операции

VPS с неограниченной (или дешёвой) исходящей полосой пропускания будет намного выгоднее.

Практические рекомендации

Для serverless-архитектуры

Мониторьте холодные старты:

Используйте AWS X-Ray для отслеживания продолжительности функции с холодным стартом
Оптимизируйте размер пакета
Минимизируйте зависимости

Контролируйте egress:

CDN не только помогают в более быстрой передаче данных, но также снижают общую стоимость. Amazon Cloudfront — это сеть доставки контента, которая быстро передаёт данные с низкой задержкой
Используйте VPC Endpoints для AWS-сервисов
Держите связанные сервисы в одной зоне доступности

Избегайте vendor lock-in:

Используйте Hexagonal architecture, где ваше приложение изолировано от внешних зависимостей. Ваши затраты на миграцию будут снижены, так как основной код вашего приложения не изменится во время миграции, и вам нужно будет только написать и подключить новые адаптеры к нему
Избегайте проприетарных сервисов для критичной логики
Используйте стандартные языки и протоколы

Для VPS-архитектуры

Автоматизация:

Используйте IaC (Infrastructure as Code)
Настройте CI/CD пайплайны
Автоматизируйте мониторинг и алертинг

Managed services:

Используйте managed database сервисы
Делегируйте резервное копирование провайдеру
Рассмотрите managed Kubernetes для контейнеров

Hybrid-подход:

Stable core на VPS
Burst workloads на serverless
Static assets на CDN
Критичные данные на собственных серверах

Гибридный подход: лучшее из обоих миров

Самые умные облачные архитектуры 2025 редко выбирают одну сторону. Они смешивают микросервисы, размещая VPS serverless стеки: держите обработчики API edge в Functions для эластичности. Направляйте тяжёлую обработку в пул контейнеров на облачном VPS. Делитесь токенами аутентификации через центральный экземпляр Redis. Этот паттерн балансирует компромиссы масштабируемости и ограничивает месячный счёт.

Примеры распределения:

VPS: основная база данных, application server, кэш
Serverless: обработка изображений, webhook handlers, фоновые задачи
CDN: статические файлы, медиа-контент

Выводы: математика решает всё

Serverless — не панацея и не мошенничество. Это инструмент, и как любой инструмент, он имеет свою область применения.

Serverless выигрывает когда:

Нагрузка непредсказуема или спайковая
Малый объём трафика (в пределах free tier)
Event-driven архитектура
Короткие задачи (<15 минут)
Нужна нулевая операционная нагрузка

VPS выигрывает когда:

Стабильная 24/7 нагрузка
Long-running процессы
Высокий объём данных
Нужны persistent connections
Критична предсказуемость бюджета

Если вы запускаете VMs или Kubernetes в публичном облаке, вы почти наверняка делаете это неправильно. В облаке мы должны арендовать сервисы, а не серверы.

Главное правило: считайте математику для вашего конкретного случая. 37signals первоначально ожидали операционной экономии в $7 миллионов за следующие пять лет, но ваши цифры могут быть совершенно другими.

Рынок облачных сервисов созрел. Теперь выбор между serverless и VPS — это не вопрос технологической моды, а вопрос холодного расчёта TCO (Total Cost of Ownership). И часто этот расчёт указывает на старый добрый VPS.