Не всегда.

Компания может использовать AWS, Azure и ещё несколько SaaS-платформ, но оставаться зависимой от: - одного identity provider; - одной DNS-зоны; - единого CI/CD; - общей системы управления секретами; - одного телеком-провайдера; - одного облачного control plane; - одного технологического субподрядчика.

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

Поэтому я бы разделял два понятия:

диверсификация поставщиков и диверсификация способности продолжать бизнес.

Первое можно подтвердить списком контрактов.

Второе — только результатами архитектурного анализа, измерением времени замены и практическими учениями.

Регуляторы уже рассматривают концентрационный риск именно как системную проблему. DORA прямо связывает его с такой зависимостью от критических ICT-провайдеров, при которой их отказ способен нарушить выполнение важных функций и вызвать крупные потери. (EUR-Lex) июле 2026 года британские регуляторы начали отдельный надзор за критическими услугами AWS, Google Cloud, Microsoft и Oracle, поскольку сбой одного такого провайдера может одновременно повлиять на множество финансовых организаций. (FCA) меня главный вывод состоит не в том, что крупные облачные платформы ненадёжны.

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

Проблема возникает, когда организация превращает надёжного поставщика в незаменимого.

Vendor assessment обычно отвечает на вопросы о сертификатах, SLA, защите данных и процессах реагирования.

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

Поэтому зрелое управление third-party risk должно начинаться не с реестра поставщиков, а с карты важных бизнес-сервисов.

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

И только после этого становится видно, где находится настоящий blast radius.

Моя позиция проста:

Multi-cloud снижает концентрационный риск только тогда, когда компания умеет продолжать работу после потери одного из облаков.

Всё остальное — архитектурная декларация.

А у вас multi-cloud — это реальная способность переключиться или только наличие второго контракта?