Настройка мульти-облачного деплоя (AWS + GCloud / Azure)
Мульти-облачный деплой — это одновременное использование двух и более облачных провайдеров для запуска приложения. Мотивация бывает разной: защита от outage одного провайдера, регуляторные требования, использование уникальных сервисов конкретного облака, ценовая оптимизация. Каждая мотивация предполагает разную архитектуру.
Сценарии мульти-облака
Резервирование (DR). Основной деплой в AWS, резервный в GCP. Активируется только при полном outage AWS. Минимальная сложность: данные реплицируются через managed сервисы или собственную логику.
Распределение нагрузки. Разные компоненты в разных облаках: веб-слой в AWS (ближе к пользователям NA), ML-инференс в GCP (TPU/GPU по более выгодной цене), данные в Azure (для клиентов на Microsoft стеке).
Полный active-active. Оба облака одновременно принимают трафик. Самый сложный вариант — синхронизация состояния между облаками.
Сетевая связность между облаками
Прямой трафик между AWS и GCP через публичный интернет — нестабильно и небезопасно для репликации данных.
Megaport / Equinix Cloud Exchange: физическое соединение через точку обмена трафиком. Минимальная латентность, стабильная пропускная способность. Оптимально для production.
AWS Direct Connect + GCP Interconnect в одну точку обмена: более сложно, но даёт выделенный канал без зависимости от публичного интернета.
Site-to-site VPN: IPSec туннели между VPC (AWS) и VPC Network (GCP). Быстрее настроить, менее надёжно, ограниченная пропускная способность.
Terraform для мульти-облачного деплоя
Terraform управляет ресурсами в нескольких облаках из одной конфигурации:
terraform {
required_providers {
aws = { source = "hashicorp/aws", version = "~> 5.0" }
google = { source = "hashicorp/google", version = "~> 5.0" }
}
}
provider "aws" {
region = "us-east-1"
}
provider "google" {
project = "my-project"
region = "us-central1"
}
# AWS: основной кластер
resource "aws_eks_cluster" "main" { ... }
# GCP: DR кластер / ML-компоненты
resource "google_container_cluster" "dr" { ... }
DNS-маршрутизация между облаками
Cloudflare Load Balancing — работает с endpoints в любых облаках. Origin pools:
- AWS ALB (us-east-1) — weight 80
- GCP Cloud Load Balancing (us-central1) — weight 20
Failover: при деградации AWS pool — Cloudflare перенаправляет весь трафик в GCP.
Route 53 + GCP Cloud DNS при active-active: CNAME с health check, TTL 60 секунд.
Синхронизация данных
Объектные хранилища: rclone sync S3 → GCS или наоборот. Либо приложение пишет в оба одновременно (dual write pattern).
Базы данных: CockroachDB, YugabyteDB, или Spanner (только GCP) нативно поддерживают multi-region/multi-cloud через репликацию Raft. Альтернатива — Debezium CDC из PostgreSQL в Kafka, consumer пишет в GCP DB.
Секреты: HashiCorp Vault — единая точка для обоих облаков. Vault кластер размещается в одном облаке, приложения в обоих читают из него через mTLS.
Kubernetes как унифицирующий слой
При работе с Kubernetes в обоих облаках (EKS + GKE) можно использовать единый control plane через:
- Anthos (Google): управляет кластерами в GKE, EKS, AKS из одной консоли
- Azure Arc: аналог от Microsoft
- Rancher: open source multi-cluster management
Единый GitOps workflow (ArgoCD или Flux) деплоит одни и те же манифесты в оба кластера.
Сложности и как с ними работать
Разные API и сервисы. AWS S3 ≠ GCS (хотя очень похожи). Использовать абстракции (boto3 + google-cloud-storage за общим интерфейсом) или libcloud.
Разные IAM модели. Workload Identity Federation позволяет GCP сервисам получать временные AWS credentials через OIDC.
Observability. Централизованный мониторинг обязателен. Datadog, Grafana Cloud, или OpenTelemetry Collector, агрегирующий метрики из обоих облаков.
Latency. Межоблачные запросы добавляют 50-150ms. Архитектура должна минимизировать synchronous cross-cloud calls.
Сроки реализации
- Сетевая связность (VPN или Interconnect) — 3-7 дней
- Terraform модули для обоих облаков — 5-10 дней
- DNS failover + load balancing — 2-3 дня
- Синхронизация данных — 5-14 дней (зависит от выбранного метода)
- Observability + тестирование — 3-5 дней
Итого: 4-8 недель для полноценного мульти-облачного деплоя.