Настройка мультиоблачной инфраструктуры: AWS, GCP, Azure под ключ

Настройка мультиоблачной инфраструктуры (Multi-Cloud)

Мультиоблако не начинается с красивой архитектурной схемы на доске. Оно начинается с ситуации: основной провайдер упал на три часа, и бизнес потерял деньги. Или: контракт требует хранить данные в EU, а ML-пайплайны дешевле гонять в GCP. Или просто: одна команда исторически сидит на Azure, другая — на AWS, и объединять их в один аккаунт политически невозможно. Во всех трёх случаях нужна мультиоблачная инфраструктура — но устройство у неё будет принципиально разное. Мы проектируем и разворачиваем такие решения под ключ, с фокусом на реальные потребности, а не на абстрактные схемы.

Две разные задачи под одним названием

Есть Active/Active мультиоблако: приложение реально работает в двух облаках одновременно, трафик балансируется между ними, при падении одного — второй принимает всё. Это сложная, дорогая архитектура. Синхронизация данных между облаками, global load balancing, одинаковые версии приложения в двух местах — операционная нагрузка значительная.

Есть Active/Passive: основной провайдер обрабатывает трафик, резервный — прогрет и готов принять нагрузку за 15-30 минут. Данные реплицируются асинхронно. RPO — 15 минут, RTO — 30 минут. Это реалистичный вариант для большинства проектов.

И есть «мультиоблако по специализации»: Cloudflare Workers для edge-логики, AWS для compute и баз, GCS для дешёвого cold storage, Vercel для фронтенда. Каждый провайдер делает то, что у него получается лучше и дешевле. Связность через API — минимальная.

Прежде чем проектировать — важно понять, какую из этих трёх задач реально решаем.

Почему данные — самая сложная часть мультиоблака?

Compute в мультиоблаке — несложно. Kubernetes одинаково работает в EKS, GKE и AKS. Terraform управляет ресурсами всех трёх провайдеров. Проблема — данные. Базы данных не умеют нативно реплицироваться между облаками.

Варианты репликации PostgreSQL между AWS RDS и GCP Cloud SQL:

• Logical replication через pglogical — работает, но требует ручной настройки и мониторинга отставания
• Debezium CDC → Kafka (MSK или Confluent) → Consumer в целевом облаке — более надёжно, но сложнее
• Managed решения: Google Database Migration Service, AWS DMS — для одноразовой миграции подходит, для ongoing репликации — ограниченно

Latency между регионами разных провайдеров — 30-80ms в зависимости от географии. Для синхронных запросов это смерть. Всё, что ходит cross-cloud, должно быть асинхронным.

Terraform для мультиоблака

Один Terraform workspace, несколько провайдеров:

terraform {
  required_providers {
    aws = {
      source = "hashicorp/aws"
      version = "~> 5.0"
    }
    google = {
      source = "hashicorp/google"
      version = "~> 5.0"
    }
    azurerm = {
      source = "hashicorp/azurerm"
      version = "~> 3.0"
    }
  }
}

provider "aws" {
  region = var.aws_region
  assume_role {
    role_arn = var.aws_role_arn
  }
}

provider "google" {
  project = var.gcp_project_id
  region = var.gcp_region
}

Remote state — в S3 с DynamoDB locking, или в Terraform Cloud. State должен быть один — иначе outputs одного провайдера не смогут стать inputs другого.

Структура проекта делится по провайдерам:

infrastructure/
  shared/ # общие переменные, data sources
  aws/
    networking/
    compute/
    databases/
  gcp/
    networking/
    storage/
  ml-platform/
  global/
    dns/ # Cloudflare или Route 53 как глобальный DNS
    monitoring/

Сеть между облаками: как соединить?

Прямое соединение AWS и GCP — через Dedicated Interconnect (GCP) + Direct Connect (AWS) с общей точкой обмена на нейтральном co-location (Equinix, Digital Realty). Это дорого, но даёт предсказуемую latency.

Для большинства проектов — VPN mesh через WireGuard или Tailscale. Tailscale особенно удобен: агент устанавливается на ноды в обоих облаках, формирует mesh-сеть, все ноды видят друг друга по IP. Конфигурация — декларативная через Terraform Tailscale провайдер.

Если трафик между облаками идёт только через API (HTTP/gRPC) — достаточно публичных эндпоинтов с mTLS. Cert-manager выдаёт сертификаты, SPIFFE/SPIRE обеспечивает identity для сервисов вне зависимости от облака.

Kubernetes в мультиоблаке: GitOps и управление

Управление несколькими кластерами — через fleet management. ArgoCD с ApplicationSet и cluster generators разворачивает одни и те же приложения в EKS и GKE из единого git-репозитория. Разница между кластерами — в values-aws.yaml и values-gcp.yaml.

Пример ApplicationSet:

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: backend-service
  namespace: argocd
spec:
  generators:
    - clusters:
        selector:
          matchLabels:
            environment: production
  template:
    metadata:
      name: '{{name}}-backend'
    spec:
      project: default
      source:
        repoURL: https://github.com/company/k8s-configs
        targetRevision: main
        path: apps/backend
        helm:
          valueFiles:
            - values.yaml
            - 'values-{{metadata.labels.cloud}}.yaml'
      destination:
        server: '{{server}}'
        namespace: backend

Velero для бэкапов между облаками — снапшоты PVC из AWS EBS реплицируются в GCS как дополнительный DR-слой.

Мониторинг и observability: единая картина

Метрики из нескольких облаков собираются в единую систему. Prometheus federation или VictoriaMetrics с remote_write из каждого кластера в центральный Thanos. Grafana с datasources на оба облака — в дашбордах видно состояние всей инфраструктуры.

Для distributed tracing — OpenTelemetry Collector в каждом кластере, экспорт в Jaeger или Grafana Tempo. Trace проходит через сервисы в AWS и GCP — видно полную цепочку.

Типичные ошибки и как их избежать

Попытка сделать инфраструктуру полностью идентичной в обоих облаках — ловушка. AWS и GCP имеют разные примитивы: Load Balancer Controller в EKS vs GKE Ingress, EBS vs Persistent Disk, Security Groups vs VPC Firewall Rules. Пытаясь сделать одно-в-одно, тратишь время на борьбу с различиями, вместо того чтобы использовать сильные стороны каждого.

Абстракции типа Crossplane помогают — но добавляют свой уровень сложности и operational overhead.

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

• Архитектурный воркшоп: определяем сценарий (Active/Passive, Active/Active или специализация), выбираем провайдеров, фиксируем требования к RTO/RPO.
• Проектирование сети: выбор типа соединения (VPN, Direct Connect) и топологии.
• Развёртывание IaC: Terraform-модули для всех провайдеров, репозиторий кода, pipeline.
• Настройка GitOps: ArgoCD/Flux для синхронизации k8s-конфигов.
• Репликация данных: настройка CDC, мониторинг лага, план восстановления.
• Мониторинг и логи: централизованный Prometheus/Grafana/Loki, алерты по SLO.
• Документация runbook и обучение команды.

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

Начинаем с архитектурного воркшопа — определяем реальную задачу и выбираем минимально сложную архитектуру, которая её решает. Оценим ваш проект за 2 дня — просто свяжитесь с нами. 5+ лет опыта в мультиоблачных архитектурах, 30+ реализованных проектов — мы знаем, как обойти типичные ловушки. Пишите, чтобы получить консультацию и детальный план.