Снижение затрат на ИТ-инфраструктуру: как облако меняет экономику бизнеса в Казахстане

Рынок публичных облаков в Казахстане в 2025 году достиг 117,6 млрд тенге — рост 25,6% к предыдущему году. Цифру представил вице-президент IDC по СНГ Андрей Беклемишев на Astana Hub 25 февраля 2026 года. К 2029 году IDC прогнозирует объём 257,2 млрд тенге при среднегодовом темпе около 22%. Это ответ бизнеса на конкретную проблему: содержание собственной ИТ-инфраструктуры дорожает быстрее, чем растут ИТ-бюджеты. В этой статеь расскажем где облачная инфраструктура даёт экономию, как меняется модель затрат при переходе с CAPEX на OPEX и какие подводные камни ждут компании при миграции.

Почему собственная инфраструктура становится дорогой

Классическая модель «купили серверы — поставили в свой ЦОД — наняли админов» в РК постепенно теряет экономическую логику. Причин несколько, и каждая бьёт по бюджету CFO.

Капитальные затраты растут вместе с курсом. Серверы, СХД, сетевое оборудование, лицензии гипервизоров и резервный ЦОД — это валютные расходы. Логистика и таможенные пошлины заметно удорожают итоговую закупку относительно прайса вендора. Железо устаревает за 3–5 лет, и цикл закупок повторяется.

Электричество и стойкоместо дорожают. Рост тарифов на энергию и плотность застройки коммерческих ЦОД в Алматы и Астане увеличивают стоимость размещения. Компания Sector Tree была вынуждена уйти из собственного ЦОД из-за регулярных отключений электричества — и это не единичный случай, а симптом ограничений локальной энергетической инфраструктуры.

Кадры стоят дороже железа. ИКТ-отрасль РК насчитывает более 200 тысяч занятых, дефицит инженеров уровня Middle и Senior сохраняется по всему рынку. DevOps-инженер сегодня обходится работодателю в 600 тыс. — 1,4 млн тенге в месяц, зарплаты в DevOps, ИИ и ИБ растут на 20–30% в год. Команда из 4–5 инженеров на собственный ЦОД — это ФОТ от 4 млн тенге ежемесячно, не считая налогов и обучения.

Регуляторика добавляет постоянные расходы. Закон РК № 94-V от 21.05.2013 (ред. от 18.01.2026) обязывает хранить персональные данные граждан Казахстана на серверах внутри страны. Для компаний, использующих зарубежные ЦОД, это означает либо построение локального плеча, либо штрафы.

Получается что собственная инфраструктура требует растущих CAPEX, ФОТ выше рынка, постоянных инвестиций в обновление и юридического сопровождения. Для SMB это становится непосильным, для Enterprise — поводом пересмотреть модель.

Какие расходы сокращает облако

Капитальные затраты на железо. При аренде облачной инфраструктуры компания не покупает серверы, СХД и сетевое оборудование. Вместо разовых платежей в десятки и сотни миллионов тенге — ежемесячные счета, привязанные к фактическому потреблению. Парк из 50–500 серверов — типовой кейс, где TCO в горизонте 3–5 лет снижается на 20–40%.

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

ФОТ инфраструктурной команды. Не нужно держать в штате администраторов СХД, инженеров сетевой инфраструктуры, специалистов по виртуализации. Команда фокусируется на прикладных задачах: разработке, безопасности приложений, FinOps. Инфраструктурные роли не исчезают — они трансформируются в SRE и DevOps, но численность сокращается.

Лицензии и поддержка ПО. Лицензии гипервизоров, систем мониторинга, резервного копирования часто включены в облачные сервисы — это избавляет от ежегодных продлений и аудитов соответствия. Резервный ЦОД и DR-инфраструктура. Построение второй площадки для аварийного восстановления — это удвоение CAPEX. В облаке катастрофоустойчивость реализуется через зоны доступности и георезервирование без капитальных вложений.

Важная оговорка: экономия достигается только при грамотной архитектуре и контроле потребления. Без FinOps-практик миграция может не сэкономить, а добавить расходов.

CAPEX vs OPEX: как меняется финансовая модель

Переход от собственной инфраструктуры к облачной — это смена финансовой модели, и для CFO эта разница важнее технических деталей.

При CAPEX-модели компания делает разовые крупные вложения с длительным сроком амортизации: купили серверы за 200 млн тенге — амортизируете 5 лет, по 40 млн в год. Деньги ушли сразу, а эффект на P&L растянут. Имущество на балансе, амортизация предсказуема, налоговые вычеты по основным средствам — всё это плюсы. Но капитал заморожен, цикл закупок длинный, а при изменении нагрузки модель не может гибко под это подстроиться.

OPEX-модель устроена иначе: ежемесячные платежи за фактически потреблённые ресурсы, pay-as-you-go в тенге у локальных провайдеров стал стандартом рынка. Расходы привязаны к выручке и потреблению, нет замороженного капитала, масштабирование — через тариф, а не через закупку. Единственное реальное ограничение: при бесконтрольном росте потребления OPEX может превысить плановый CAPEX — модель требует культуры контроля затрат.

Ключевое преимущество OPEX с точки зрения P&L — привязка ИТ-затрат к юнит-экономике. Бизнес видит стоимость одного клиента, одной транзакции, одного гигабайта — и принимает решения на основе данных. OPEX даёт гибкость, но требует зрелости в управлении затратами.

Какие сервисы выгоднее переносить в облако

Не всё в облаке экономит одинаково. Есть категории, где выгода очевидна и быстро считается, и есть случаи, где облако оправдано стратегически, но не финансово в моменте.

Проще всего считается экономия на сервисах с переменной нагрузкой: сайты с пиковым трафиком, маркетинговые лендинги в период кампаний, образовательные платформы с сезонностью. Cloud Servers с автомасштабированием закрывают пик без капитальных вложений в «запасное» железо — платите только за потреблённое. Схожая логика работает для dev/test-стендов: они нужны в рабочие часы, легко гасятся ночью и в выходные, и по данным FinOps Foundation это даёт 30–65% экономии относительно постоянно работающего стенда.

Объектные хранилища экономически выгоднее собственных СХД при объёмах от единиц до сотен терабайт: бизнес платит за гигабайты и операции, не закладывая удвоение мощности «на вырост». Для бэкапов, медиаконтента, логов это типовой сценарий. Управляемые СУБД идут дальше — они снимают рутину администрирования целиком: резервное копирование, патчинг, репликация, мониторинг. Для команд из 10–50 разработчиков отказ от выделенного DBA в штате даёт ощутимую экономию на ФОТ и снижает риск ошибок ручного администрирования.

Управляемые Kubernetes-кластеры снимают с команды операционную нагрузку по поддержке control plane. Сравнение TCO собственной K8s-инсталляции и managed-сервиса почти всегда в пользу облака — за счёт экономии на инженерах SRE-уровня, а с учётом зарплат DevOps в РК от 600 тыс. тенге это становится решающим аргументом для SMB.

Отдельная история — инфраструктура для ИИ-проектов. GPU в собственности дороги и быстро устаревают, поэтому аренда GPU-инстансов по часам остаётся единственной разумной экономикой для большинства SMB и средних Enterprise. По данным Flexera 2025, уровень внедрения GenAI в корпоративных облачных программах вырос с 50% до 58%.

А вот стабильные высоконагруженные сервисы 24/7 с предсказуемым ростом стоит переносить осторожно — при горизонте планирования 5+ лет собственный ЦОД может оказаться дешевле. То же касается систем, привязанных к специализированному железу, и legacy-приложений с лицензиями, не поддерживающими виртуализацию. Здесь решение принимается через детальный TCO-расчёт.

Типичные ошибки при оптимизации инфраструктуры

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

Первая и самая распространённая — lift-and-shift без редизайна. Простой перенос виртуальных машин «как есть» переносит и всю накопленную неэффективность: избыточно выделенные CPU и RAM, неоптимизированные диски, лишние резервные узлы. Облако в такой конфигурации обходится дороже собственной инфраструктуры. Правильный подход — пересмотреть архитектуру под облачные сервисы: stateless-приложения, автоскейлинг, объектные хранилища.

Вторая ошибка — игнорирование FinOps. 27% облачных расходов в мире уходит впустую. Конкретные источники потерь типичны для всех:

• dev-среды, работающие 24/7;
• snapshot-копии многомесячной давности;
• завышенные тарифные планы при низкой утилизации;
• трафик между зонами доступности при неправильной архитектуре;
• забытые ресурсы после экспериментов.

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

Egress-трафик — ещё одна статья, которую часто не считают заранее. Архитектуры с большим объёмом отдачи данных пользователям или плотной интеграцией с внешними сервисами требуют отдельного расчёта: стоимость исходящего трафика может «съесть» всю экономию на вычислениях.

Отдельный риск — выбор провайдера без учёта регуляторики. Закон РК № 94-V обязывает хранить персональные данные граждан Казахстана внутри страны, и для финсектора и госструктур это не опция, а требование. Зарубежное облако для таких данных — прямой путь к штрафам и репутационным рискам.

Глубокая интеграция с проприетарными сервисами одного провайдера без архитектурной возможности мигрировать создаёт vendor lock-in. Использование открытых стандартов — Kubernetes, S3-совместимые API, PostgreSQL — сохраняет переговорную позицию и страхует от ценовых сюрпризов.

Наконец, миграция «всем разом» — частая причина срыва бюджета и сроков. Рабочий сценарий выглядит иначе: пилот на одном-двух некритичных сервисах, отработка процессов, затем поэтапная миграция с регулярными ретроспективами.

Как рассчитать экономический эффект от миграции

Решение о переходе в облако должно опираться на цифры. Базовая методика подойдёт и SMB, и Enterprise — отличаются только масштабы.

Отправная точка — полный TCO собственной инфраструктуры за горизонт 3–5 лет:

• стоимость серверов, СХД и сетевого оборудования с учётом амортизации;
• лицензии гипервизоров, ОС, СУБД и средств резервного копирования;
• электричество, стойкоместо, охлаждение и физическая безопасность ЦОД;
• ФОТ инфраструктурной команды с налогами и накладными расходами;
• стоимость резервного ЦОД или DR-сценария;
• расходы на обновление парка.

Большинство компаний, впервые собирая эту цифру, обнаруживают, что реальные затраты в 1,5–2 раза выше тех, что фигурируют в ИТ-бюджете.

Следующий шаг — рассчитать целевую облачную конфигурацию на основе реального профиля нагрузки, а не того, что выделено сейчас. Важно брать прогноз с учётом автоскейлинга, резервирования (committed use, savings plans) и оптимизации архитектуры — иначе получится завышенная цифра, которая делает облако неконкурентным на бумаге.

Отдельной строкой учитываются единоразовые затраты миграции: аудит инфраструктуры и проектирование целевой архитектуры, работа интегратора или внутренней команды, параллельная эксплуатация старой и новой инфраструктуры (обычно 1–3 месяца), обучение команды. Эти затраты часто занижают или вовсе не закладывают — и именно из-за этого миграция выбивается из бюджета.

При сравнении P&L-эффекта важно смотреть не только на итоговую сумму, но и на структуру: освобождение замороженного капитала и его альтернативная стоимость, ускорение time-to-market новых продуктов, снижение рисков — отказы, штрафы, простои — и влияние на оценку компании при привлечении инвестиций.

Первый месяц после миграции не репрезентативен — реалистичный расчёт делается на горизонте 3–6 месяцев с учётом FinOps-оптимизации. По оценкам FinOps-практик, внедрение методологии даёт до 30% экономии за первые недели работы: это нужно закладывать в модель, а не воспринимать как приятный бонус.

Казахстанская компания Flowsell провела миграцию силами небольшой внутренней команды и сократила инфраструктурные затраты — кейс был представлен на Profit Cloud Day 2025. Это типовой результат для SMB с относительно простой архитектурой, без legacy и тяжёлых интеграций.

Когда облако действительно помогает экономить, а когда нет

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

Быстрый рост с непредсказуемой нагрузкой — классический сценарий в пользу облака. Стартапы и масштабирующиеся компании не могут ни промахнуться с закупкой — купить мало значит потерять клиентов, купить много значит заморозить капитал, — ни ждать поставки железа. Похожая картина у сезонных и пиковых бизнесов: ритейл с распродажами, образовательные сервисы с приёмными кампаниями, билетные платформы получают экономию за счёт оплаты только пиковых ресурсов. Компании с высокой долей dev/test-стендов выигрывают за счёт возможности гасить непродуктивные среды ночью и в выходные.

Региональная или международная экспансия через облако занимает недели, через собственный ЦОД — годы. Для финсектора и госструктур РК локализация ЦОД в Казахстане обязательна по закону № 94-V, и локальное облако с резервированием по зонам доступности решает задачу без капитальных вложений.

Собственная инфраструктура остаётся конкурентной там, где нагрузка стабильна, утилизация железа близка к 100% и горизонт планирования — 5 лет и дольше. То же относится к специализированному железу — HFT-системам, ASIC, узкоспециализированным ML-стендам, а также к случаям с жёсткими регуляторными требованиями к физическому контролю над оборудованием.

Большинство крупных компаний РК приходят к гибридной модели: критичные системы с предсказуемой нагрузкой остаются в собственном ЦОД, всё остальное переезжает в облако. По данным Kursiv, 78% компаний Казахстана уже используют хотя бы одно облачное решение, а рынок растёт на 35% в год. Гибрид становится новой нормой, а не временной мерой.

Из локальных решений — партнёрство VK Cloud и QazCloud: две зоны доступности (QazCloud и Kazteleport), более 20 IaaS- и PaaS-сервисов, биллинг в тенге, соответствие требованиям закона № 94-V. Пример того, как локализация и облачная модель совмещаются в одной конфигурации.

Главный принцип

Снижение затрат на ИТ-инфраструктуру — результат осознанного выбора модели под профиль нагрузки, а не лозунг об отказе от собственного дата-центра. Сокращение CAPEX через миграцию в облако работает, если параллельно внедряются FinOps-практики, пересматривается архитектура и контролируется cloud waste. Без этого экономия превращается в перерасход.

Рынок облачной инфраструктуры в Казахстане растёт на 25,6% в год не потому, что облако модно, а потому что для большинства компаний экономика складывается в его пользу. Задача CTO и CFO — не следовать тренду, а посчитать TCO для своего бизнеса и принять решение на цифрах.