Выбор облачной платформы в Европе всё меньше сводится только к цене, SLA, регионам и набору managed-сервисов. К этим критериям добавляется ещё один: насколько компания контролирует зависимость от провайдера и сможет ли сменить платформу без непропорциональных затрат через несколько лет.
DMA и Data Act не заставляют бизнес срочно уходить от крупных облачных платформ. Но они меняют контекст: усиливают внимание к рыночной власти Big Tech, условиям выхода, переносимости данных, стоимости миграции и прозрачности контрактов. Для клиента это может стать дополнительным аргументом в переговорах с провайдером и поводом заранее проверить архитектурную зависимость.
Главное ограничение остаётся техническим. Даже если регулирование снижает часть внешних барьеров, оно не убирает hyperscaler lock-in: зависимость от API, managed-баз, serverless-функций, IAM, сетевых сервисов, мониторинга, лицензий, скидок и навыков команды. Данные можно выгрузить, но это ещё не значит, что приложение быстро заработает на другой платформе.
Практически это означает три вещи:
- считать не только стоимость входа в облако, но и стоимость выхода;
- отдельно проверять переносимость данных, приложений и операционных процессов;
- рассматривать европейских, локальных и альтернативных провайдеров не как автоматическую замену hyperscaler, а как часть более широкой стратегии.
Сначала важно разделить два регуляторных слоя: DMA больше связан с рыночной властью крупнейших цифровых платформ, а Data Act — с переносимостью данных и условиями смены облачного провайдера. Если смешать эти темы, легко либо переоценить эффект регулирования, либо не заметить реальные возможности для снижения зависимости от одной платформы.
DMA и Data Act: два разных регуляторных слоя вокруг облаков
DMA и Data Act часто воспринимают как единый европейский нажим на Big Tech, но для облачной стратегии это разные инструменты. DMA работает с рыночной властью крупнейших цифровых платформ, а Data Act — с практическими условиями переноса данных и смены облачного или периферийного провайдера.
DMA обычно связывают с маркетплейсами, поиском, магазинами приложений и мессенджерами, но облачная инфраструктура тоже попала в поле внимания. 18 ноября 2025 года Еврокомиссия открыла три расследования по облачным сервисам в рамках DMA: два — по вопросу возможного статуса gatekeeper для AWS и Microsoft Azure, ещё одно — по тому, достаточно ли текущие DMA-обязательства подходят для облачного рынка. Это пока не санкции и не признание нарушений, а проверка применимости правил.
Data Act устроен иначе. Для облаков он ближе к теме контракта и миграции: переносимость данных, открытые интерфейсы, совместимость и функциональная сопоставимость сервисов. Его практический смысл для клиента — понять, как можно выйти из текущей платформы, забрать данные и снизить барьеры перехода.
Если коротко:
| Вопрос | DMA | Data Act |
| Главный фокус | Рыночная власть крупнейших платформ | Перенос данных и смена провайдера |
| Для облачного клиента | Помогает оценивать зависимость от крупных игроков | Помогает обсуждать условия выхода и совместимости |
| Смена провайдера | Может изменить рыночный контекст | Прямо касается перехода между сервисами |
| Практический эффект | Больше внимания к поведению hyperscaler | Больше оснований требовать понятный exit-процесс |
Главное различие такое: DMA помогает смотреть на рыночную власть провайдера, а Data Act — на условия выхода из платформы. В контрактных переговорах это превращается в конкретные вопросы: как выгружаются данные, в какие сроки, в каких форматах, сколько стоит исходящий трафик, какие интерфейсы документированы и что считается успешной миграцией.
Но ни один из режимов сам по себе не заменяет архитектурную подготовку. Если приложение глубоко завязано на managed-сервисы, права доступа, мониторинг и специфичные API, юридические гарантии облегчат выход, но не сделают его автоматическим. Поэтому дальше нужно разобрать, из чего на практике складывается hyperscaler lock-in.
Hyperscaler lock-in: из чего складывается зависимость
Даже если регулирование упрощает перенос данных и снижает часть расходов на выход, сам переход из крупной облачной платформы остаётся инженерным проектом. Зависимость возникает не только из-за контракта, но и из-за того, как устроена система: какие API использует приложение, где лежат данные, как настроены доступы, мониторинг, бэкапы и процессы команды.
Условно lock-in складывается из нескольких слоёв:
- Данные и трафик. Важны объём, формат, скорость переноса, стоимость исходящего трафика и риск простоя при выгрузке.
- Платформенные сервисы. Управляемые базы, очереди, serverless-функции, события, хранилища и аналитика часто имеют отличающиеся от вендора к вендору API, настройки, лимиты и формат журналов.
- Контур управления. IAM-роли, политики доступа, ключи, аудит, сетевые правила, DNS, балансировщики, мониторинг и алерты редко переносятся как готовая модель.
- Коммерческая и операционная зависимость. Лицензии, скидки, обязательства по расходам, навыки команды, runbook-и и процессы обычно заточены под текущую платформу.
Практический пример — управляемая база данных. Таблицы можно экспортировать, но поведение приложения может зависеть от конкретных типов хранилища, параметров репликации, встроенных бэкапов, прав доступа, мониторинга и производительности. Формально данные переносимы; фактически нужно заново проверить SLA, задержки, отказоустойчивость и операционные процедуры.
В корпоративной среде зависимость может быть ещё шире. Например, компания использует связку облачной платформы, корпоративной идентификации, офисных сервисов, лицензий, аналитики и скидок за объём. Это не делает такую архитектуру ошибочной: она может давать скорость, зрелость и предсказуемую поддержку. Но при выборе платформы важно понимать цену обратного хода.
Регулирование способно снизить внешние барьеры: сделать условия выхода прозрачнее, уменьшить часть платежей и усилить позицию клиента в переговорах. Но главный вопрос остаётся техническим: можно ли перенести не только данные, а работающую систему со всеми интеграциями, правами, наблюдаемостью и операционной моделью.
Совместимость сервисов: переносимость данных не равна переносимости приложений
Если зависимость шире самих данных, то совместимость нужно проверять на нескольких уровнях. Выгрузить базу, файлы или журналы в читаемом формате — только первый шаг. После этого приложение должно работать в другой среде с ожидаемыми правами, задержками, событиями, лимитами и сценариями отказа.
В облаках есть три уровня переносимости:
- Данные — можно ли экспортировать их в понятном и машинно-читаемом формате;
- Интерфейсы — можно ли обращаться к сервису через открытые или совместимые API;
- Поведение приложения — будет ли система работать с теми же ожиданиями по доступам, задержкам, сбоям, событиям и мониторингу.
Data Act может улучшить первые два уровня: сделать форматы и интерфейсы прозрачнее, а переход — менее закрытым. Но сопоставимая функциональность не означает полную идентичность поведения. Провайдер может предлагать сервис похожего класса, но его лимиты, модель прав, настройки резервного копирования, обработка событий, метрики и реакции на сбои будут отличаться.
Пример — S3-совместимое объектное хранилище. Совместимый API снижает барьер: приложение проще перенастроить, а часть инструментов загрузки и чтения данных может сохраниться. Но это не гарантирует одинаковые политики доступа, скорость операций, лимиты запросов, интеграции с событиями, поведение при региональном отказе или качество мониторинга.
Похожая логика работает и с Kubernetes. Контейнеры повышают переносимость вычислений, но не переносят автоматически сеть, базы данных, IAM, секреты, наблюдаемость и процедуры эксплуатации.
Поэтому при выборе облачной платформы в Европе недостаточно спросить, можно ли забрать данные и есть ли “совместимый” сервис. Нужно проверять, как приложение поведёт себя на другой платформе в реальных сценариях: под нагрузкой, при сбое, при восстановлении, при изменении прав доступа и при переключении интеграций.
Совместимость снижает часть технических барьеров, но реальный переход между провайдерами всё равно остаётся проектом с бюджетом, сроками, тестами и рисками.
Миграция и мультиоблако: что может стать проще, а что останется проектом
Совместимость снижает часть технических барьеров, но не превращает смену платформы в простое переключение. После проверки форматов, API и поведения приложения появляется более приземлённый вопрос: сколько стоит не “теоретически перенести”, а реально уйти.
Снижение платы за исходящий трафик может заметно изменить экономику выхода для компаний с большими массивами данных. Если SaaS- или финтех-компания хранит терабайты данных, более дешёвая выгрузка снижает финансовый барьер. Но инженерный проект от этого не исчезает.
У миграции остаются три уровня:
- Данные — выгрузка, проверка целостности, перенос архивов, журналов, резервных копий и восстановление после сбоя;
- Приложения — перенастройка баз, очередей, прав доступа, сетевых маршрутов, зависимостей и тестирование под нагрузкой;
- Операционная модель — новые процедуры дежурств, мониторинг, безопасность, поддержка, SLA и навыки команды.
Смена провайдера и мультиоблако — разные стратегии. Смена провайдера отвечает на вопрос “как выйти из текущей платформы”. Мультиоблако отвечает на другой вопрос: “как одновременно эксплуатировать несколько платформ”.
Мультиоблачная архитектура может снизить зависимость от одного поставщика, но она же повышает сложность сети, управления доступом, мониторинга, безопасности и поддержки. Команда фактически обслуживает не одну среду, а несколько разных операционных контуров.
Контрактный слой тоже остаётся важным. Обязательства по расходам, скидки за объём, пакетные предложения, сроки экспорта, форматы данных и помощь при выходе могут ускорить или затормозить миграцию. Регулирование помогает сделать часть условий прозрачнее и снизить отдельные барьеры, но не заменяет расчёт стоимости выхода заранее.
Из этого следует практический этап: не просто решить “уходить или оставаться”, а понять, какие нагрузки где должны жить — у крупного провайдера, у европейского поставщика, у нишевого сервиса или в мультиоблачной схеме.
Стратегия выбора провайдера в Европе
Регулирование не делает европейского или альтернативного провайдера автоматически лучшим выбором. Оно меняет саму рамку оценки: компания должна сравнивать не только функциональность и цену входа, но и управляемость зависимости, условия миграции, юрисдикцию данных и реальную совместимость сервисов.
Крупная облачная платформа: когда важны масштаб и зрелость сервисов
Крупные облачные платформы остаются рациональным выбором, когда компании нужны широкая линейка managed-сервисов, глобальная сеть регионов, зрелые инструменты безопасности, аналитики, машинного обучения, баз данных и поддержки.
Для быстрорастущего SaaS, финтеха или международной корпоративной группы это может быть правильной ставкой. Но в таком сценарии важно заранее ограничивать критичные точки зависимости: отделять данные от специфичной логики, использовать стандартные форматы, документировать план выхода и не принимать долгосрочные обязательства по расходам без оценки миграционного риска.
Европейские и альтернативные провайдеры: где они дают преимущество
Европейский провайдер может быть сильнее, если приоритетом являются размещение данных в ЕС, понятная юрисдикция, локальная поддержка, требования клиентов к цифровому суверенитету или работа с регулируемыми секторами.
Такой выбор может быть уместен для хранилищ, резервных копий, отдельных контуров обработки персональных данных, национальных проектов и сервисов, где правовая предсказуемость важнее самой широкой линейки управляемых функций. Но европейского поставщика всё равно нужно проверять по инженерным критериям: отказоустойчивость, безопасность, наблюдаемость, поддержка, совместимость API и способность помочь при миграции.
Альтернативный или нишевый провайдер подходит, когда нагрузка хорошо очерчена: объектное хранилище, вычисления без сложной платформенной обвязки, резервная площадка, отдельная аналитическая среда, периферийная инфраструктура или сервис с предсказуемым профилем нагрузки. Такой подход может снизить зависимость от одного крупного поставщика и дать лучшую цену на конкретный класс ресурсов, но обычно даёт меньше managed-сервисов и интеграций.
Мультиоблако: когда снижение зависимости оправдывает сложность
Мультиоблако оправдано не всегда. Оно имеет смысл, если у компании есть зрелая инженерная команда, единые практики безопасности, автоматизированное развёртывание, независимый мониторинг и ясное понимание, какие нагрузки зачем размещены в разных облаках.
Если несколько провайдеров выбираются только “для страховки”, без бюджета на эксплуатацию, мультиоблачная архитектура может повысить риск. Вместо снижения зависимости компания получает несколько разных IAM-моделей, сетевых контуров, систем мониторинга, процедур поддержки и наборов компетенций.
Практическая стратегия обычно выглядит не как выбор одного поставщика навсегда, а как классификация нагрузок. Критичные приложения с высокой зависимостью от managed-сервисов можно оставить у крупного провайдера, но с планом выхода. Данные, архивы и резервные копии стоит проектировать так, чтобы их можно было выгрузить в стандартных форматах. Нагрузки с требованиями к европейской юрисдикции можно размещать у провайдера с дата-центрами и договорными гарантиями в ЕС. Изолированные сервисы можно выносить к альтернативным поставщикам, если это не ломает безопасность и поддержку.
Для новых закупок полезно отдельно проверять не только цену и SLA, но и совместимость, условия выхода, стоимость исходящего трафика, перенос журналов, резервных копий, настроек и метаданных.
Заключение
DMA и Data Act добавляют к выбору облака в Европе новый критерий: насколько компания контролирует зависимость от платформы. Речь не о том, чтобы автоматически уходить от крупных провайдеров или считать европейского поставщика универсальной заменой, а о более зрелом методе выбора.
Компания должна заранее понимать, какие зависимости принимает, где нужна переносимость, какие условия выхода закрепить в контракте и какие части архитектуры должны оставаться переносимыми. Коммерческие барьеры могут снижаться, но перенос работающей системы всё равно остаётся инженерным проектом — поэтому облачная стратегия должна учитывать не только вход в платформу, но и управляемый выход из неё.
FAQ
Нужно ли европейским компаниям срочно уходить от AWS, Azure или Google Cloud?
Нет. DMA и Data Act не требуют от клиентов уходить от крупных облачных платформ. Они дают повод пересмотреть архитектуру, контракты и план выхода.
Делает ли Data Act миграцию между облаками простой?
Нет. Data Act может снизить стоимость и улучшить условия переноса данных, но не переносит автоматически приложения, права доступа, сети, мониторинг и операционные процессы.
Чем DMA важен для облачного рынка?
DMA важен как инструмент контроля рыночной власти крупных цифровых платформ. Для облачных клиентов это может повлиять на прозрачность условий, совместимость сервисов и переговорную позицию.
Европейский провайдер — лучшая альтернатива крупному облачному провайдеру?
Не всегда. Европейский провайдер может быть сильнее по требованиям к размещению данных, локальному соответствию и юрисдикции, но его нужно проверять по отказоустойчивости, поддержке и интеграциям.
Что нужно включать в запрос предложений или контракт с облачным провайдером?
Форматы выгрузки данных, сроки миграции, стоимость исходящего трафика, помощь при выходе, документированные интерфейсы, условия расторжения, обязательства по расходам и порядок передачи журналов, резервных копий и настроек.
Мультиоблако снижает зависимость от одного провайдера?
Да, но ценой большей сложности. Несколько облаков требуют отдельного управления сетью, безопасностью, наблюдаемостью, доступами, поддержкой и компетенциями команды.
Список источников
2. European Commission — “Data Act explained”
3. UK Competition and Markets Authority — “Cloud services market investigation: Final decision report”
