От требований к провайдеру: как выбрать облако, которое не подведет через год

• — Где физически хранятся данные? Есть ли гарантии локализации?
• — Соответствует ли облако 152-ФЗ, требованиям ФСТЭК, ФСБ, ЦБ РФ?
• — Поддерживает ли провайдер сертификацию СТЭК, СЗИ, КИИ?

   Большинство облачных провайдеров имеют аттестацию по 152-ФЗ по УЗ-1 (уровень защищенности). Стоит учитывать, что у некоторых провайдеров аттестовано все облако, а у некоторых — определенные ЦОДы или сервисы.

Например, ГОСТ Р 57580.1-2017 – это национальный стандарт безопасности банковских и финансовых операций. Если у провайдера есть сертификат соответствия этому стандарту, то его облако могут спокойно использовать кредитные организации.

2. Техническая зрелость и функциональность

• — Есть ли аналоги не только базовые сервисы, но и «продвинутые» (управляемый Kubernetes, СУБД, облачные функции, API шлюзы, ML-сервисы и др.)?
• — Поддерживается ли Terraform и насколько удобный API платформы? Какова степень совместимости с OpenAPI?
• — Присутствует ли детальный ресурсов и логирование состояний сервисов?
• 
  

Главные игроки рынка публичных облаков предлагают на данный момент 60+ IaaS и PaaS сервисов. Так, при выборе вендора и его сервисов необходимо учесть не только функциональные характеристики сервиса, но и сопутствующие возможности или сервисы: это резервное копирование и восстановление в случае сбоя, полнота и глубина мониторинга, а также настройка оповещения в случае сбоя.

Например, у некоторых провайдеров присутствует IPSec VPN как сервис, а у других нет. В случае отсутствия сервиса потребуется его реализовывать самостоятельно – развернуть виртуальную машину и соответствующее ПО. Кроме того, если необходимо отказоустойчивость и ваше решение использует несколько зон доступности, то для VPN также потребуется продумать реализацию отказоустойчивости самостоятельно.

Правильно оценивайте требуемую производительность сервисов в облаке, в том числе дисковой подсистемы – ориентируйтесь не только на названия, но и указанные технические характеристики (IOPS, bandwidth).

3. SLA и отказоустойчивость

• — Какие SLA по доступности: 99.89%, 99.95%, 99.9%? Какие финансовые штрафы за несоблюдение SLA?
• — Расположение и количество ЦОДов провайдера? Какие есть зоны? Регионы?
• — Как реализовано резервное копирование, DRP, RPO/RTO?
• — 
• Есть ли резервирование линий электропитания? Каналов телекоммуникаций?

Многие провайдеры отдельно выделяют, что их ЦОДы имеют Tier III сертификацию, т. е. обладают высоким уровнем надежности, доступности и устойчивости к сбоям (SLA порядка 99,982%).

Кроме того, не забывайте обращать внимание, при каких условиях SLA применяется для сервисов. Например, для PaaS-сервисов СУБД SLA распространяется только в случае использования двух и более рабочих узлов.

4. Экономика и TCO

• — Какова стоимость владения: не только compute/storage, но и исходящий или входящий трафик, выделенный канал, резервирование, API-вызовы, поддержка?
• — Есть ли гибкие тарифы, скидка за резервацию ресурсов или за объем используемых ресурсов?
• — Прозрачна ли биллинговая система? Можно ли экспортировать данные по затратам и автоматизировать их анализ?
• 
  
• Довольно часто при расчетах «забывают» учесть стоимость сопутствующих ресурсов – например, трафика, канала связи, Interconnect либо Directconnect, стоимость поддержки. Обычно данные расходы составляют не более 5-10% от стоимости самих ресурсов, но тоже влияют на итоговые расчеты. 
• 
  

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

У некоторых провайдеров стоимость аттестованного сегмента (например, по 152-ФЗ) отличается от базовых цен, или взимается дополнительная плата за шифрование. Все это необходимо учитывать конкретно для вашей системы при расчете TCO и стоимости решения.

Важно: существенную экономию в размере 5-10% может дать скидка за резервацию ресурсов, а также использование прерываемых (spot) экземпляров, в том числе и для ресурсов с графическим процессором (GPU).

5. Экосистема и интеграции

• — Есть ли магазин или маркетплейс с готовыми решениями?
• — Есть ли партнеры, консультанты, обучение, документация?
• 
  
• Экосистема — это не роскошь. Без экосистемы и готовых модулей или сценариев существенная часть времени будет потрачена на «изобретение велосипеда». Что, в свою очередь, снизит экономию от перехода в облако.

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

6. Безопасность и аудит

• — Есть ли встроенные WAF, DDoS-защита, IAM, шифрование?
• — Поддерживается ли аудит действий?
• — Можно ли интегрировать с SIEM, SOC, внешними системами мониторинга?
• — Как быстро управляемые сервисы получают обновления?
• 
  
• Вопросы безопасности важны как с точки зрения регуляторных положений, так и с практической точки зрения. Например, шифруются ли данные в покое (at rest) или хранятся в открытом виде? Можно ли использовать свой ключ шифрования? А как шифруются резервные копии?
• 
  
• Другой важный вопрос — логи аудита. Предоставляются ли такие логи? Возможно ли их выгрузка в сторонние SIEM-системы? Какой формат логов (т.е. содержатся ли в них все необходимые поля)?

Архитектурные подходы и их плюсы и минусы

Есть три ключевых подхода к миграции.

Подход 1. Полный переход в одно российское облако

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

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

Подход 2. Гибридное облако (российское + on-prem)

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

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

Подход 3. Multi-cloud (2 и более российских облака)

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

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

Рекомендации архитектора

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

• 1. Реализуйте пилотный проект на реальной рабочей нагрузке.
• Вместо тестового приложения разверните в продуктивной среде один из ваших реальных сервисов. В процессе обязательно отработайте процедуры развертывания, мониторинга, резервного копирования и масштабирования.
• 
  2. Закрепите гарантии уровня сервиса (SLA) финансовыми обязательствами.
• Без материальной ответственности провайдера SLA является лишь декларацией о намерениях, а не реальным инструментом управления рисками.
• 
  3. Заложите архитектурную возможность мультиоблачности.
• Даже при использовании одного провайдера проектируйте систему так, чтобы в будущем можно было интегрировать услуги второго облака или организовать миграцию. Это страхует от рисков и дает пространство для маневра.
• 
  4. Автоматизируйте процессы с самого начала.
• Внедрение принципов Infrastructure as Code (IaC), GitOps и полноценной наблюдаемости (Observability) является обязательным условием для исключения ручного труда, снижения ошибок и эффективного управления растущей инфраструктурой.
• 
  5. Обеспечьте соответствие законодательным требованиям. При работе с персональными данными (152-ФЗ), гостайной или критической информационной инфраструктурой (КИИ) консультация с юристами и экспертами по требованиям ФСТЭК является обязательным этапом, а не опцией.

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