Переезжаем из AWS в Yandex Cloud: IAM, сеть и object storage под лупой

Миграция с AWS в Yandex Cloud - тема, которую мы откладывали месяца три. Клиент - средний e-commerce, инфраструктура не огромная, но и не игрушечная: несколько десятков виртуалок, PostgreSQL на RDS, несколько бакетов S3 с общим объёмом в районе 15 ТБ, плюс CloudFront для статики. Когда расчёты в евро перестали сходиться с реальностью, разговор о переезде стал неизбежным.

Спойлер: мы не заменили AWS на Yandex Cloud с закрытыми глазами. Это другая платформа с другой логикой, и некоторые различия были неочевидны даже нам.

IAM: не то же самое, но работает

В AWS за годы выросла сложная модель - IAM-роли, политики с JSON-синтаксисом, permission boundaries, SCP на уровне организации. Всё это мощно, но требует привычки.

Yandex Cloud предлагает IAM на основе ролей и сервисных аккаунтов. Сервисный аккаунт - аналог IAM-роли для EC2, но логика назначения отличается. Роли в YC привязываются к ресурсу или папке (folder), что немного меняет привычный AWS-паттерн, где всё крутится вокруг политик на уровне аккаунта.

Что нас немного притормозило - отсутствие inline-политик с мелкозернистыми действиями типа s3:GetObject на конкретный путь. Yandex Object Storage поддерживает bucket policy в S3-совместимом формате, и это работает, но доступ к bucket policy через консоль YC в середине 2023 года - это приключение с документацией. В итоге перешли на terraform и всё стало опрятнее.

Интеграция через федерацию удостоверений (SAML 2.0) у YC есть - клиент использовал корпоративный IdP, и это подключилось без особых мучений.

Сеть: VPC другого поколения

AWS VPC - зрелая штука с огромным количеством опций. Yandex VPC устроен проще: сети, подсети, route tables, security groups. Для большинства задач этого достаточно.

Что приятно удивило: подсети в YC создаются сразу с привязкой к зоне доступности, и топология становится немного чище. В AWS привыкаешь к тому, что AZ-аффинити настраивается косвенно через Launch Template и много где вручную.

Что пришлось решать: NAT-gateway в Yandex Cloud - это отдельный сервис NAT Instance (управляемый NAT появился относительно недавно). Клиент использовал NAT gateway в AWS для выхода из приватных подсетей, и здесь пришлось либо поднимать NAT instance на виртуалке, либо использовать managed NAT. Выбрали managed - дороже, чем в AWS пропорционально трафику, но без головной боли с поддержкой.

Приватные зоны DNS работают ожидаемо, с переменной Cloud DNS. VPN до офиса клиента подняли через Cloud Interconnect / IPSec - прошло без особых происшествий.

Object Storage: где деньги

Вот это - самое интересное с точки зрения бюджета. Yandex Object Storage совместим с S3 API, поэтому большинство инструментов - rclone, aws cli с кастомным endpoint, MinIO Client - работают из коробки. Про MinIO как S3-gateway для отечественных облаков напишем отдельно.

По стоимости хранения: YC Object Storage при сопоставимых объёмах обходится заметно дешевле AWS S3, особенно на операциях PUT/GET при высокой интенсивности. Исходящий трафик внутри России значительно дешевле, чем в AWS при выгрузке в Европу.

Что нужно учесть:

• Lifecycle policies. Поддерживаются, но интерфейс управления ими в консоли YC требует внимания - некоторые параметры принимаются только через API/terraform.
• Versioning и MFA Delete. Versioning есть, MFA Delete в YC Object Storage на середину 2023 не поддерживается. Для клиентов с требованиями compliance это важная деталь.
• Multipart upload. Работает, ограничения близки к AWS.
• CDN. Yandex Cloud CDN интегрируется с Object Storage нативно, заменили CloudFront без боли.

SberCloud как альтернатива тоже смотрели. По feature-set он отстаёт от YC, документация менее подробная, но тарифы в ряде сценариев интереснее. Для клиента выбрали YC - зрелость платформы и количество managed-сервисов решили.

Где мы сейчас

Перенос основной нагрузки занял около трёх недель. Параллельная работа обеих сред - ещё месяц. Kubernetes-кластер разворачиваем уже в YC через Deckhouse, что избавляет от необходимости самостоятельно готовить managed K8s на базе Yandex Managed Kubernetes - у клиента специфические требования к конфигурации узлов.

PostgreSQL переехал с RDS на Yandex Managed Service for PostgreSQL - это отдельная история, связанная с тем, что версия на RDS отличалась от того, что доступно в YC. Покрутили Postgres Pro как вариант, в итоге остановились на vanilla через managed-сервис.

Итоговая стоимость инфраструктуры снизилась. Не драматически, не в разы - примерно на треть при текущем курсе. Но расчёты теперь в рублях, что само по себе снимает часть операционной головной боли.

Что дальше - посмотрим. Пока инфраструктура работает стабильно, инцидентов после переезда не было. Команда клиента привыкает к консоли YC - это отдельный квест, но не катастрофа.