Облачные сервисы: почему расходы бизнеса на них растут

Затраты на облачные сервисы растут не потому, что бизнес «переехал в облако и забыл про серверную». Такой сценарий был маркетинговым. В рабочей архитектуре облако не отменяет стоимость инфраструктуры. Оно меняет способ ее закупки, масштабирования и контроля. CapEx уходит в OpEx. Но нагрузка, данные, требования ИБ и AI workloads никуда не исчезают. Часто они растут быстрее, чем экономия от отказа от собственного железа.

Рынок уже не экспериментальный: 416,5 млрд рублей и рост до триллиона

Динамика рынка облачных услуг показывает зрелую фазу. В 2025 году общий объем российского рынка облачных сервисов достиг 416,5 млрд рублей. Рост к 2024 году — 32,8%. Прогноз на 2030 год — 1,2 трлн рублей.

Внутри рынка рост также неравномерный, но синхронный:

Рост популярности облачных сервисов связан не с одной причиной. Нет одного драйвера. Есть стек факторов:

• рост объемов данных — 33%;
• модернизация бизнеса — 32%;
• рост стоимости оборудования — 30%;
• повышение требований к информационной безопасности — 30%;
• внедрение ИИ — 27%;
• импортозамещение — 20%.

Это профиль спроса. Он показывает, что компании покупают облако не только ради масштабирования. Они закрывают накопленный технический долг: устаревшие СХД, дефицит резервных площадок, слабую наблюдаемость, ручные релизы, отсутствие гибкой среды для разработки и тестирования.

Облако стало не способом сэкономить на сервере. Оно стало способом купить скорость изменения инфраструктуры.

С точки зрения архитектурного комитета, главный риск — считать рост расходов дефектом закупки. Часто это дефект проектирования. Нагрузка мигрирует в облако без пересмотра паттернов. Монолит получает больше CPU. База данных — более дорогой storage. Логи пишутся без retention policy. Kubernetes-кластер живет с постоянным overprovisioning. Финансовый результат предсказуем: счет растет, SLA не улучшается пропорционально.

Почему растут затраты на облака: нагрузка стала другой

Классическая ошибка — сравнивать стоимость облака со стоимостью физического сервера по цене CPU и RAM. Это неполная модель. В облачном счете сидят компоненты, которые в локальной инфраструктуре часто не учитывались явно:

• резервирование по зонам доступности;
• managed backup;
• snapshot storage;
• межзональный и внешний traffic;
• NAT gateway;
• observability;
• WAF и DDoS protection;
• managed Kubernetes control plane;
• лицензии ОС и баз данных;
• шифрование, KMS, audit logs;
• тестовые и staging-среды, которые не выключаются;
• хранение архивных логов без lifecycle policy.

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

Но видимость не равна оптимизации. Без FinOps и технической дисциплины облако быстро превращается в неконтролируемую OpEx-платформу.

Типовые причины роста счета:

1. Lift-and-shift без рефакторинга.

Виртуальные машины копируют локальную схему. Приложение не использует autoscaling, managed queues, object storage, serverless-компоненты. Платится цена облака, но эксплуатационная модель остается старой.

2. Постоянный запас ресурсов.

Команды резервируют инстансы «на пик». CPU utilization держится на 10–20%, RAM простаивает. Для on-prem это было привычно. Для облака это ежедневный финансовый leak.

3. Неправильная работа с данными.

Данные растут быстрее приложений. Object storage дешевле блочного, но архитектура часто продолжает писать всё в дорогие тома. Логи и артефакты CI/CD хранятся без TTL.

4. Слабая сегментация окружений.

Dev, test, stage, preprod получают почти production-конфигурацию. Ночью и в выходные ресурсы не выключаются. Нагрузка отсутствует, счет идет.

5. Переход на managed services без оценки TCO.

Managed PostgreSQL, Kafka, Redis, Kubernetes снижают операционную нагрузку. Но их стоимость выше bare VM. Экономика сходится только при корректном учете SLA, команды эксплуатации и рисков отказа.

6. AI workloads.

Инференс, обработка данных, векторные базы, GPU, pipeline для обучения и дообучения моделей. Это новый класс потребления. Он плохо укладывается в старые лимиты ИТ-бюджета.

Отдельный слой — автоматизация и ИИ в бизнес-процессах. Компании внедряют LLM-сервисы, RAG-контуры, классификацию обращений, генерацию отчетности, интеллектуальный поиск. На уровне стратегии это выглядит как цифровая трансформация; на уровне инфраструктуры — как новые хранилища, новые API, новые очереди, новые требования к latency и безопасности данных. Динамика таких проектов хорошо видна в материалах о трендах внедрения ИИ и автоматизации в бизнесе, но в бюджете это почти всегда конвертируется в рост cloud consumption.

ИИ меняет профиль облачного потребления

Внедрение ИИ указано среди причин роста инвестиций в облака у 27% российских компаний. Глобально эффект сильнее: расходы на дата-центры в 2026 году прогнозируются на уровне 788 млрд долларов, рост — 55,8%. Общие мировые ИТ-расходы — 6,31 трлн долларов, плюс 13,5% к 2025 году.

Это не абстрактный «бум ИИ». Для инфраструктуры он выражается в конкретных потребностях:

Для AI-нагрузок критичны не только вычисления. Критичны данные. Их объем, качество, доступность и юридический режим. Поэтому облачный бюджет растет сразу в нескольких плоскостях:

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

GPU — заметная статья. Но не единственная. В проектах с RAG часто дороже оказываются storage, vector DB, индексация, интеграции, observability и безопасность. Особенно при корпоративном SLA и требованиях к хранению данных внутри периметра или у доверенного провайдера.

Здесь не работает простая формула «купить модель через API». Enterprise-сегмент редко ограничивается одним API endpoint. Нужны:

• контроль персональных и коммерческих данных;
• журналирование запросов и ответов;
• разграничение доступа;
• prompt management;
• защита от утечек;
• fallback при недоступности модели;
• учет стоимости на пользователя, продукт, подразделение;
• интеграция с IAM, SIEM, DWH, CRM, ERP.

Каждый пункт — это инфраструктура. Иногда код. Иногда PaaS. Иногда отдельный security-сервис. Поэтому рост затрат на облака в 2026 году будет связан не только с тарифами провайдеров. Он будет связан с архитектурным расширением контура.

AI не добавляет один сервис в облачный счет. Он добавляет новый слой архитектуры.

Экономика провайдеров: тарифы будут давить снизу

Российские облачные провайдеры в 2026 году вынуждены повышать тарифы из-за роста себестоимости комплектующих и дефицита ИТ-оборудования. Особенно чувствительна оперативная память. Точный средний процент роста тарифов по рынку не установлен. Его нельзя корректно назвать. Но направление понятно: себестоимость инфраструктуры растет.

Провайдер не продает «облако». Он продает капитал, превращенный в сервис:

• серверы;
• СХД;
• сетевое оборудование;
• лицензии;
• стойки;
• электропитание;
• охлаждение;
• инженерную эксплуатацию;
• команды SRE;
• резервирование;
• compliance;
• security operations.

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

Для заказчика это означает простую вещь: облако перестало быть «дешевой альтернативой закупке серверов». Закупка серверов тоже дорожает. Поэтому сравнение должно идти не по цене единицы ресурса, а по совокупной модели владения.

Где облако экономически оправдано

Облако дает сильный эффект, когда есть:

• переменная нагрузка;
• быстрый time-to-market;
• потребность в DR без строительства второй площадки;
• много сред разработки и тестирования;
• нерегулярные batch jobs;
• требование быстро масштабировать storage;
• дефицит внутренних компетенций по эксплуатации БД, k8s, брокеров;
• необходимость географического резервирования;
• частые релизы через CI/CD;
• проектная нагрузка с неопределенным горизонтом.

Где облако становится дорогим

Стоимость быстро растет, если есть:

• стабильная 24/7-нагрузка без пиков;
• крупные stateful-системы без оптимизации storage;
• высокий egress traffic;
• постоянный overprovisioning;
• лицензии, привязанные к ядрам;
• долгий retention логов;
• отсутствие tagging и chargeback;
• ручное создание ресурсов;
• отсутствие лимитов на sandbox-среды;
• неуправляемая мультиоблачность.

Это не аргумент против облака. Это аргумент против бессистемной эксплуатации. В enterprise-среде облако должно управляться как продуктовая платформа. С владельцем, бюджетом, SLA, SLO, каталогом сервисов, guardrails, политиками безопасности и FinOps-метриками.

Мультиоблачность: не экономия по умолчанию, а снижение зависимости

Около 58% российских компаний используют мультиоблачную стратегию. Структура следующая: 30% работают с двумя провайдерами, 15% — с тремя, 13% — с четырьмя. Главный мотив — снижение зависимости от одного поставщика и оптимизация затрат.

Но мультиоблачность редко снижает расходы автоматически. Она снижает vendor lock-in. Иногда повышает устойчивость. Иногда дает рычаг в переговорах. Но почти всегда добавляет сложность.

Мультиоблачность оправдана, если она решает конкретную архитектурную задачу:

• критичная система требует резервирования вне одного провайдера;
• есть регуляторные ограничения по данным;
• разные провайдеры сильны в разных сервисах;
• нужно избежать жесткого vendor lock-in;
• закупочная политика требует конкуренции;
• часть контуров остается в private cloud;
• продукт работает на нескольких рынках или в нескольких юрисдикциях.

Плохая мультиоблачность выглядит иначе. Команды выбирают провайдера по привычке. Один сервис живет в одном облаке, другой — в другом. Сеть не документирована. IAM разный. Terraform-модули не стандартизированы. Логи собираются частично. В такой модели затраты растут быстрее, чем устойчивость.

Оптимальный паттерн — не «всё везде». Оптимальный паттерн — controlled portability:

• единый IaC-подход;
• минимизация провайдер-специфичных сервисов в критичном ядре;
• допускаемое использование managed services в некритичных или экономически оправданных зонах;
• стандартные landing zones;
• единый tagging;
• централизованный billing export;
• FinOps-дашборды;
• политики по lifecycle ресурсов;
• регулярный rightsizing;
• архитектурные ревью перед запуском крупных сервисов.

Kubernetes часто используют как слой переносимости. Это работает только частично. k8s переносит workload, но не переносит полностью данные, сети, IAM, managed databases, очереди, observability и security controls. Поэтому утверждение «у нас k8s, значит мы не зависим от провайдера» технически слабое. Контейнеризация уменьшает зависимость. Не устраняет ее.

Суверенные облака и технологическая независимость

Мировые расходы на Sovereign Cloud IaaS в 2026 году прогнозируются на уровне 80 млрд долларов. Рост — 35,6%. Причина — геополитическая напряженность и стремление стран к технологической независимости. В Европе расходы на публичные облачные сервисы составят 229 млрд долларов в 2025 году и достигнут 452 млрд долларов к 2029 году. CAGR — 19%.

Для российского рынка это не внешняя статистика. Это подтверждение общего направления. Облако становится элементом инфраструктурного суверенитета. Не только способом быстро поднять VM.

Суверенное облако требует:

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

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

Российские компании дополнительно закладывают импортозамещение как фактор инвестиций в облака. Его доля среди причин роста — 20%. Это не максимальный драйвер, но значимый. Особенно для компаний с регуляторным давлением, госсектором, финансовым контуром, промышленностью, телекомом.

Архитектурно это ведет к гибридной модели:

• часть систем остается on-prem или в private cloud;
• новые цифровые продукты выходят в публичные облака;
• критичные данные изолируются;
• аналитика и AI строятся на выделенных контурах;
• резервирование идет между площадками;
• SaaS используется точечно, с оценкой рисков;
• интеграция строится через API gateway, broker, ETL/ELT-контуры.

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

Что должен считать бизнес, а не только ИТ

Рост расходов на облачные сервисы нельзя анализировать только через строку invoice. Нужна связка технических и финансовых метрик.

Минимальный набор для архитектурного контроля:

• Unit economics. Стоимость одной транзакции, одного пользователя, одного документа, одного inference-запроса, одного заказа.
• Utilization. CPU, RAM, storage IOPS, network. Не средняя температура, а по классам workload.
• Idle resources. VM, диски, IP, snapshots, test-кластеры, которые не используются.
• Storage growth rate. Рост данных по типам: hot, warm, cold, archive.
• Traffic cost. Внешний egress, межзональный traffic, межоблачные каналы.
• SLA cost. Сколько стоит переход с 99,5% на 99,9% и выше.
• Managed service premium. Разница между self-managed и managed с учетом команды эксплуатации.
• Commitment coverage. Доля ресурсов, покрытая долгосрочными контрактами или reserved capacity.
• Tagging compliance. Доля ресурсов с корректными тегами продукта, команды, среды, cost center.
• Forecast accuracy. Отклонение фактического счета от прогноза.

Без этих метрик обсуждение бюджета превращается в конфликт между финансами и ИТ. Финансы видят рост счета. ИТ видит рост нагрузки и требований. Архитектурный комитет должен видеть причинно-следственную связь.

Правильная модель управления расходами выглядит так:

1. Каталог стандартных платформенных сервисов.

Команды не создают инфраструктуру с нуля. Они выбирают утвержденные шаблоны: VM class, managed DB profile, k8s namespace, logging tier, backup policy.

2. IaC как обязательный слой.

Ручные ресурсы — исключение. Terraform, OpenTofu, Pulumi или аналогичный инструмент фиксируют конфигурацию. Изменения проходят review.

3. Бюджеты на уровне продукта.

Не общий счет «за облако», а P&L по системам. Владелец продукта видит стоимость своих решений.

4. Автоматический shutdown непроизводственных сред.

Dev и test не должны работать 24/7 без причины. Расписание — базовая мера.

5. Lifecycle policy для данных.

Hot storage не должен быть архивом. Логи не должны храниться бессрочно в дорогом классе.

6. Rightsizing как регулярный процесс.

Не раз в год. Минимум ежемесячно. С отчетом по неиспользуемым ресурсам.

7. Архитектурное ревью AI-проектов.

Каждый AI-сервис должен иметь оценку cost per request, модель хранения данных, лимиты, fallback и security design.

8. Контроль vendor lock-in.

Не запрет managed services. Запрет неконтролируемой зависимости без exit plan.

9. SLA по бизнес-критичности.

Не все системы требуют одинакового уровня отказоустойчивости. Разные классы критичности — разные затраты.

10. Контрактная стратегия.

Reserved capacity, committed spend, конкуренция между провайдерами, пересмотр тарифов, анализ скидок. Это часть архитектуры, не только закупок.

Оптимальный стек: не дешевле, а управляемее

Для enterprise-среды базовая целевая модель в 2026 году выглядит так:

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

Главный принцип: облачная архитектура должна проектироваться под стоимость так же, как под отказоустойчивость и безопасность. Если cost model появляется после запуска production, она уже опоздала.

Финальная позиция простая. Расходы бизнеса на облачные сервисы растут потому, что облако стало основной платформой для данных, ИИ, модернизации и суверенной инфраструктуры. Провайдеры несут более высокую себестоимость. Компании потребляют больше управляемых сервисов. Нагрузки становятся тяжелее. Требования к ИБ и SLA растут.

Сократить счет административным запретом нельзя. Можно только управлять архитектурой:

• считать unit cost;
• устранять idle resources;
• проектировать lifecycle данных;
• ограничивать egress;
• применять autoscaling;
• стандартизировать IaC;
• вводить FinOps;
• выбирать managed services по TCO, а не по удобству;
• строить мультиоблачность только под конкретный риск;
• проверять AI-проекты на стоимость до production.

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