Что нужно знать до начала
Это практический разбор миграции с зарубежных облаков (AWS, Azure, GCP) на российские. Конкретные суммы штрафов и формулировки 152-ФЗ меняются — сверяйте актуальную редакцию перед принятием решения и финальную оценку рисков доверьте юристу. Сроки и расходы зависят не от объёма данных, а от связанности архитектуры — поэтому честная оценка начинается с карты зависимостей, а не с прайса за гигабайт.
Если ваш продукт всё ещё живёт в AWS, Azure или Google Cloud, а пользователи — в России, в 2026 году это уже не «технический долг на потом», а вопрос с дедлайном. Локализация персональных данных стала жёстче, штрафы выросли в разы, а оплата зарубежного облака из России превратилась в отдельный квест. Хорошая новость: рынок российских облаков за это время вырос из «выживания после ухода вендоров» в зрелый сегмент с собственными лидерами и почти полным набором аналогов. Плохая — миграция редко бывает «просто перенести серверы», и большинство проблем не в данных, а в managed-сервисах и скрытых зависимостях.
Если коротко: мигрировать имеет смысл, когда вы храните или собираете персональные данные пользователей из России (тогда это требование 152-ФЗ, а не выбор), когда оплата и поддержка зарубежного облака стали ненадёжными, или когда вы хотите сократить инфраструктурные расходы. Сам перенос — от нескольких недель до нескольких месяцев, и зависит он не от количества гигабайт, а от того, сколько у вас завязано на проприетарные managed-сервисы провайдера.
01 · Почему в 2026 мигрируют: три реальных драйвера
152-ФЗ и выросшие штрафы. Закон требует, чтобы сбор персональных данных россиян велся с использованием серверов, расположенных в России (ч. 5 ст. 18 152-ФЗ). Нарушение локализации — это административка по ст. 13.11 КоАП. После изменений, вступивших в силу с 2025 года, санкции заметно выросли: за нарушение локализации для юрлиц это порядка 1–6 млн ₽ за первое нарушение и 6–18 млн ₽ за повторное, а за неправомерную обработку и утечки появились оборотные штрафы, доходящие до сотен миллионов рублей. Роскомнадзор в 2026 году усилил проверки. Важная деталь: закон не запрещает трансграничную передачу данных, которые уже были собраны в базах на территории России, — но новый сбор должен идти на российские серверы.
Оплата и надёжность зарубежного облака. Оплатить AWS / Azure / GCP из России в 2026 году можно только обходными путями, а доступ к части сервисов и поддержке нестабилен. Для бизнеса, которому инфраструктура нужна как коммунальная услуга, это операционный риск, а не удобство.
Экономика. Перенос в Россию часто позволяет сократить инфраструктурные расходы — иногда в несколько раз, особенно если вы платили за premium-сервисы и egress. Оговорка: российские облака в 2026 году дорожают, поэтому считать экономику нужно на конкретной конфигурации, а не по обещаниям «дешевле в разы».
02 · Что переносится один в один, а что придётся переделывать
Главная ошибка планирования — считать, что «облако есть облако». На уровне базовых кирпичей аналоги в России есть и зрелые; ломается обычно верхний, «удобный» слой.
| Сервис в AWS / Azure / GCP | Аналог в российских облаках | Насколько просто перенести |
|---|---|---|
| Виртуальные машины (EC2 / Azure VM / GCE) | Compute / виртуальные серверы у любого крупного провайдера | Просто — прямой аналог |
| Объектное хранилище (S3 / Blob / GCS) | S3-совместимое объектное хранилище | Просто — обычно S3-совместимый API |
| Управляемые БД (RDS / Cloud SQL) | Managed PostgreSQL / MySQL / ClickHouse | Средне — есть аналоги, но проверять версии и расширения |
| Kubernetes (EKS / AKS / GKE) | Managed Kubernetes | Средне — переносимо, но различия в аддонах / сети |
| Serverless / FaaS (Lambda, Cloud Functions) | Cloud Functions и serverless-контейнеры (лидер по зрелости — Yandex Cloud) | Сложнее — логика и триггеры переписываются |
| NoSQL вроде DynamoDB | Прямого «один-в-один» аналога часто нет; решается через YDB или другую модель | Сложно — нередко требуется редизайн слоя данных |
| Проприетарные очереди, шина событий, специфические ML-сервисы | Частичные аналоги, иногда самостоятельная реализация | Сложно — оценивать индивидуально |
Вывод простой: чем больше вы использовали «фирменные» сервисы конкретного облака, тем больше будет переделки. Чем ближе ваша архитектура к открытым стандартам (PostgreSQL, S3-совместимое хранилище, обычный Kubernetes), тем дешевле и быстрее переезд.
03 · Российские облака в 2026: на что смотреть при выборе
Подробное сравнение восьми провайдеров у нас есть в отдельном разборе — «8 российских облаков для production-продукта в 2026». Если коротко, провайдеры различаются по профилю, и под миграцию выбирают не «самый известный», а тот, чей профиль совпадает с задачей:
- Cloud-native и serverless — сюда чаще берут Yandex Cloud (лидер по зрелости serverless в России) и Cloud.ru с богатым PaaS.
- Managed-базы и Big Data — сильная сторона VK Cloud.
- IaaS, bare metal и аттестованные сегменты — Selectel и провайдеры с сертификацией под защищённые данные (УЗ-1, ГОСТ Р 57580, требования ФСТЭК, PCI DSS).
- Комплаенс-первый подход — провайдеры с аттестованной инфраструктурой (например, сегменты MWS Cloud, Cloud.ru, VK Cloud, аттестованный Selectel).
Отдельный тренд 2026 года — мультиоблако: компании специально распределяют нагрузку между двумя провайдерами, чтобы застраховаться от роста тарифов и сбоев. Для критичных систем это уже норма, а не паранойя.
04 · Как выглядит план миграции
Хорошая миграция — это не «ночь переключения», а последовательность проверяемых шагов, где на каждом этапе есть путь назад.
- Аудит и карта зависимостей. Что у вас реально работает: сервисы, managed-компоненты, интеграции, где живут персональные данные, какие процессы CI/CD и мониторинга завязаны на текущее облако. Этот шаг определяет всю стоимость переезда.
- Выбор целевого провайдера и архитектуры. Под профиль нагрузки и требования 152-ФЗ. Здесь же решается, что переносим как есть, что заменяем аналогом, а что переписываем.
- Подготовка целевого окружения. Сеть, доступы, инфраструктура как код, базовый мониторинг и логирование — до переноса данных, а не после.
- Перенос данных и сервисов инкрементально. Сначала некритичное, затем — основное, с проверкой на каждом шаге. Где возможно — параллельная работа старого и нового окружения.
- Переключение и проверка. Перевод трафика (часто поэтапно), проверка работоспособности, нагрузки, индексируемости и целостности данных, и только потом — отключение старого.
- Документация и передача. Чтобы инфраструктуру можно было поддерживать без зависимости от конкретного человека.
05 · Подводные камни, на которых проваливаются миграции
Большинство провалов — не в коде, а в недооценённой связанности.
- Managed-сервисы без прямого аналога. Если бизнес-логика завязана на DynamoDB, специфические очереди или фирменный ML-сервис, перенос превращается в редизайн. Это надо обнаружить на аудите, а не на переключении.
- Скрытые зависимости. Хардкод регионов, эндпоинтов, IAM-ролей, внешних вебхуков и IP-адресов всплывает в самый неподходящий момент.
- Данные и downtime. Большие базы и объектные хранилища переносятся не мгновенно; нужен план синхронизации, окно и, главное, путь отката, если что-то пошло не так.
- Egress и время на трансфер. Выгрузка больших объёмов из зарубежного облака стоит денег и времени — это отдельная строка в смете и графике.
- «Переключили и забыли». Без нагрузочного теста и параллельного прогона новое окружение может вести себя иначе под реальным трафиком.
Профессиональная миграция как раз и отличается тем, что эти риски находят на этапе карты зависимостей, а переключение делают обратимым.
06 · Сколько это занимает
Честный ответ — «зависит», но диапазон предсказуем: от нескольких недель для компактного сервиса на стандартных компонентах до нескольких месяцев для платформы с обилием managed-сервисов и интеграций. Сроки двигают три вещи:
- объём данных,
- число сервисов,
- степень привязки к проприетарным возможностям исходного облака.
Чем стандартнее стек, тем быстрее; чем больше «магии» конкретного провайдера — тем дольше.
Итог · Ключевые факты (можно цитировать)
- По 152-ФЗ сбор персональных данных россиян должен вестись на серверах в России (ч. 5 ст. 18); нарушение — по ст. 13.11 КоАП.
- Штрафы за нарушение локализации для юрлиц — порядка 1–6 млн ₽ (первое нарушение) и 6–18 млн ₽ (повторное); за неправомерную обработку и утечки введены оборотные штрафы до сотен миллионов рублей (усиление — с 2025 года).
- Базовые сервисы (виртуалки, S3-совместимое хранилище, managed PostgreSQL / MySQL, Kubernetes) переносятся предсказуемо; проприетарные (Lambda, DynamoDB и аналоги) требуют переработки.
- Реалистичный срок миграции — от нескольких недель до нескольких месяцев в зависимости от связанности архитектуры.
Данные актуальны на июнь 2026; правовые формулировки и тарифы меняются — проверяйте перед решением.
Планируете переезд с зарубежного облака или приводите инфраструктуру под 152-ФЗ? H-Studio — architecture-first студия разработки: начинаем с архитектурного спринта и карты зависимостей, переносим данные, сервисы и DevOps-процессы инкрементально и с обратимым переключением, чтобы миграция не превратилась в простой и переделку. Расскажите о вашей инфраструктуре — оценим объём, риски и реалистичный срок.
Частые вопросы
Обязательно ли переносить инфраструктуру в Россию из-за 152-ФЗ? Если вы собираете персональные данные пользователей из России, закон требует, чтобы их сбор велся на серверах в России. Это не обязательно «перенести вообще всё», но база с персональными данными должна быть локализована. Точную конфигурацию и зону ответственности лучше согласовать с юристом.
Что сложнее всего перенести с AWS? Не данные, а проприетарные managed-сервисы — serverless-логику (Lambda), NoSQL вроде DynamoDB, фирменные очереди и ML-сервисы. Для них часто нет аналога «один в один», и слой приходится перепроектировать.
Можно ли мигрировать без простоя? Во многих случаях да — за счёт параллельной работы старого и нового окружения и поэтапного перевода трафика. Гарантия «нулевого простоя» зависит от архитектуры и определяется на этапе аудита.
Сколько стоит миграция? Стоимость определяется не объёмом данных, а связанностью: числом сервисов, количеством проприетарных компонентов и интеграций. Поэтому честная оценка начинается с карты зависимостей, а не с прайса за гигабайт.
Какое российское облако выбрать? То, чей профиль совпадает с задачей: serverless и cloud-native, managed-базы, аттестованный сегмент под защищённые данные. Подробное сравнение — в нашем разборе «8 российских облаков для production-продукта в 2026».
Что важнее — выбрать провайдера или провести аудит? Аудит. Без карты зависимостей выбор провайдера превращается в гадание: вы не знаете, какие именно managed-сервисы критичны для вашей бизнес-логики, какие интеграции придётся переделывать и сколько данных реально нужно перенести. Хороший аудит занимает несколько дней — и определяет всю экономику переезда.
Источники research: klerk.ru/674017, comply.ru (локализация с 01.07.2025), cloudindex.ru/mapper, itsumma cloudscomparison, cloud4y cloud-migration-2026, habr x-com (рост цен), habr amvera (serverless аналоги).