IaaS, PaaS, SaaS, FaaS и CaaS: в чем разница и какую облачную модель выбрать бизнесу

Разобраться в пяти аббревиатурах облачных сервисов бизнесу нужно не ради терминологии, а ради денег и управляемости инфраструктуры. От выбранной модели зависит, кто будет обновлять операционную систему, восстанавливать сервис после сбоя, контролировать доступ и поддерживать технологический стек.

Чем больше задач берет на себя провайдер, тем меньше инфраструктурной работы остается клиенту. Обратная сторона - сокращение свободы настройки и более высокая зависимость от возможностей конкретной платформы.

• IaaS предоставляет вычислительные ресурсы, сеть и хранилище. Клиент самостоятельно управляет операционной системой, серверным ПО и приложениями.
• В PaaS провайдер готовит среду для разработки и запуска приложений. Команда отвечает за код, данные, зависимости и настройки продукта.
• CaaS предназначен для контейнерных приложений и оркестрации. Он дает больше контроля, чем PaaS, но требует компетенций в Kubernetes, сетях и эксплуатации контейнеров.
• FaaS запускает отдельные функции по запросу, расписанию или событию. SaaS представляет собой готовое приложение, которое компания использует по подписке.
• Переход в облако не снимает с бизнеса ответственность за безопасность. Провайдер защищает компоненты, которыми управляет, а клиент отвечает за пользователей, права, доступные настройки и безопасную работу с данными.

IaaS, или Infrastructure as a Service, предоставляет базовые вычислительные ресурсы, сети и хранилище. Обычно это виртуальные серверы, диски, IP-адреса, виртуальные сети и балансировщики.

Провайдер обслуживает физическое оборудование, сеть дата-центра, системы хранения и слой виртуализации. Клиент управляет гостевой операционной системой, установленным ПО, приложениями, данными и доступом пользователей.

Уровень свободы здесь выше, чем в других облачных моделях. Компания может использовать поддерживаемые образы Windows и Linux, загружать совместимые собственные образы, устанавливать нужную СУБД, настраивать сетевые правила и разворачивать специализированное серверное ПО.

Плата за эту свободу - необходимость обслуживать значительную часть стека самостоятельно. На стороне клиента остаются три основные группы задач:

• операционная система, обновления и серверное ПО;
• сеть, права доступа и безопасность внутри виртуальной среды;
• данные, мониторинг, резервное копирование и восстановление.

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

Для защиты данных используют резервные копии, снимки дисков, репликацию и встроенные механизмы приложений. При этом самого наличия снапшота недостаточно. Нужно контролировать успешность заданий и периодически проверять восстановление.

IaaS подходит для систем, которым нужны определенная ОС, собственное серверное ПО или нестандартная конфигурация. Типичные сценарии:

• размещение 1С и ERP;
• файловые серверы;
• корпоративные порталы;
• унаследованные приложения;
• тестовые среды;
• резервные площадки;
• системы с особыми сетевыми требованиями.

DaaS как отдельный сценарий

На инфраструктурном уровне могут работать виртуальные рабочие столы - DaaS, Desktop as a Service.

Сотрудник подключается к удаленной среде с ноутбука или другого устройства, а основные приложения и данные обрабатываются на сервере. Это упрощает централизованное администрирование и контроль доступа.

Но виртуальный рабочий стол сам по себе не гарантирует, что данные никогда не попадут на конечное устройство. Возможность копирования файлов, использования буфера обмена, печати и подключения локальных накопителей определяется политиками DaaS.

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

В модели PaaS провайдер готовит среду, в которой команда развертывает и запускает приложение.

Базовая инфраструктура, операционная система и среда выполнения находятся на стороне платформы. Клиент отвечает за код, зависимости, конфигурацию, данные, секреты и права доступа.

Разработчику не приходится самостоятельно поднимать виртуальные машины, обновлять ОС и готовить базовый веб-сервер. Это сокращает объем инфраструктурной работы, но не освобождает команду от эксплуатации приложения.

На стороне клиента остаются:

• мониторинг;
• управление зависимостями;
• настройка масштабирования;
• защита секретов;
• обработка ошибок;
• резервирование данных.

Главное ограничение PaaS - поддерживаемый платформой стек. Провайдер определяет доступные версии языков, сред выполнения, баз данных, способы деплоя и сетевые возможности.

Если приложению нужна нестандартная библиотека, собственный системный модуль или особая конфигурация ОС, возможностей платформы может не хватить.

Для MVP или типового веб-приложения PaaS часто становится удобной точкой входа: команда сосредотачивается на продукте, а не на настройке серверов.

Переходить на CaaS стоит не после достижения условного числа сервисов, а тогда, когда проекту нужны собственные контейнеры, переносимость, гибкие сетевые настройки или отдельные правила масштабирования.

CaaS предоставляет среду для запуска и оркестрации контейнерных приложений.

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

Граница ответственности различается от сервиса к сервису. В одном случае провайдер управляет только control plane, а рабочие узлы обслуживает клиент. В другом используются управляемые группы узлов или режим, в котором инфраструктурная часть почти полностью скрыта.

CaaS занимает промежуточное положение между IaaS и PaaS. Он дает больше контроля над средой приложения, чем большинство платформ, но не требует управления физическим оборудованием и гипервизором.

В контейнерах можно запускать не только микросервисы:

• монолитные приложения;
• фоновые обработчики;
• плановые задания;
• CI/CD-компоненты;
• внутренние платформенные сервисы.

Контейнерная модель помогает стандартизировать состав приложения между dev, stage и prod. При этом среды все равно могут различаться сетями, хранилищами, секретами, политиками доступа и конфигурацией кластера.

Практическая граница между PaaS и CaaS проходит по требованиям проекта. Если команде достаточно стандартного стека и типового деплоя, PaaS проще. Если нужны собственные образы, гибкая сеть и независимые политики масштабирования, CaaS дает больше свободы.

Порог входа у CaaS выше. Даже управляемый Kubernetes требует компетенций в сетях, хранилищах, безопасности и наблюдаемости.

SaaS - готовое приложение, которое клиент использует через браузер, мобильный или настольный клиент.

К этой модели относятся:

• корпоративная почта;
• CRM;
• системы электронного документооборота;
• видеоконференции;
• HR-платформы;
• офисные приложения;
• сервисы управления проектами.

Провайдер управляет инфраструктурой, платформой и самим продуктом. Клиент настраивает пользователей, роли, права, доступные бизнес-параметры и работает со своими данными.

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

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

SaaS удобен для стандартных задач, где собственная разработка не дает бизнесу заметного преимущества.

Сравнивать SaaS с собственным решением только по цене лицензии нельзя. В расчет входят подписки, внедрение, миграция данных, интеграции, обучение и сопровождение. Для собственного решения к ним добавляются инфраструктура, серверные лицензии, труд администраторов и разработчиков.

FaaS запускает отдельные функции по событию.

Триггером может быть HTTP-запрос, загрузка файла, сообщение в очереди, изменение записи или таймер.

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

В тариф могут входить:

• количество вызовов;
• длительность выполнения;
• выделенная память и CPU;
• сетевой трафик;
• прогретые экземпляры;
• подключенные облачные сервисы.

FaaS относится к serverless-подходу. Серверы физически существуют, но клиент не управляет их выделением, обновлением и масштабированием.

Холодный старт

Если готовой среды нет, платформе требуется время на создание и инициализацию экземпляра. Эта дополнительная задержка называется холодным стартом.

На нее влияют рантайм, размер пакета, зависимости, сетевые настройки и способ инициализации приложения.

Для чувствительных к задержке сценариев используют заранее подготовленные экземпляры, например provisioned concurrency. Другой вариант - вынести пользовательские операции с жесткими требованиями к отклику в постоянно работающий сервис.

Главное различие облачных моделей - объем управления, который остается у клиента. Вместе с ним меняются способы тарификации, масштабирования и развертывания.

Таблица показывает типичное распределение обязанностей. Фактическая граница определяется документацией продукта и договором.

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

Например, SaaS-провайдер обслуживает систему аутентификации, но клиент решает, кому создать учетную запись, кого назначить администратором и когда удалить доступ уволенного сотрудника.

Уровень зависимости от поставщика определяется не только названием модели. Он растет при использовании проприетарных API, закрытых форматов данных, специфических сервисов IAM и уникальных механизмов масштабирования.

IaaS или PaaS

В IaaS клиент самостоятельно устанавливает ОС, веб-сервер, среду выполнения, мониторинг и средства защиты.

В PaaS базовая среда уже подготовлена, а приложение развертывается через Git, CI/CD, интерфейс или API платформы.

PaaS сокращает первоначальную настройку, если приложение укладывается в поддерживаемый стек. IaaS дает больше свободы, но требует больше сопровождения.

PaaS или SaaS

PaaS - инструмент для создания собственного продукта. SaaS - уже готовый продукт для решения бизнес-задачи.

В PaaS клиент владеет кодом и определяет логику приложения. В SaaS он работает внутри логики, которую разработал поставщик.

IaaS или SaaS

Рассмотрим систему электронного документооборота.

В IaaS компания арендует ресурсы, устанавливает СЭД, настраивает ОС, базу данных, обновления и резервирование. Такой вариант дает больше контроля, но требует сопровождения.

В SaaS компания создает пользователей, настраивает роли и начинает внедрение готового сервиса. Простой продукт можно запустить быстро, но корпоративная миграция с интеграциями способна занять недели или месяцы.

Более дешевую модель определяют по полной стоимости владения, а не по одной строке прайса.

PaaS или FaaS

В PaaS обычно разворачивают приложение или сервис. В FaaS - отдельные функции, которые вызываются по событию.

FaaS удобен для обработки файлов, уведомлений, интеграций, сообщений в очереди и плановых заданий.

При стабильной постоянной нагрузке стоимость PaaS, CaaS и FaaS нужно рассчитывать по тарифам конкретных сервисов. Некоторые платформы умеют масштабироваться до нуля, а функции могут использовать постоянно подготовленные экземпляры.

IaaS

Высокая свобода означает высокую операционную ответственность.

Без компетентного администратора или подрядчика растет риск просроченных обновлений, открытых портов, ошибок в правах, отсутствия резервных копий и неконтролируемого потребления ресурсов.

PaaS

Быстрый запуск может привести к зависимости от платформы.

Особенно внимательно нужно оценивать специфические API, встроенные очереди, аутентификацию, механизмы деплоя и управляемые сервисы без прямых аналогов.

Перед миграцией команда должна перечислить все платформенные зависимости и определить, чем их заменить.

SaaS

Главные риски - ограниченная кастомизация и перенос данных.

До заключения договора проверьте форматы выгрузки, наличие API, срок хранения после расторжения, возможность восстановления удаленных записей и порядок возврата данных.

FaaS

Основные ограничения - холодный старт, лимиты времени выполнения, сложность локальной отладки и распределенная трассировка.

Например, AWS Lambda ограничивает один вызов 15 минутами. У других платформ лимиты могут отличаться.

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

CaaS

Контейнеры упрощают перенос приложения, но кластер требует компетенций.

Ошибки часто возникают в сетевых политиках, хранилищах, секретах, правах сервисных аккаунтов, ingress и лимитах ресурсов.

Совокупная стоимость владения складывается не только из цены виртуального CPU или подписки.

Учитывайте:

• вычислительные ресурсы, диски и трафик;
• лицензии;
• работу сотрудников и подрядчиков;
• мониторинг и средства безопасности;
• резервное копирование;
• миграцию и обучение;
• простои и сопровождение интеграций.

IaaS часто предлагает понятную стоимость ресурсов, но требует больше работы по сопровождению.

PaaS сокращает часть инфраструктурных задач, однако управляемые компоненты могут стоить дороже эквивалентных ресурсов IaaS.

SaaS дает прозрачную стоимость подписки, но итог зависит от числа пользователей, набора функций и интеграций.

FaaS может быть выгоден при редкой событийной нагрузке. При большом числе вызовов, длительном выполнении или постоянно подготовленных экземплярах экономика меняется.

Отдельный источник потерь - неиспользуемые ресурсы: забытые виртуальные машины, лишние диски, завышенные размеры инстансов и тестовые среды, работающие круглосуточно.

Поэтому модели нужно сравнивать по TCO конкретного сценария.

Для российского бизнеса к техническому выбору модели добавляется еще один критерий - требования к обработке данных и кибербезопасности.

Обработка персональных данных регулируется Федеральным законом от 27 июля 2006 года № 152-ФЗ «О персональных данных». Он устанавливает обязанности операторов и лиц, обрабатывающих данные по поручению оператора. Применяемые меры зависят от характера обработки, категории данных и используемой информационной системы.

С 19 июля 2026 года действует приказ ФСБ России № 161 от 22 апреля 2026 года. Он утвердил порядок аккредитации центров ГосСОПКА и требования к центрам, обеспечивающим обнаружение компьютерных атак, регистрацию инцидентов, реагирование и обмен информацией.

Приказ регулирует работу центров ГосСОПКА. Связанные с системой требования распространяются на организации и объекты, подпадающие под соответствующие нормативные нормы, а не автоматически на каждую компанию, работающую с персональными данными.

Центры ГосСОПКА аккредитует ФСБ России. Срок действия аккредитации не превышает пяти лет.

При выборе облачного провайдера проверьте:

• место физического размещения данных;
• роли оператора и лица, обрабатывающего данные по его поручению;
• меры защиты на стороне площадки;
• применимые аттестаты и сертификаты;
• порядок регистрации и расследования инцидентов;
• правила хранения журналов;
• резервное копирование;
• распределение обязанностей в договоре.

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

FaaS для длительного монолитного процесса

Serverless не является универсальной средой для любого кода.

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

Такие операции нужно проектировать идемпотентными, разбивать на этапы и связывать через очереди или workflow-сервисы.

Для длительных задач подойдут контейнерные задания, фоновые процессы в PaaS или CaaS и специализированные оркестраторы.

Kubernetes ради Kubernetes

Команда разворачивает кластер для небольшого монолита только потому, что контейнеры считаются современным стандартом.

Проблема не в Kubernetes, а в несоответствии сложности решаемой задаче. Кластер добавляет ingress, сетевые политики, секреты, хранилища, мониторинг и управление ресурсами.

Для небольшого приложения виртуальная машина или PaaS часто решают задачу проще.

Однако несколько микросервисов - не единственная причина использовать Kubernetes. Он может быть оправдан требованиями к стандартизации, изоляции, безопасности и переносимости.

Выбор модели только по прайсу

Низкая цена виртуальной машины не учитывает стоимость администрирования, мониторинга, обновлений и резервного копирования.

Сравнивать нужно полную стоимость владения.

Иллюзия автоматического бэкапа

Провайдер отвечает за свою инфраструктуру, но наличие пользовательских копий определяется тарифом и настройками.

Даже если автоматические снимки входят в услугу, проверьте частоту, срок хранения, защиту от удаления и результат тестового восстановления.

SaaS без проверки экспорта

После нескольких лет работы компания может обнаружить, что данные выгружаются только частично или в неудобном формате.

До подписания договора задайте поставщику три вопроса:

1. В каком формате доступны данные?
2. Сколько они хранятся после расторжения?
3. Есть ли API или механизм регулярного экспорта?

В одной компании разные задачи могут работать в разных моделях.

Типовой вариант:

• корпоративная почта и офисные приложения - SaaS;
• CRM и ЭДО - SaaS, если подходят готовые процессы;
• 1С и специфическое серверное ПО - IaaS;
• новый веб-сервис - PaaS или CaaS;
• контейнерная платформа - CaaS;
• уведомления и обработка загрузок - FaaS;
• виртуальные рабочие места - DaaS.

Каждую задачу стоит размещать там, где соотношение контроля, стоимости и скорости запуска лучше соответствует ее требованиям.

Для стартапа точкой входа часто становится PaaS: небольшой команде важнее быстрее выпустить продукт. Переход к CaaS или IaaS может произойти позже, когда появятся нестандартные зависимости, особые сетевые требования или необходимость глубже контролировать среду.

Когда модель стоит пересмотреть

IaaS → PaaS или SaaS. Значительная часть бюджета уходит на сопровождение типовой задачи, которая не требует собственного стека.

PaaS → CaaS или IaaS. Платформа не поддерживает нужную библиотеку, сетевую схему или способ развертывания.

PaaS → CaaS. Компонентам нужны независимые релизы, собственные контейнеры и отдельные политики масштабирования.

IaaS или PaaS → FaaS для части логики. Серверы простаивают, а отдельные операции запускаются короткими событиями.

1. Нужен готовый продукт или собственное приложение?
2. Требуется ли доступ к операционной системе?
3. Нужно ли устанавливать нестандартное серверное ПО?
4. Поддерживает ли платформа нужный стек?
5. Есть ли у команды компетенции для выбранной модели?
6. Нужны ли контейнеры и независимое масштабирование компонентов?
7. Есть ли событийные задачи, которые можно вынести в функции?
8. Какие требования предъявляются к размещению и защите данных?
9. Кто отвечает за обновления, доступы, резервное копирование и восстановление?
10. Как будут переноситься данные при смене поставщика?
11. Из чего складывается полная стоимость владения?

Чем больше контроля требуется компании, тем ближе выбор к IaaS или CaaS. Чем важнее скорость запуска и снижение объема администрирования, тем уместнее PaaS, FaaS или SaaS.

На практике эти модели не конкурируют напрямую. В одной архитектуре SaaS может отвечать за почту и CRM, IaaS - за 1С, CaaS - за контейнерные приложения, а FaaS - за обработку событий.

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

Можно ли перенести приложение из PaaS в IaaS без переписывания кода?

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

Объем работ определяют после инвентаризации зависимостей.

Как уменьшить холодный старт в FaaS?

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

Сценарии с жесткими требованиями к задержке лучше размещать в постоянно работающем сервисе.

Обязательно ли иметь DevOps-инженера для CaaS?

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

Отдельная штатная должность не обязательна, но зона ответственности должна быть закреплена.

Кто отвечает за резервное копирование данных в SaaS?

Это определяется возможностями сервиса и договором.

Провайдер может резервировать всю платформу для аварийного восстановления, но клиенту не всегда доступно восстановление отдельной записи или состояния на выбранную дату.

Проверьте срок хранения копий, доступные точки восстановления, корзину, версионирование и возможность регулярного экспорта критичных данных.

Информация носит общий характер и не заменяет анализ конкретной инфраструктуры, договора и применимых нормативных требований.