Облачные вычисления против локальных серверов в банках
Чтобы понять, что выгоднее банку — облачные вычисления или локальные серверы, недостаточно сопоставить тариф виртуальной машины со стоимостью оборудования. Такое сравнение отвечает только на вопрос о цене отдельных ресурсов.
Макар Литвинов·Обновлено: 26 сентября 2026 г.·9 мин
Оно не показывает расходы на сопровождение, безопасность, резервирование, передачу данных и обновление платформы — а именно там часто обнаруживается разница между первоначальным бюджетом и фактической стоимостью владения.
Поэтому вопрос «как проверить облачные вычисления против локальных серверов в банках» начинается с конкретной системы и её нагрузки. Нужно выяснить, какие данные она обрабатывает, как связана с остальной инфраструктурой, насколько меняется потребление ресурсов и какие требования предъявляются к доступности. Универсального ответа для всего банка нет: практический выбор чаще сводится к тому, где разместить отдельные компоненты и как посчитать их полную стоимость.
Ловушка TCO: почему локальная инфраструктура обходится банкам дороже прогнозов
Локальная инфраструктура кажется предсказуемой, пока в смете видны серверы, системы хранения и сетевое оборудование. Но закупка — лишь начало расходов. К ней добавляются площадка и инженерные системы, обслуживание, специалисты, обновления, информационная безопасность и готовность восстановить сервис после сбоя.
Есть и менее очевидная статья — запас мощности. Если его заложить с избытком, часть оборудования простаивает. Если запаса не хватает, расширение зависит от закупки и ввода новых ресурсов. Облачная модель позволяет быстрее менять выделенные мощности, но не устраняет расходы: вместо капитальных вложений появляются регулярные платежи, зависящие от потребления.
По данным исследования Deloitte за 2024 год, фактическая совокупная стоимость владения локальной инфраструктурой в банках может в 3–4 раза превышать первоначальные оценки. Это не универсальная надбавка к любому бюджету, а разрыв между ранним прогнозом и полным учётом расходов. Для конкретной системы результат зависит от срока эксплуатации, загрузки оборудования, требований к отказоустойчивости и стоимости сопровождения.
При проверке облачных вычислений против локальных серверов важно сравнивать варианты на одинаковом горизонте и при одинаковых требованиях к доступности. Сопоставлять ежемесячный облачный тариф с ценой закупленного сервера — всё равно что сравнивать счёт за электричество со стоимостью генератора: границы расчёта разные.
| Параметр | Локальные серверы | Облачная инфраструктура |
|---|---|---|
| Стартовые расходы | Закупка и подготовка оборудования требуют капитальных затрат | Можно начать работу без закупки всей физической платформы |
| Масштабирование | Нужна свободная мощность или новое оборудование | Ресурсы можно менять быстрее, но рост потребления увеличивает счёт |
| Эксплуатация | Банк отвечает за оборудование, площадку, обслуживание и специалистов | Провайдер обслуживает часть инфраструктуры, но конфигурацией и расходами нужно управлять |
| Планирование мощности | Запас приходится закладывать до фактического пика | Ресурсы проще подстраивать под переменную нагрузку |
| Риски стоимости | Недооценка сопровождения, обновления, простои или нехватка мощности | Расходы на хранение, исходящий трафик и неконтролируемое потребление сервисов |
В облачной смете нужно учитывать не только вычисления. На итог влияют хранение данных, резервные копии, управляемые сервисы и сетевой обмен. Например, egress fees — плата за исходящий трафик — может стать существенной, если данные регулярно перемещаются между системами или регионами. Если этот поток заранее не измерить, тариф на вычислительные ресурсы даст неполную картину.
Облако не гарантирует экономию. Оно меняет структуру расходов — и эту структуру нужно считать на реальной нагрузке.
Бюджетный перекос: как legacy-системы поглощают 64% ресурсов на инновации
Согласно исследованию Deloitte, поддержка устаревших банковских систем в локальной инфраструктуре поглощает в среднем 64% IT-бюджета. На новые цифровые продукты и инновации остаётся 36%. Эти доли помогают увидеть масштаб бюджетного перекоса, но сами по себе не говорят, какую систему следует переносить и куда.
Перенос приложения в облако не равен его модернизации. Если оставить прежние зависимости, ручные процедуры выпуска и ограничения архитектуры, расходы могут просто сменить адрес. Вместо затрат на обслуживание локального оборудования появится счёт за облачные ресурсы, а сама система по-прежнему будет требовать внимания специалистов.
Чтобы понять, что именно стоит за расходами legacy-системы, их полезно разделить на три части:
- Поддержка текущего состояния. Сколько стоит обеспечивать доступность, безопасность и совместимость приложения с банковским контуром?
- Изменение приложения. Какие архитектурные работы нужны, чтобы система могла эффективно использовать масштабирование или управляемые сервисы?
- Эффект размещения. Какие расходы действительно исчезнут при переносе, какие останутся, а какие появятся в другой форме?
Такой разбор не позволяет приписать серверной инфраструктуре все расходы, связанные с устаревшим приложением. Часть затрат создаёт сама система и способ её эксплуатации. Если это не учитывать, миграция может оказаться дорогим переносом прежних проблем на новую площадку.
Особенно важно проследить связи между компонентами. Приложение может занимать немного места и потреблять сравнительно мало вычислительных ресурсов, но постоянно обращаться к другим системам. В результате стоимость его размещения будет зависеть не только от размера самой нагрузки, но и от объёма сетевого обмена, хранения и сопровождения интеграций.
Гибридная модель как стандарт: разделение критических данных и фронт-офисных нагрузок
Для банков выбор редко сводится к двум крайностям: перенести всё в публичное облако или оставить всё в собственном ЦОД. Локальные серверы, выделенное оборудование и облачные ресурсы могут сосуществовать. Например, критичные базовые системы размещают на локальной или выделенной инфраструктуре, а фронт-офисные сервисы масштабируют в облаке. Аналитические и ИИ-нагрузки тоже рассматривают отдельно — с учётом данных, требований и конфигурации.
Гибридная архитектура позволяет выбирать место для каждого компонента, а не для всего банковского IT разом. При этом важно разделять нагрузку и ответственность. Физической инфраструктурой может управлять провайдер, но банк всё равно должен контролировать доступ, конфигурацию и потоки данных в рамках выбранной модели.
Для каждого приложения полезно составить собственный профиль:
- базовые системы и компоненты с жёсткими требованиями к размещению оценивать отдельно от переменных фронт-офисных нагрузок;
- для аналитики учитывать объём исходных данных, частоту обмена и срок хранения результатов;
- сервисы с заметными пиками проверять на потребность в быстром добавлении ресурсов;
- для всех компонентов фиксировать зависимости от API, хранилищ и внутренних систем;
- заранее описывать, как связаны площадки и кто отвечает за восстановление при сбое.
Гибридность не означает, что чувствительные данные автоматически должны оставаться только на собственном оборудовании. Нельзя вывести единое правило размещения из самого факта, что данные относятся к банковским. Схему нужно определять для конкретной системы и потока данных с учётом применимых требований и уровня защищённости.
Распределение компонентов по нескольким площадкам создаёт и новые точки внимания: сетевые связи, интеграции, согласованное восстановление. Если один сервис работает в облаке, а другой остаётся локальным, обмен между ними становится частью архитектуры и бюджета. Чем теснее компоненты связаны, тем важнее оценить стоимость и надёжность этого обмена до миграции, а не после неё.
Объём российского рынка облачных услуг в 2024 году составил 392 млрд рублей; на 2029 год прогнозировался рост до 801 млрд рублей при среднегодовом темпе 21%. Доля отечественных решений в сегменте публичных облаков, по имеющимся данным, превысила 91,7% в 2025 году. Эти показатели описывают развитие рынка, но не доказывают, что конкретному банку выгодно переносить конкретную систему. Для этого всё равно нужны профиль нагрузки и расчёт стоимости.
Скрытые риски облачной миграции: от egress fees до управления данными
Цена облачной нагрузки зависит не только от процессоров и памяти. В расчёте участвуют объём и срок хранения данных, резервные копии, передача между системами и дополнительными сервисами. Если данные продолжают накапливаться без ясной политики хранения, счёт может расти даже тогда, когда сами вычисления почти не меняются.
Особое внимание стоит уделить egress fees. Для оценки недостаточно знать общий объём данных: нужно понимать, откуда и куда они перемещаются, как часто это происходит и какие компоненты инициируют обмен. Например, расходы могут оказаться выше ожидаемых, если облачный сервис регулярно обращается к локальному хранилищу или несколько компонентов передают друг другу крупные массивы.
Похожим образом нужно оценивать управляемые сервисы. Они способны снять часть инфраструктурной работы с команды, но влияют на стоимость и создают архитектурные зависимости. Важно выяснить, какие операции включены в тариф, какие оплачиваются отдельно и что произойдёт с расходами, если вырастет объём данных или изменится схема обмена.
При сравнении облака и локальных серверов для банка полезно собрать как минимум следующие параметры:
- обычную и пиковую нагрузку приложения;
- объём оперативного и постоянного хранения;
- частоту резервного копирования и срок хранения копий;
- направления и объём исходящего трафика;
- расходы на сопровождение, безопасность и аварийное восстановление;
- стоимость изменений приложения, если простого переноса недостаточно.
Этот набор не заменяет архитектурный анализ, но позволяет перейти от абстрактного тарифа к оценке конкретной нагрузки. Для локального варианта действует тот же принцип: цена сервера без учёта площадки, сопровождения и восстановления не показывает полную стоимость системы.
Управление данными — не отдельная формальность, которую можно добавить в конце миграции. Если заранее не определить, какие системы обмениваются данными и кто отвечает за доступ, хранение и восстановление, гибридная схема станет сложнее для контроля. Значит, в сравнении нужно учитывать не только место размещения, но и операционные процедуры, которые это размещение потребует.
Скорость Time-to-Market: как IaC меняет цикл развертывания с 30 минут до 30 секунд
Infrastructure as Code, или IaC, позволяет описывать инфраструктурную конфигурацию кодом и создавать среды повторяемым способом. В приведённых данных время развёртывания новой виртуальной машины сокращается с 30 минут до 30 секунд. Это относится к созданию ресурса, а не к полному выпуску банковского сервиса.
Разница существенна, когда команда регулярно создаёт одинаковые среды или быстро меняет мощности под нагрузку. Но инфраструктура — лишь один этап вывода продукта. Согласования, тестирование, проверка доступа и подключение зависимостей остаются. Если именно они занимают основную часть цикла, ускорение развёртывания виртуальной машины не даст такого же сокращения Time-to-Market.
Поэтому сравнивать локальную и облачную модели стоит по полному циклу изменения: от готовой конфигурации до среды, прошедшей необходимые проверки и подключённой к нужным системам. Для одних нагрузок важнее быстро добавить ресурсы под пик. Для других — стабильность конфигурации и совместимость с базовыми банковскими системами.
Скорость развёртывания требует и контроля потребления. Если ресурсы можно создавать быстро, неучтённые расходы тоже способны накапливаться быстрее. Нужны правила автоматического создания и удаления сред, контроль простаивающих ресурсов и наблюдение за сетевым трафиком. Иначе удобство IaC ускорит не только работу команды, но и рост счёта.
Сравнивать нужно нагрузки, а не лозунги
Практическая проверка облачных вычислений против локальных серверов в банках начинается с инвентаризации систем. Базовые банковские приложения, фронт-офис, аналитика и ИИ-сервисы могут предъявлять разные требования — сводить их к единой модели размещения нет смысла.
Затем для каждого компонента задают одинаковые условия расчёта: горизонт планирования, профиль нагрузки, требования к доступности и допустимое размещение данных. В локальную оценку включают оборудование, обновления, персонал, площадку, безопасность и восстановление. В облачную — вычисления, хранение, управляемые сервисы и исходящий трафик. Отдельно учитывают стоимость изменений приложения, если перенос требует модернизации.
После расчёта остаётся сопоставить стоимость с операционной моделью. Где требуется быстро менять ресурсы? Какие приложения тесно связаны с локальными системами? Сколько будет стоить обмен между площадками? Кто отвечает за доступ, конфигурацию и восстановление? Ответы на эти вопросы определяют, какую роль облако, выделенная инфраструктура и локальные серверы будут играть в конкретной архитектуре.
Результатом такого сравнения должна быть не одна рекомендация для всего банка, а обоснованный вариант размещения для каждой нагрузки. Локальная инфраструктура может быть уместна там, где нужны выделенные мощности или заданный контур размещения. Облако — там, где важны гибкость и скорость изменения ресурсов, а расходы на данные и эксплуатацию рассчитаны. Гибридная модель соединяет эти режимы, но не освобождает от главной работы: считать полную стоимость и понимать, как компоненты зависят друг от друга.