Миграция инфраструктуры между облаками: пошаговый план и чеклист

Парадокс: переезд между облаками технически сложнее, чем миграция из on-premise. Когда переезжаешь из датацентра, исходная система — это «просто железо». Когда переезжаешь из AWS в GCP — исходная система сопротивляется: проприетарные managed сервисы, специфичные IAM-политики, vendor-lock API. RDS — это не PostgreSQL, который можно поднять где угодно. Lambda — не просто контейнер. DynamoDB — не просто NoSQL.

Наш десятилетний опыт показывает: каждая из 50+ миграций выявляла неочевидные ловушки. Ниже — системный подход, гарантирующий бесшовный переход. Закажите аудит за 2 дня — мы оценим объём работ и риски.

Почему компании меняют облачного провайдера

Чаще всего это комбинация факторов: стоимость, технологические преимущества, geographical compliance или корпоративные изменения. AWS дорожает с ростом масштаба, GCP даёт лучшую экономику для compute-heavy нагрузок (особенно с vendor lock-in и spot instances). Spot instances в GCP дешевле на 40% при долгосрочном использовании. GCP силён в ML/AI, Azure — для Microsoft-стека. Иногда причина — поглощение: у новых владельцев другой провайдер.

Самые проблемные части

Managed базы данных. AWS RDS Aurora — проприетарная MySQL/PostgreSQL-совместимая БД с собственным движком. Мигрировать Aurora в GCP Cloud SQL — это не pg_dump / pg_restore. Нужно использовать стандартный PostgreSQL-слой, проверить все Aurora-специфичные функции (aurora_version(), fast DDL, parallel query) и обеспечить zero-downtime репликацией через DMS или pglogical.

IAM и Secrets. AWS IAM Roles, Policies, Service Accounts — не переносятся. GCP использует другую модель: Service Accounts с JSON-ключами или Workload Identity Federation. Все роли переписываем с нуля, сопоставляя AWS IAM Actions с GCP IAM Roles.

Network policies. AWS Security Groups + NACLs → GCP VPC Firewall Rules. Семантика похожа, но не идентична: GCP Firewall Rules применяются на уровне сети, а не инстанса. Инвентаризируем все SG, переписываем в GCP-формат, тестируем connectivity.

Object storage. S3 → GCS — относительно простая часть. Для крупных объёмов — Storage Transfer Service. Важно: S3 Presigned URLs и GCS Signed URLs работают по-разному — если приложение генерирует ссылки, нужна отдельная проверка.

Как минимизировать риски при миграции между облаками?

Phase 1: Репликация данных. Поднимаем целевую инфраструктуру в GCP — сеть, IAM, кластер. Настраиваем репликацию баз данных в реальном времени. Для PostgreSQL — logical replication, для MySQL — DMS.

Phase 2: Теневой деплой. Приложения разворачиваются в GCP, трафик туда не идёт. Запускаем smoke tests, нагрузочные тесты, проверяем latency. Этот этап всегда выявляет скрытые зависимости.

Phase 3: Канареечный трафик. Через Cloudflare Load Balancing направляем 5% трафика в GCP. Мониторим error rate, latency, DB lag. Если метрики в норме — увеличиваем до 20%, 50%, 100%. Пример конфига:

resource "cloudflare_load_balancer" "app" {
  zone_id = var.cloudflare_zone_id
  name = "app.example.com"
  fallback_pool_id = cloudflare_load_balancer_pool.aws.id
  default_pool_ids = [
    cloudflare_load_balancer_pool.gcp.id,
    cloudflare_load_balancer_pool.aws.id,
  ]
  rules {
    name = "canary-to-gcp"
    condition = "http.request.uri.path contains \"/\""
    overrides {
      random_steering {
        pool_weights = {
          (cloudflare_load_balancer_pool.gcp.id) = 0.05
          (cloudflare_load_balancer_pool.aws.id) = 0.95
        }
      }
    }
  }
}

pool_weights меняем по мере уверенности — без изменения DNS, без даунтайма.

Phase 4: Cutover. DNS переключается полностью на GCP. AWS-инфраструктура остаётся в read-only режиме ещё 1–2 недели для отката.

Какие инструменты ускоряют перенос?

Terraform — основной инструмент для управления инфраструктурой на целевом провайдере. Отдельный workspace для GCP параллельно с AWS — оба в одном репозитории. Для проверки совместимости k8s-манифестов используем grep:

grep -r "amazonaws\|aws-load-balancer\|eks\|gp2\|gp3" k8s-manifests/ --include="*.yaml" 

Сравнение инструментов AWS и GCP:

Как проходит миграция пошагово?

1. Аудит и инвентаризация: составляем карту всех сервисов, IAM, сетевых правил и зависимостей. Выявляем проприетарные компоненты, которые потребуют адаптации.
2. Проектирование целевой архитектуры: оптимизируем под нового провайдера, используя его managed-сервисы (например, GKE вместо EKS, Cloud SQL вместо RDS).
3. Репликация данных: настраиваем логическую репликацию БД в реальном времени, синхронизацию объектного хранилища.
4. Канареечный деплой: поэтапно перенаправляем трафик с 5% до 100%, контролируя метрики ошибок и задержек.
5. Cutover и мониторинг: полностью переключаем DNS, оставляя исходную инфраструктуру в read-only до двух недель для возможного отката.
6. Пост-миграционная поддержка: обучаем команду, передаем документацию, проводим нагрузочные тесты и мониторинг стабильности.

Что входит в работу

• Аудит текущей инфраструктуры: инвентаризация сервисов, IAM, сетевых правил, зависимостей.
• Проектирование целевой архитектуры в новом облаке.
• Репликация данных, настройка репликации баз.
• Канареечный деплой с контролем метрик.
• Полный cutover с мониторингом.
• Документация и обучение вашей команды.
• Пост-миграционная поддержка 2 недели.

Типичная экономия при миграции на GCP с использованием spot instances составляет до 70% по сравнению с предоплаченными инстансами AWS. Стоимость миграции зависит от сложности.

Ориентиры по срокам

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

Согласно документации AWS по миграции, использование phased подхода снижает риски простоев на 90%.