Google Cloud, Yandex Cloud и другие облака: чем отличаются и когда их берут

В https://courses.digitable.life/post/devops/11-aws/ мы разобрали AWS как эталон — не потому что он лучший, а потому что он задал словарь, которым все пользуются. В https://courses.digitable.life/post/devops/12-azure/ — увидели, что то же самое можно построить вокруг корпоративной идентичности и лицензий. Эта статья про третий вопрос: а если ни то, ни другое?

Три причины взять облако не из «большой двойки» встречаются в реальности почти всегда в чистом виде:

1. Технология. Есть ровно один сервис, который решает вашу задачу принципиально лучше, и он живёт в конкретном облаке. BigQuery, Spanner, Cloud Run — это про GCP. Так же было с Kubernetes, пока он не стал общим достоянием.
2. Юрисдикция и регулирование. Персональные данные граждан РФ по 152-ФЗ должны обрабатываться на территории РФ; часть организаций обязана работать с российским юрлицом и платить в рублях. Это не вопрос вкуса, это вопрос легальности бизнеса.
3. Деньги на конкретной оси. Egress, GPU, дисковый IOPS, лицензии. Оси разные, и по каждой есть провайдер, который дешевле гиперскейлера в разы, а не на проценты.

Всё остальное — «нам сказали, что там дешевле» — обычно не выдерживает столкновения со счётом за второй месяц. Разберём по порядку, начав с самого содержательного технически варианта.

Google Cloud: другая модель тех же вещей

GCP редко выигрывает у AWS «по сумме сервисов». Он выигрывает по нескольким конкретным осям и проигрывает по широте каталога. Начнём с каркаса, потому что именно он определяет, как вы будете жить в этом облаке.

Иерархия ресурсов: проект вместо аккаунта

В AWS единица изоляции — аккаунт, вещь тяжёлая: отдельная регистрация, отдельные квоты, отдельная боль при создании. В GCP та же роль у проекта, и проект создаётся одной командой за три секунды. Отсюда культурная разница: в GCP нормально иметь сотни проектов, по одному на сервис и окружение.

• Organization — корень, привязан к домену через Cloud Identity или Google Workspace. Без организации проекты «висят» на личном аккаунте — это первая вещь, которую надо исправить в любом серьёзном внедрении.
• Folder — вложенные папки для отделов и окружений; на них вешают политики.
• Project — граница квот, включённых API, биллинга и изоляции. Ресурс всегда принадлежит ровно одному проекту.

IAM в GCP устроен проще, чем в AWS, и это одновременно достоинство и ограничение. Allow-политика — это список привязок «роль → набор принципалов», и она наследуется вниз по дереву. Роль, выданная на папке, действует на все проекты внутри. Явного Deny исторически не было вовсе (deny-политики появились позже и применяются редко), поэтому главный инструмент ограничения — не запрет, а Organization Policy Constraints: «в этой папке нельзя создавать внешние IP», «нельзя выключать OS Login», «разрешены только регионы EU».

# Проекты — дешёвая сущность, создаём под сервис и окружение
gcloud projects create acme-api-prod --folder=123456789012
gcloud beta billing projects link acme-api-prod --billing-account=01ABCD-234567-89EFGH

# API выключены по умолчанию — включаем ровно нужные
gcloud services enable run.googleapis.com artifactregistry.googleapis.com \
  secretmanager.googleapis.com --project=acme-api-prod

# Ограничение на уровне папки: никаких внешних IP у виртуалок
gcloud resource-manager org-policies enable-enforce \
  compute.vmExternalIpAccess --folder=123456789012

Практическое следствие «включённых по умолчанию» API: в GCP почти всё выключено, пока вы явно не включили. Это спасает от случайных счетов, но регулярно ломает Terraform-планы с сообщением вида API [compute.googleapis.com] not enabled on project. Включение API — часть инфраструктурного кода, а не ручной шаг.

Сеть: VPC глобальна — и это меняет архитектуру

Самое заметное архитектурное отличие GCP. VPC в GCP — глобальный ресурс, подсети — региональные. Виртуалка в europe-west4 и виртуалка в us-east1 в одной VPC видят друг друга по приватным адресам без peering, без transit gateway, без единой строчки конфигурации.

Что это даёт на практике:

• Мультирегион перестаёт быть проектом на квартал. Добавить регион — добавить подсеть.
• Глобальный HTTP(S) Load Balancer — один анонимный IP на весь мир с anycast-маршрутизацией в ближайший здоровый бэкенд. В AWS аналог собирается из ALB в каждом регионе плюс Route 53 плюс Global Accelerator.
• Обратная сторона: единая плоскость управления сетью — единая зона отказа. Крупные сбои сети GCP исторически были глобальными, тогда как AWS ломался регионально.

Ещё одна практическая деталь: Cloud NAT тарифицируется иначе, чем NAT Gateway в AWS — есть почасовая плата за виртуалки, использующие шлюз, и плата за обработанный трафик, но нет ситуации «два шлюза по 45 $/мес просто за существование в двух AZ». Для маленьких инсталляций это ощутимо дешевле. А Private Google Access позволяет ходить в API Google без внешнего IP и без NAT вообще — то, ради чего в AWS приходится вручную заводить десяток VPC-endpoints.

Вычисления: главный аргумент — Cloud Run

В GCP есть привычные слои — Compute Engine (виртуалки), GKE (Kubernetes, о котором подробно в https://courses.digitable.life/post/devops/06-kubernetes/), Cloud Functions. Но настоящий дифференциатор — Cloud Run: вы отдаёте OCI-образ, слушающий порт из переменной PORT, и получаете HTTPS-эндпоинт, автоскейлинг от нуля, ревизии и разделение трафика. Без кластера, без нод, без CNI, без ingress-контроллера.

Экономика Cloud Run — главное, ради чего его берут. Тарификация посекундная по фактически выделенным vCPU и памяти, плюс плата за миллион запросов. Есть два режима, и разница между ними — типичный источник неожиданного счёта:

• CPU только во время запроса (по умолчанию). Между запросами инстанс не тарифицируется вообще. Идеально для неровного трафика. Но фоновые задачи, начатые после отправки ответа, останавливаются — «отправил ответ и дописал в очередь» не работает.
• CPU всегда выделен. Дешевле за секунду, инстанс живёт постоянно, фоновые потоки работают. Нужен для gRPC-стримов, воркеров, приложений с внутренним пулом/кэшем.

Прикидка на реальном сервисе: API на 1 vCPU / 512 МиБ, 20 запросов в секунду со средним временем ответа 120 мс, concurrency: 80. Одновременно активных инстансов — единицы, а не десятки, потому что Cloud Run по умолчанию шлёт до 80 параллельных запросов в один контейнер (в отличие от AWS Lambda, где на запрос ровно один инстанс). Счёт получается порядка 25–60 $/мес против ~75 $/мес только за control plane GKE, ещё до нод.

Отсюда честное правило выбора:

BigQuery: настоящая причина, по которой приходят в GCP

Если бы у GCP был один сервис, ради которого компании мигрируют целиком, это BigQuery. Хранилище отделено от вычислений полностью: данные лежат в колоночном формате, запрос поднимает произвольное число слотов на несколько секунд и отпускает их.

Две модели оплаты, и выбор между ними — главное решение:

• On-demand: платите за просканированные байты (порядка 6,25 $ за ТиБ, первый ТиБ в месяц бесплатно). Прекрасно на старте, катастрофа при аналитике-самообслуживании: один SELECT * по 40-терабайтной таблице стоит 250 $, и любой сотрудник с доступом к BI может его выполнить. Дважды. Случайно.
• Editions (слоты): покупаете вычислительную мощность с автоскейлингом. Предсказуемо, дешевле при постоянной нагрузке, требует управления резервациями.

-- Партиционирование и кластеризация — не оптимизация, а контроль расходов.
-- Без них каждый запрос сканирует таблицу целиком и платит за это.
CREATE TABLE analytics.events (
  event_time TIMESTAMP,
  user_id    STRING,
  event_type STRING,
  payload    JSON
)
PARTITION BY DATE(event_time)
CLUSTER BY event_type, user_id
OPTIONS (
  -- защита от «SELECT * без WHERE»: запрос обязан фильтровать по партиции
  require_partition_filter = TRUE,
  partition_expiration_days = 400
);

# Всегда проверяйте объём ДО выполнения — dry run бесплатен
bq query --use_legacy_sql=false --dry_run \
  'SELECT user_id FROM `acme.analytics.events` WHERE DATE(event_time) = "2026-07-10"'

# Query successfully validated. Assuming the tables are not modified,
# running this query will process 4823145984 bytes of data. (~4.5 ГиБ ≈ 0,03 $)

# И жёсткий предохранитель на уровне проекта
bq update --maximum_bytes_billed=1099511627776 acme-analytics

Обязательные к внедрению предохранители: maximum_bytes_billed на уровне проекта, квоты на пользователя в день, require_partition_filter на больших таблицах. Без них BigQuery — самый быстрый способ получить пятизначный счёт от человека, который просто «посмотрел данные».

Экономика GCP: чем скидки отличаются от AWS

Две вещи, о которых стоит знать заранее. Первая: egress в GCP по умолчанию дороже AWS — сетевой уровень Premium (трафик идёт по магистрали Google до ближайшей к клиенту точки) стоит порядка 0,12 $/ГБ. Переключение сети на Standard tier удешевляет, но трафик выходит в интернет в регионе размещения — для мирового аудитория это заметно по задержкам. Вторая: GKE берёт 0,10 $/час за кластер (около 73 $/мес) сверх стоимости нод; один зональный кластер на биллинг-аккаунт бесплатен.

Рабочий пример: Cloud Run из Terraform + деплой без ключей

Ключевая практика GCP, ради которой стоит перестраивать пайплайн, — Workload Identity Federation: CI обменивает свой OIDC-токен на короткоживущий токен сервисного аккаунта. Долгоживущих JSON-ключей в секретах не остаётся вовсе. Подробнее о модели угроз — в https://courses.digitable.life/post/devops/17-security-in-pipeline/.

# ---- Artifact Registry: реестр образов рядом с рантаймом ----
resource "google_artifact_registry_repository" "app" {
  location      = var.region          # тот же регион, что и Cloud Run — иначе платный трафик
  repository_id = "app"
  format        = "DOCKER"

  # Чистка мусора: без неё реестр растёт вечно и тихо
  cleanup_policies {
    id     = "keep-recent"
    action = "KEEP"
    most_recent_versions { keep_count = 20 }
  }
  cleanup_policies {
    id     = "drop-old-untagged"
    action = "DELETE"
    condition {
      tag_state  = "UNTAGGED"
      older_than = "604800s" # 7 дней
    }
  }
}

# ---- Сервисный аккаунт рантайма: отдельный от деплойного ----
resource "google_service_account" "runtime" {
  account_id   = "api-runtime"
  display_name = "Runtime SA для сервиса api (без прав на деплой)"
}

resource "google_cloud_run_v2_service" "api" {
  name     = "api"
  location = var.region
  ingress  = "INGRESS_TRAFFIC_INTERNAL_LOAD_BALANCER" # снаружи — только через глобальный LB

  template {
    service_account = google_service_account.runtime.email

    scaling {
      min_instance_count = 1   # 0 = экономия, но холодный старт; 1 = убирает p99-хвост
      max_instance_count = 40  # верхняя граница счёта при всплеске или атаке
    }

    containers {
      image = "${var.region}-docker.pkg.dev/${var.project}/app/api:${var.image_tag}"

      resources {
        limits = { cpu = "1", memory = "512Mi" }
        cpu_idle = true  # true = CPU только на время запроса (дешевле, без фоновых задач)
      }

      # Секреты монтируются из Secret Manager, а не кладутся в env открытым текстом
      env {
        name = "DATABASE_URL"
        value_source {
          secret_key_ref {
            secret  = google_secret_manager_secret.db_url.secret_id
            version = "latest"
          }
        }
      }

      startup_probe {
        http_get { path = "/healthz" }
        failure_threshold = 10
        period_seconds    = 3
      }
    }

    max_instance_request_concurrency = 80 # ключевой рычаг цены: сколько запросов на контейнер
  }

  traffic {
    type    = "TRAFFIC_TARGET_ALLOCATION_TYPE_LATEST"
    percent = 100
  }
}

# ---- Пул федерации для GitHub Actions ----
resource "google_iam_workload_identity_pool_provider" "github" {
  workload_identity_pool_id          = google_iam_workload_identity_pool.ci.workload_identity_pool_id
  workload_identity_pool_provider_id = "github"

  attribute_mapping = {
    "google.subject"       = "assertion.sub"
    "attribute.repository" = "assertion.repository"
    "attribute.ref"        = "assertion.ref"
  }

  # БЕЗ этого условия развернуть ваш прод сможет любой репозиторий на GitHub
  attribute_condition = "assertion.repository == 'acme/api' && assertion.ref == 'refs/heads/main'"

  oidc { issuer_uri = "https://token.actions.githubusercontent.com" }
}

# .github/workflows/deploy.yml — деплой без единого секрета в репозитории
name: deploy
on:
  push:
    branches: [main]

permissions:
  contents: read
  id-token: write   # обязательно: без этого GitHub не выдаст OIDC-токен

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - id: auth
        uses: google-github-actions/auth@v2
        with:
          workload_identity_provider: projects/123456789/locations/global/workloadIdentityPools/ci/providers/github
          service_account: deployer@acme-api-prod.iam.gserviceaccount.com
          # токен живёт ровно столько, сколько идёт деплой
          access_token_lifetime: 600s

      - uses: google-github-actions/setup-gcloud@v2

      - name: Сборка и push прямо в Artifact Registry
        run: |
          gcloud auth configure-docker ${{ vars.REGION }}-docker.pkg.dev --quiet
          IMAGE=${{ vars.REGION }}-docker.pkg.dev/${{ vars.PROJECT }}/app/api:${{ github.sha }}
          docker build -t "$IMAGE" .
          docker push "$IMAGE"

      - name: Постепенный вывод — сначала 10 % трафика
        run: |
          gcloud run deploy api --image "$IMAGE" --region ${{ vars.REGION }} \
            --no-traffic --tag candidate
          gcloud run services update-traffic api --region ${{ vars.REGION }} \
            --to-tags candidate=10

Разделение трафика по тегам ревизий — встроенный канареечный релиз без service mesh и без Argo Rollouts. Стратегии выката подробно разобраны в https://courses.digitable.life/post/devops/04-cd-and-release-strategies/; здесь важно, что в Cloud Run это две команды, а не отдельная подсистема.

Yandex Cloud: когда выбор делает не архитектор, а юрист

Yandex Cloud — не «GCP для России». Это самостоятельная платформа, выросшая из внутренней инфраструктуры Яндекса, с собственным набором сильных и слабых мест. Берут её по причинам, которые редко относятся к технике.

Почему берут

• 152-ФЗ и локализация персональных данных. Обработка ПДн граждан РФ должна происходить на территории РФ. YC даёт аттестованные сегменты под УЗ-1…УЗ-4, документы для проверок и готовые модели угроз.
• Юрлицо в РФ, рубли, закрывающие документы, НДС. Для компании с российской бухгалтерией это не «удобство», а условие возможности платить.
• Задержка. До московского пользователя из ru-central1 — единицы миллисекунд. Из Франкфурта — 25–40 мс на RTT, и это заметно на чувствительных к латентности приложениях.
• Доступность. С 2022 года у российских компаний просто нет надёжного доступа к AWS/GCP/Azure: оплата, санкционные ограничения, риск отключения. Это доминирующий фактор, каким бы техническим ни был спор.

Как устроено

Иерархия: организация → облако → каталог (folder) → ресурсы. Облако — единица биллинга и квот, каталог — единица изоляции: у каждого каталога своя сеть, свои сервисные аккаунты, свои ресурсы. Прод и стейдж — разные каталоги, иногда разные облака.

Регион фактически один — ru-central1 — с зонами доступности a, b, d (зона c была выведена из эксплуатации, что само по себе полезный урок: не хардкодьте список зон, читайте его из API). Отсутствие второго полноценного региона — важнейшее архитектурное ограничение: георезерв внутри YC вы не построите, он делается только через второго провайдера или собственную площадку.

Каталог сервисов покрывает основные потребности:

S3-совместимость Object Storage — стратегически важная деталь: boto3, mc, rclone, terraform с S3-бэкендом, Velero, Loki, Thanos работают почти без изменений. Это резко снижает стоимость входа и выхода. ClickHouse как управляемый сервис — сильная сторона: у гиперскейлеров его либо нет, либо он есть у третьих лиц.

Terraform в Yandex Cloud: две особенности, о которых узнаёшь больно

Первая: официальный реестр HashiCorp недоступен из РФ, поэтому провайдер ставится из зеркала Yandex. Вторая: многие команды используют https://courses.digitable.life/post/devops/09-terraform-and-iac/ с OpenTofu — форк не имеет тех же ограничений лицензии и распространения.

# ~/.terraformrc — зеркало провайдеров
provider_installation {
  network_mirror {
    url = "https://terraform-mirror.yandexcloud.net/"
    include = ["registry.terraform.io/*/*"]
  }
  direct {
    exclude = ["registry.terraform.io/*/*"]
  }
}

terraform {
  required_providers {
    yandex = { source = "yandex-cloud/yandex", version = "~> 0.115" }
  }

  # Стейт — в Object Storage, блокировки — в YDB (Dynamo-совместимый режим)
  backend "s3" {
    endpoints = { s3 = "https://storage.yandexcloud.net" }
    bucket    = "acme-tfstate"
    region    = "ru-central1"
    key       = "prod/k8s/terraform.tfstate"

    skip_region_validation      = true
    skip_credentials_validation = true
    skip_requesting_account_id  = true
    skip_s3_checksum            = true
  }
}

resource "yandex_kubernetes_cluster" "prod" {
  name       = "prod"
  network_id = yandex_vpc_network.main.id

  master {
    # Региональный мастер: реплики в трёх зонах, дороже зонального примерно втрое,
    # но зональный мастер = плановая недоступность control plane при работах
    regional {
      region = "ru-central1"
      dynamic "location" {
        for_each = yandex_vpc_subnet.zones
        content {
          zone      = location.value.zone
          subnet_id = location.value.id
        }
      }
    }
    version   = "1.30"
    public_ip = false          # доступ к API — только через bastion или VPN
  }

  service_account_id      = yandex_iam_service_account.k8s.id
  node_service_account_id = yandex_iam_service_account.k8s_nodes.id
  release_channel         = "STABLE"
  network_policy_provider = "CALICO"
}

resource "yandex_kubernetes_node_group" "workers" {
  cluster_id = yandex_kubernetes_cluster.prod.id
  version    = "1.30"

  instance_template {
    platform_id = "standard-v3"        # Ice Lake; v2 старее и не всегда дешевле
    resources {
      cores         = 4
      memory        = 8
      core_fraction = 100              # 5/20/50 % — дешёвые «долевые» ядра для стейджа
    }
    boot_disk { type = "network-ssd"; size = 64 }
    scheduling_policy { preemptible = false }
  }

  scale_policy {
    auto_scale { min = 3, max = 12, initial = 3 }
  }

  allocation_policy {
    dynamic "location" {
      for_each = ["ru-central1-a", "ru-central1-b", "ru-central1-d"]
      content { zone = location.value }
    }
  }
}

Два рычага цены, специфичных для YC и отсутствующих у гиперскейлеров в таком виде:

• core_fraction — гарантированная доля vCPU: 5 %, 20 %, 50 % или 100 %. Машина с core_fraction = 20 стоит примерно втрое дешевле и отлично подходит под стейдж, раннеры CI и служебные ноды. Для прод-нагрузки с латентностью — нет.
• Прерываемые ВМ — вытесняются в течение суток, дешевле примерно вдвое. Логика та же, что у Spot: батчи, CI, обработка очередей с ретраями.

# CLI yc — привычная эргономика, JSON на выходе
yc compute instance list --format json | jq -r '.[] | "\(.name)\t\(.status)\t\(.zone_id)"'
# api-1    RUNNING    ru-central1-a
# api-2    RUNNING    ru-central1-b
# worker-1 RUNNING    ru-central1-d

# Токен для kubectl — через плагин, без статических kubeconfig-секретов
yc managed-kubernetes cluster get-credentials prod --internal --force

# Проверить, во что обходится каталог за месяц
yc billing account list
yc resource-manager folder list-operations --id b1g... --limit 20

Честные ограничения

Не поддаваться маркетингу здесь так же важно, как и в случае AWS:

• Один регион. DR-стратегия уровня «упал регион» требует второго провайдера. Планируйте бэкапы наружу с первого дня.
• Глубина сервисов меньше. Нет аналогов Spanner, Athena, Step Functions в зрелом виде; IAM проще и грубее — нет полноценного эквивалента SCP и permissions boundary, разграничение делается структурой каталогов.
• Экосистема вокруг. Меньше готовых Terraform-модулей, меньше ответов на Stack Overflow, меньше специалистов на рынке, но заметно живее русскоязычные сообщества и быстрее реакция поддержки на корпоративных тарифах.
• Квоты. Стартовые квоты жёстче, чем ожидаешь: число ВМ, ядер, дисков, статических IP. Повышение — через тикет, и это не мгновенно. Закладывайте в план миграции.

Остальные: нишевые рычаги, а не замена

Oracle Cloud Infrastructure — тот случай, когда стоит перебороть предубеждение к вендору. Два реальных аргумента: постоянный бесплатный уровень с 4 ядрами Ampere ARM и 24 ГБ RAM (не триал, а Always Free) и 10 ТБ бесплатного egress в месяц с ценой 0,0085 $/ГБ дальше — на порядок дешевле гиперскейлеров. Плюс дешёвые bare metal и сильный HPC-сегмент. Минусы: меньше сервисов, менее удобная консоль, региональные квоты на дефицитные ARM-мощности.

Cloudflare — не облако общего назначения, а рычаг ровно по одной оси: egress не тарифицируется вообще. R2 (S3-совместимое хранилище без платы за исходящий трафик) в паре с Workers меняет экономику медиа, дистрибутива и публичных датасетов радикально. Типовая гибридная схема: вычисления в основном облаке, публичные объекты в R2, статика и кэш на краю.

VK Cloud — построен на OpenStack, что даёт понятную переносимость и вариант «то же самое, но в приватном контуре». Выбирают там, где нужен гибрид с собственной площадкой без изучения нового API.

Selectel — промежуточная категория между хостингом и облаком: облачные серверы, выделенные серверы, colocation в одной панели. Часто самый разумный ответ на вопрос «нам нужны просто мощные машины в РФ подешевле».

Cloud.ru — облако с корпоративной ориентацией и линейками на разных платформенных стеках; смотрят те, кому важны связи со сбербанковской экосистемой и импортозамещающие реестры.

Scaleway, OVHcloud, Hetzner Cloud — европейский ответ на вопрос суверенности и цены. Hetzner — отдельная история, где виртуалка с 4 vCPU и 8 ГБ стоит порядка 8 €/мес, а трафик практически бесплатен; про этот класс решений — следующая статья.

Alibaba Cloud — фактически безальтернативен, если у вас пользователи в материковом Китае: ICP-лицензирование, локальный CDN, работа за Великим файрволом.

Сравнение по осям, которые действительно решают

Одинаковая нагрузка: 6 приложений (суммарно 12 vCPU / 24 ГБ), PostgreSQL 4 vCPU / 16 ГБ с репликой, 500 ГБ объектов, 1 ТБ egress, Kubernetes или его эквивалент. Порядок величины, не коммерческое предложение.

Главный вывод из таблицы обычно читают неправильно. Разница между Hetzner и AWS — 770 $/мес, это примерно три часа работы инженера в неделю по московским или европейским ставкам. Если самостоятельная эксплуатация БД, бэкапов, мониторинга и обновлений кластера съедает больше трёх часов в неделю — экономии нет, есть перенос затрат из счёта в зарплату, где они хуже видны. Строгий разбор этой арифметики — в https://courses.digitable.life/post/devops/15-cloud-cost-and-tradeoffs/.

Как выбирать: дерево решений

Мультиоблако: когда это защита, а когда налог

Слово «мультиоблако» описывает четыре разные стратегии, и путать их дорого.

1. Мультиоблако по недосмотру. Маркетинг завёл что-то в одном облаке, дата-инженеры — в другом. Это не стратегия, это долг. Лечится инвентаризацией и консолидацией.
2. Осознанный выбор лучшего по оси. Вычисления в одном облаке, объекты в R2, аналитика в BigQuery. Работает, если границы проходят по данным, которые редко пересекают провайдера. Убивает egress, если пересекают часто.
3. Портируемость как страховка. Всё на Kubernetes, всё через Terraform, никаких проприетарных сервисов. Даёт рычаг на переговорах и путь к отступлению — ценой отказа от того, ради чего облако вообще берут.
4. Настоящий active-active в двух облаках. Двойная экспертиза, двойной мониторинг, репликация данных через интернет, вдвое больше режимов отказа. Оправдано при регуляторном требовании или при контрактных SLA, где простой стоит больше, чем вся эта конструкция.

Три вещи, которые определяют реальную стоимость выхода из облака и которые надо оценивать до входа, а не после:

• Гравитация данных. Вывезти 50 ТБ из S3 — порядка 4500 $ по обычной ставке. Хорошая новость: с 2024 года, под давлением EU Data Act, AWS, Google и Microsoft не берут плату за egress при полном уходе к другому провайдеру — но процедура заявительная, с условиями и сроками, и на частичную миграцию не распространяется.
• Замок в плоскости управления. IAM, сеть, наблюдаемость, теги, политики — переписываются целиком и всегда дольше, чем кажется.
• Замок в проприетарных сервисах. DynamoDB, BigQuery, Cosmos DB, Step Functions — у них нет прямого аналога. Замена = переписывание приложения, а не миграция.

Практический компромисс, который работает у большинства: держите переносимыми вычисления и наблюдаемость, разрешайте себе замок на данных. Контейнеры, Kubernetes, Terraform/OpenTofu, Prometheus и OpenTelemetry — переносимы почти бесплатно (см. https://courses.digitable.life/post/devops/08-helm-and-gitops/ и https://courses.digitable.life/post/devops/16-observability-and-oncall/). А отказ от BigQuery ради гипотетической миграции — это отказ от реальной выгоды сегодня ради страховки, которой вы, скорее всего, никогда не воспользуетесь.

Типичные ошибки

Общие для всех «не-AWS» облаков

• Считать по прайсу vCPU. Счёт формируют egress, NAT, IOPS, control plane, снапшоты и логи. Сравнение «GCE дешевле EC2 на 8 %» бессмысленно без остальных строк.
• Игнорировать зрелость экосистемы. Отсутствие готового Terraform-модуля, оператора или интеграции с вашим SIEM — это недели работы, которые не видны в сравнительной таблице.
• Не проверять квоты до миграции. «Развернём 200 ядер завтра» упирается в стартовую квоту 32 и тикет в поддержку на три дня.
• Забыть про выход. Оценивайте цену и срок ухода в момент входа. Если ответ «не знаем» — вы приняли решение вслепую.

Специфичные для GCP

• SELECT * в BigQuery без партиционного фильтра. Один запрос — четырёхзначный счёт. Ставьте maximum_bytes_billed и require_partition_filter до того, как дадите доступ аналитикам.
• Забыть, что VPC глобальна. Пересечение CIDR подсетей в разных регионах ломает всё сразу, а не «только в этом регионе». Планируйте адресное пространство централизованно.
• Оставить Premium tier для нагрузки, которой он не нужен. Внутренние сервисы и бэкапы прекрасно живут на Standard tier за существенно меньшие деньги.
• Держать долгоживущие JSON-ключи сервисных аккаунтов. Это самый распространённый способ потерять GCP-проект. Только Workload Identity Federation.
• Cloud Run с cpu_idle = true и фоновой работой после ответа. Задача просто не выполнится, и вы узнаете об этом по расхождению данных, а не по ошибке.

Специфичные для Yandex Cloud

• Полагаться на одну зону доступности. Зона c выводилась из эксплуатации — миграция была плановой, но обязательной. Раскладывайте по трём зонам и читайте список зон из API.
• Считать, что георезерв есть. Второго региона нет. Бэкапы наружу (другой провайдер или собственное хранилище) — обязательная часть проекта, а не «когда-нибудь потом».
• Зональный мастер Kubernetes в проде. Экономия в пару тысяч рублей оборачивается недоступностью API кластера во время работ — и неработающим автоскейлингом в этот момент.
• core_fraction меньше 100 на прод-нагрузке. Латентность плавает непредсказуемо, и это очень трудно диагностировать по метрикам приложения.
• Провайдер Terraform из основного реестра. Настройте зеркало в ~/.terraformrc централизованно, иначе каждый новый инженер потратит на это полдня.

Мини-итог

• GCP отличается от AWS не набором сервисов, а моделью: дешёвые проекты вместо тяжёлых аккаунтов, наследуемый IAM вместо явных Deny, глобальная VPC вместо региональных. Это упрощает мультирегион и усложняет жёсткое разграничение прав.
• Cloud Run — самая низкая эксплуатационная нагрузка на рынке для stateless HTTP-сервисов. Если у вас меньше пятнадцати сервисов и нет платформенной команды, это почти всегда правильный ответ в GCP.
• BigQuery — реальная причина миграций и реальная причина катастрофических счетов. Предохранители ставятся до первого запроса, а не после.
• Yandex Cloud выбирают по юрисдикции, задержке и возможности платить — и это законные причины. Технически платформа зрелая на основном пути, но один регион и более простой IAM меняют проектирование надёжности и разграничения.
• Egress — ось, по которой облака различаются на два порядка. Если трафика больше нескольких терабайт в месяц, он определяет выбор сильнее, чем всё остальное вместе.
• Мультиоблако бесплатно только на уровне вычислений и наблюдаемости. На уровне данных оно стоит денег всегда — вопрос лишь в том, платите вы за это осознанно.
• Цена выхода — часть цены входа. Считайте её в тот же день, когда подписываете договор.

Источники

• Google Cloud Architecture Framework — аналог Well-Architected: надёжность, безопасность, стоимость, операции.
• Google Cloud resource hierarchy и IAM overview — первоисточник по наследованию политик.
• VPC network overview — почему сеть глобальная и что из этого следует.
• Cloud Run documentation и Cloud Run pricing — режимы тарификации CPU и конкурентность.
• BigQuery: контроль расходов — квоты, maximum_bytes_billed, партиционирование.
• Workload Identity Federation и google-github-actions/auth — деплой без статических ключей.
• Google Cloud Pricing Calculator — считать до, а не после.
• Документация Yandex Cloud и калькулятор — актуальные тарифы и квоты.
• Yandex Cloud Terraform provider и зеркало провайдеров — рабочая установка из РФ.
• Соответствие требованиям 152-ФЗ в Yandex Cloud — модель ответственности и аттестация.
• Oracle Cloud Free Tier — состав Always Free, включая ARM-мощности и egress.
• Cloudflare R2 pricing — экономика хранения без платы за egress.
• EU Data Act и отмена платы за перенос данных — регуляторная причина изменений 2024 года.

Что дальше

Мы прошли по всей линейке публичных облаков и почти на каждом шаге упирались в один и тот же вопрос: а не переплачиваем ли мы за управляемость, которая нам не нужна? Иногда правильный ответ — выделенный сервер за 60 € в месяц, который делает работу кластера за 900 $. Об этом — следующая статья: VPS, VDS, выделенные серверы и DigitalOcean/Hetzner: когда простое дешевле облака.