Немного контекста: почему переезжают
До 2022 года AWS был для многих российских компаний стандартом де-факто. Хорошая документация, огромная экосистема, знакомый интерфейс. Потом все изменилось — и компании оказались перед выбором: мигрировать планово или ждать, пока за тебя решат.
Сейчас, в 2026-м, большинство тех, кто должен был переехать — уже переехал. Но остаются компании, которые все еще используют гибридные схемы или только начинают процесс. Этот материал — для них.
Я собрал опыт нескольких миграций — от небольших стартапов до компаний с несколькими сотнями виртуальных машин. Буду говорить прямо, без «все просто и легко».
Что работает одинаково — и это приятно удивляет
Начну с хорошего, потому что хорошего действительно много.
S3-совместимые хранилища — это, пожалуй, самый легкий кусок миграции. Selectel, Cloud.ru, Yandex Cloud — все реализуют совместимый с AWS S3 API. Меняете endpoint и ключи в конфигурации приложения, и boto3, rclone или ваш SDK работают без изменений в коде. На перенос данных через rclone уходит время пропорционально объему, но сам процесс прямолинейный.
Terraform — у всех крупных российских провайдеров есть официальные провайдеры. Если ваша инфраструктура описана в коде, переход выглядит как: поменять провайдер, заменить имена ресурсов на эквиваленты. Не все один-к-одному, но логика та же.
Managed Kubernetes — работает привычно. Если деплоили в EKS, в Managed K8s от Yandex Cloud или Cloud.ru вы почувствуете себя комфортно. Те же манифесты, та же логика. Провайдеры умеют интегрировать кластер со своими балансировщиками и хранилищами — это займет время на настройку, но не потребует переписывать приложения.
Managed базы данных — PostgreSQL, MySQL, Redis в managed-исполнении работают как и везде. Данные переносятся через pg_dump/pg_restore или через сервисы Data Transfer, которые есть у Cloud.ru и Yandex Cloud.
Что потребует переработки
Вот здесь нужно быть честными.
IAM — придется переучиться
AWS IAM — это очень зрелый, многолетний продукт с гибкой системой политик. IAM российских провайдеров проще и местами ограниченнее. Если у вас сложные политики с условиями и тонким разграничением доступа — придется потратить время на переработку. Не катастрофа, но день-два минимум на разбор и переписывание.
Особенно это касается сервисных аккаунтов и прав для CI/CD. В AWS привыкли к Instance Profile — роли, которая назначается EC2-инстансу и дает ему права без явных ключей. Аналог есть у всех провайдеров, но реализован по-разному.
Lambda → Serverless Functions
Если вы активно используете AWS Lambda — это, пожалуй, самый трудоемкий кусок. Serverless-функции есть у Yandex Cloud (Cloud Functions), у Cloud.ru тоже есть аналог. Базовая логика та же: триггер → функция → ответ. Но специфика платформ разная, а некоторые интеграции придется переписать.
Особенно больно, если Lambda у вас завязана на API Gateway с кастомными авторайзерами. Это нужно разбирать руками. Планируйте на это несколько недель, не дней.
CloudWatch и алертинг
Если мониторинг завязан на CloudWatch с Alarm-ами, дашбордами и Log Insights — готовьтесь к переносу. Российские провайдеры имеют собственные системы мониторинга, но экспортировать конфигурации CloudWatch напрямую нельзя. Многие команды в этот момент принимают решение перейти на Grafana + Prometheus — и это, честно говоря, неплохой выбор, потому что это стандарт, который работает везде.
Что неприятно удивляет
Это раздел, который в рекламных материалах не пишут.
Документация. AWS имеет двадцатилетнюю документацию, тысячи StackOverflow-ответов, курсы на любой платформе. Российские провайдеры активно развивают документацию, но ее глубина пока другая. Особенно ощущается в нестандартных сценариях: когда что-то работает не так, и вы идете гуглить — ответа на русском может не быть. Придется читать код и экспериментировать.
Зоны доступности. У AWS три AZ в регионе — это стандарт. У российских провайдеров ситуация разная: у кого-то 2–3 зоны, у кого-то меньше. Для архитектур с жесткими требованиями к отказоустойчивости это важно проверить до начала работы.
Поддержка. Enterprise-поддержка у российских провайдеров есть, но ее качество и скорость — это лотерея, которая зависит от конкретного провайдера и вашего тарифного плана. Бесплатный тир поддержки на практике означает «напишите в тикет и ждите». Если поддержка критична — закладывайте коммерческий план.
Практический план миграции
Вот последовательность, которая работала в реальных проектах.
Шаг 1: инвентаризация. Прежде чем что-то трогать — сделайте список всего, что работает в AWS. Не только виртуальные машины, но и Lambda, SQS, SNS, ElastiCache, RDS, S3-бакеты, Security Groups, IAM-роли. Многие обнаруживают ресурсы, о существовании которых забыли.
Шаг 2: классификация по сложности. Разделите сервисы на три группы. Простые (S3, VM, managed БД) — переедут быстро. Средние (K8s, мониторинг, CI/CD) — потребуют дней. Сложные (Lambda с интеграциями, специфичные сервисы) — планируйте недели.
Шаг 3: начните с некритичных. Первым переезжает staging или внутренний инструмент. Вы находите грабли в безопасной среде, а не на продакшне в пятницу вечером.
Шаг 4: параллельная работа. Перед переключением трафика новая инфраструктура должна пробработать хотя бы неделю в реальных условиях (с зеркалированием части трафика или тестовой нагрузкой). Не переключайте в слепую.
Шаг 5: держите AWS еще месяц. Не спешите все удалять. Счет за простаивающую инфраструктуру болезненный, но обнаружить через три недели, что что-то завязано на AWS-ресурс, который уже удален — еще болезненнее.
Что в итоге
Миграция с AWS на российское облако — это реальная работа, которая требует нескольких месяцев для серьезной инфраструктуры. Но это выполнимо, и результат дает спокойствие: данные в российской юрисдикции, нет зависимости от иностранного сервиса, часто выгоднее по деньгам.
Лучшее, что можно сделать до начала — потратить день на разговор с командой конкретного провайдера. Все крупные (Cloud.ru, Yandex Cloud, Selectel) имеют архитекторов по миграции, которые делают это бесплатно в рамках пресейла. Они видели сотни миграций и подскажут, где у вашей конкретной архитектуры будут грабли.