Спор «serverless или Kubernetes» начался ещё в конце 2010-х, прошёл долгий путь и к 2026 году выглядит иначе. Платформы возмужали, FinOps превратился из модного слова в обязательную практику, а облачные счета продолжают расти быстрее, чем хотелось бы финансовым директорам. Маркетинг по-прежнему обещает «платите только за то, что используете» в случае serverless (без серверов) и «полный контроль и предсказуемость» — в случае Kubernetes. На практике обе формулировки скрывают важные нюансы, и неправильный выбор модели легко влечёт за собой утечку бюджета.
В этой статье разберём, как устроена стоимость облака в обеих архитектурах, в каких сценариях serverless экономит деньги, а в каких — становится дороже Kubernetes, и какие практики FinOps помогают не переплачивать вне зависимости от выбранной модели.
Как формируется стоимость облака в serverless и Kubernetes
Сравнивать две архитектуры «в лоб» нельзя — у них принципиально разные модели тарификации. Прежде чем переходить к сценариям, важно понять логику начисления расходов.
Serverless и FaaS: оплата по факту вызова
В модели serverless, или FaaS (функция как сервис), пользователь платит за три вещи: количество вызовов функций, фактическое время выполнения с точностью до миллисекунд и объём выделенной памяти. Когда нагрузки нет, нет и счёта. Звучит как идеальная финансовая модель, особенно для нерегулярных задач. Но логика тарификации включает зависимости от связанных сервисов и нюансы, о которых поговорим ниже.
Kubernetes: оплата за выделенные ресурсы
Кластер Kubernetes потребляет ресурсы постоянно — простаивает он или работает в полную силу. Расходы предсказуемы и фиксированы по времени, но требуют грамотной оптимизации размера нод, настройки автоскейлеров и постоянного мониторинга загрузки. При высокой утилизации стоимость на единицу нагрузки получается низкой — потому что амортизируется на всём объёме обработанных запросов. При простое вы платите за «воздух».
Когда serverless снижает стоимость облака
Есть несколько сценариев, где FaaS действительно экономит деньги по сравнению с контейнерами.
Нерегулярный и пиковый трафик
Сайт с резкими всплесками трафика, обработчики событий от внешних систем, задачи по расписанию, которые запускаются раз в сутки или реже. Платить за работающий 24/7 контейнер ради обработки нескольких тысяч событий в сутки — переплата. Serverless здесь выигрывает за счёт того, что счёт пропорционален реальной нагрузке.
Событийные конвейеры и фоновая обработка
Загрузка файла в объектное хранилище → запуск функции → обработка → запись результата в очередь. Связки serverless с брокерами сообщений, объектными хранилищами и базами данных стали отраслевым стандартом для асинхронной обработки. Здесь FaaS даёт не только экономию, но и упрощает архитектуру.
MVP и продукты с непредсказуемой нагрузкой
Пока команда не понимает, как поведут себя пользователи, serverless позволяет не закладываться на инфраструктуру вперёд. Стоимость облака растёт пропорционально успеху продукта, а не вперёд него. Для стартапа на ранней стадии это критично: не нужно держать кластер, который будет крутиться вхолостую первые месяцы.
Когда Kubernetes выгоднее, чем serverless
Те же причины, по которым serverless хорош на «рваной» нагрузке, превращаются в недостатки при стабильном трафике.
Стабильно высокий трафик
При постоянной утилизации кластер Kubernetes с резервированными нодами обходится существенно дешевле, чем эквивалентное количество вызовов FaaS. Точка перелома индивидуальна и зависит от конфигурации, но отрасль сходится на том, что на отметке в десятки миллионов запросов в месяц контейнерные платформы почти всегда выгоднее. Случаи миграции с FaaS обратно на контейнерные платформы или управляемый Kubernetes с экономией в разы — уже не редкость.
Длительные задачи и тяжёлые вычисления
У стандартных serverless-функций есть жёсткий лимит времени выполнения: обычно до пятнадцати минут. Это делает FaaS неподходящим для пакетной обработки больших объёмов данных, перекодирования видео, конвейеров обработки данных с длительными SQL-запросами, обучения моделей машинного обучения. В Kubernetes таких ограничений нет — кластер свободно держит длительные задачи.
Сервисы, чувствительные к задержкам
Холодный старт — задержка при «холодном» вызове функции, которая может составлять сотни миллисекунд для лёгких сред исполнения и несколько секунд для Java или .NET без специальных оптимизаций. Для пользовательского API, где важна стабильная задержка ответа, это критично. Решение в виде резерва предварительно инициализированных экземпляров (provisioned concurrency) фактически возвращает постоянно работающие вычислительные мощности — но с надбавкой за serverless-обёртку. Для нагрузок, чувствительных к задержкам, Kubernetes с настроенными проверками готовности и предварительно прогретыми подами оказывается и стабильнее, и дешевле.
Скрытые расходы FaaS, о которых молчат
Главная ловушка serverless — структура реального счёта. Базовая цена за вызов функции и за ГБ-секунду вычислений выглядит копеечной. Но реальный счёт формируется из совокупности связанных сервисов, и их доля часто превышает стоимость самих функций.
NAT-шлюзы и сетевой трафик
Если функция работает внутри виртуальной частной сети (VPC) и обращается во внешние API, например, к платёжному провайдеру, весь её трафик идёт через NAT-шлюз. Почасовая аренда плюс плата за обработанный объём данных могут на низких объёмах превышать саму стоимость вычислений. Особенно неприятно — NAT-шлюзы тарифицируются непрерывно, даже когда функции не вызываются. Это типичная «зомби-инфраструктура»: ресурс развёрнут и оплачивается, но бизнес-ценности не приносит.
API-шлюз и логирование
Публичный вход в serverless-функции почти всегда идёт через управляемый API-шлюз, который тарифицируется отдельно за каждый миллион запросов. Для нагруженных API эта статья нередко становится крупнейшей в счёте. Параллельно растут расходы на логи: их объём масштабируется вместе с числом вызовов, а без политики ротации хранилище логов будет дорожать быстрее, чем растёт сама нагрузка.
Холодные старты и резерв предварительно инициализированных экземпляров
Чтобы избавиться от задержек на холодном старте, на критичных функциях включают выделенную одновременность (provisioned concurrency). Это решает проблему задержки, но возвращает фиксированную базовую стоимость, как у обычного контейнера, плюс serverless-наценку провайдера. FinOps-подход здесь однозначен: использовать резерв точечно — только на самых критичных эндпоинтах и только в часы пиковой нагрузки.
Тарификация инициализации и неоптимальная память
В 2025 году крупные провайдеры FaaS изменили подход к тарификации фазы инициализации функций — теперь время холодного старта считается как часть выполнения и попадает в счёт. Для тяжёлых сред исполнения вроде Java или .NET это превращает каждый «холодный» запуск в прямую статью расходов и может увеличивать общий счёт на десятки процентов. Параллельная проблема — недостаточная память: функция со скромным объёмом ОЗУ работает дольше и в итоге обходится дороже, чем та же функция с увеличенной памятью, потому что вычислительная мощность масштабируется вместе с памятью. Подбор оптимальной конфигурации через инструменты замера производительности стал базовой FinOps-практикой для серверлес-платформ.
Kubernetes: когда есть переплата
Картина была бы однобокой, если не сказать о том, как кластеры умеют тратить деньги впустую.
Простаивающие ноды и нерациональная утилизация
Без HPA, VPA и грамотной оптимизации размера ресурсов типичная ситуация: кластер Kubernetes держит нагрузку на десяти процентах CPU, а тарифицируется по полному объёму выделенных нод. Без работы с метриками утилизации цена контейнерной платформы растёт линейно с числом сервисов, но не с реальной нагрузкой. Это та же логика, что в serverless, только наоборот: если в FaaS вы платите слишком много за слишком много вызовов, то в Kubernetes — за слишком много простоя.
Сопутствующая экосистема
Kubernetes сам по себе — только ядро. Вокруг него обычно стоит обширная экосистема: Prometheus и Grafana для мониторинга, контроллер входящего трафика, сервисная сетка для межсервисного взаимодействия, менеджер секретов, инструменты безопасности, ArgoCD или Flux для GitOps. Каждый компонент — это либо отдельный платный сервис, либо собственные ресурсы кластера. Совокупная стоимость владения Kubernetes-платформой редко ограничивается стоимостью вычислений.
Стоимость DevOps
Промышленный кластер Kubernetes требует команды с серьёзной технической подготовкой: SRE, платформенные инженеры, специалисты по безопасности. Эта команда — отдельная и существенная статья расходов. Для маленькой компании со скромной нагрузкой стоимость экспертизы не размазывается на достаточный объём вычислений и делает Kubernetes экономически невыгодным по сравнению с serverless-подходом, где значительная часть операционной работы переложена на провайдера.
FinOps как инструмент оптимизации затрат
Вне зависимости от того, выбрали вы serverless, Kubernetes или гибрид, в 2026 году без FinOps-практик облачные расходы выходят из-под контроля. FinOps — это не отдельный отдел и не один инструмент, а культура работы с облачной стоимостью, в которой ответственность за затраты разделена между инженерами, финансами и продуктом.
Тэгирование и прозрачность расходов
Первый шаг любой FinOps-практики — обязательное тэгирование ресурсов: владелец, команда, проект, среда, центр затрат. Без этого невозможно понять, кто что тратит, и невозможно построить распределение затрат по подразделениям. Многие команды начинают именно с этого — и удивляются, когда обнаруживают, что забытые среды разработки и осиротевшие NAT-шлюзы съедают заметную долю бюджета.
Сдвиг влево: оценка стоимости до развёртывания
Парадигма 2026 года — считать стоимость архитектурного решения до того, как оно попадёт в промышленную среду. Контроль стоимости в конвейерах CI/CD, оценка Terraform-планов через специализированные инструменты, обязательная строка «влияние на стоимость» в запросе на изменения — всё это превращает оптимизацию затрат из реактивной деятельности в проактивную.
Мониторинг аномалий
Облачные расходы редко растут плавно — обычно скачком, после того как кто-то выкатил неоптимальную конфигурацию или случайно создал рекурсивный вызов функции, который запустился миллион раз за минуту. Алерты на отклонение от нормы — обязательный элемент FinOps-инструментария и для Kubernetes, и для serverless.
Гибридная архитектура: Kubernetes плюс serverless
Зрелые команды редко делают бинарный выбор. Чаще встречается гибридная архитектура: ядро системы — стабильные постоянно работающие сервисы, API, базы данных — работает в Kubernetes, а на периферии живут serverless-функции для событийных задач, обработчиков веб-хуков, периодических задач и обработки загруженных файлов.
Такой подход даёт лучшее из двух миров: базовые расходы предсказуемы и оптимизированы за счёт высокой утилизации кластера, а пиковые и нерегулярные нагрузки не требуют постоянных ресурсов и не оплачиваются «вхолостую». Главное при таком подходе — внимательно проектировать границы между двумя средами и контролировать сетевой трафик между ними, чтобы не получить неожиданный счёт за передачу данных.
Российская специфика выбора между serverless и Kubernetes
На российском рынке к 2026 году доступны обе архитектуры, и выбор между ними определяется не отсутствием технологий, а спецификой задач и требований. В практике крупного бизнеса баланс часто смещён в сторону Kubernetes по нескольким причинам.
Первая — регуляторика. Соответствие 152-ФЗ, требования ФСТЭК для государственных информационных систем и стандарты безопасности для финансовых данных проще закрывать на инфраструктуре с прозрачным разграничением зон ответственности. Контейнерные платформы здесь дают больше контроля над сетевыми политиками, шифрованием и аудитом, чем абстрагированный serverless.
Вторая — характер нагрузок. Российский корпоративный сегмент чаще имеет дело со стабильными постоянно работающими сервисами, корпоративными системами, отраслевыми приложениями. Это классический сценарий, где Kubernetes выигрывает у FaaS экономически.
Третья — задачи машинного обучения и работы с GPU. Полноценный управляемый Kubernetes с GPU стал стандартным предложением: можно арендовать Kubernetes-кластеры в облаке, в том числе с поддержкой GPU для машинного обучения и искусственного интеллекта, как готовый сервис, привязанный к российской инфраструктуре и соответствующий требованиям регуляторов. Для тяжёлых нагрузок машинного обучения и обучения моделей это закрывает значительную часть запросов крупного бизнеса, для которого выбор между serverless и Kubernetes на практике решается в пользу второго ещё на этапе требований.
Заключение
Универсального ответа на вопрос «что дешевле — serverless или Kubernetes» не существует. Serverless экономит деньги там, где нагрузка нестабильная, редкая или плохо предсказуемая; Kubernetes выигрывает там, где трафик стабильный, плотный и предсказуемый. Между этими полюсами — гибрид, который чаще всего и оказывается правильным ответом для зрелого продукта.
Главный навык в 2026 году — не выбор технологии, а умение считать совокупную стоимость владения: вычисления, сетевой трафик, логи, инструменты наблюдаемости, стоимость экспертизы. И встроенная в процесс разработки FinOps-культура, которая не даёт счёту за облако расти быстрее, чем растёт сам бизнес.
