Репатриация из облака: с AWS или Azure в Ригу

Репатриация из облака означает перенос части нагрузок из публичного облака, например AWS или Azure, на арендованные или свои серверы ради предсказуемого счёта. Почти никогда это не полный уход из облака: переезжают ровные нагрузки вроде баз данных, ERP и файловых серверов, а пиковые, глобальные и построенные на управляемых сервисах остаются. Ниже разбираем, когда переезд окупается, как посчитать его вместе с платой за исходящий трафик, как провести его по шагам и где здесь наш дата-центр в Риге. Все цены проверены 27 сентября 2026 года и указаны без НДС.

Что такое репатриация из облака и чем она не является

Так называют любой перенос нагрузки из крупного публичного облака в инфраструктуру с фиксированной ценой: арендованные выделенные серверы, ваши собственные серверы на размещении в дата-центре или виртуальные серверы регионального провайдера. Обычно получается гибрид: база данных и внутренние системы работают на серверах с фиксированной ценой, а сеть доставки контента, почта или несколько управляемых сервисов остаются в облаке. Поэтому полезный вопрос звучит не «нужно ли облако вообще», а «какие нагрузки платят облачную цену за гибкость, которой никогда не пользуются».

Почему компании выносят нагрузки из публичного облака

• Предсказуемые расходы в месяц. Счёт за облако складывается из множества измеряемых строк: часы вычислений, диски, снимки, IP-адреса, балансировщики нагрузки, запросы и трафик. Для меняющейся нагрузки это честно, но сервер, который весь месяц работает ровно, проще планировать в бюджете по фиксированной цене. Резервирование и Savings Plans снижают облачную цену, но привязывают вас на один или три года и отнимают ту самую гибкость, ради которой вы шли в облако.
• Плата за исходящий трафик. Входящие данные в AWS и Azure бесплатны, а за данные, уходящие в интернет, после небольшого бесплатного объёма платят за каждый гигабайт. Сервис, который много отдаёт пользователям или копирует резервные копии на другую площадку, платит за каждый гигабайт, а у сервера с фиксированной ценой трафик обычно включён в пределах месячного лимита.
• Данные в ЕС. У AWS и Azure есть регионы в ЕС, и данные там остаются в ЕС. Тем не менее часть компаний предпочитает, а иногда этого требуют их клиенты, поставщика, который сам является компанией из ЕС и заключает договор по праву ЕС. Чем место хранения данных отличается от права, которому подчиняется поставщик, объясняем в статье об облаках ЕС и США и о том, где лежат данные.
• Производительность ровных нагрузок. Базе данных или ERP, которые работают весь день, нужны выделенные ядра, локальные диски и предсказуемые задержки. Облако это тоже даёт, но именно крупные инстансы и премиальные диски, которые обеспечивают такую производительность, раздувают счёт. На выделенном сервере вся машина в вашем распоряжении за фиксированную цену.

Когда лучше остаться в публичном облаке

Репатриация не приговор облаку. Оставьте нагрузку на месте, если:

• нагрузка пиковая или сезонная, и на своих серверах вы бы весь год платили за пик, который длится несколько дней;
• пользователи на нескольких континентах, и сервису нужны регионы или edge-точки рядом с каждым из них;
• приложение построено на управляемых сервисах, например serverless-функциях, управляемых базах данных, очередях или AI API, и их пересборка обойдётся в большее время инженеров, чем сэкономит переезд;
• проект короткий или экспериментальный, и его размер пока никто не знает;
• ещё действуют резервирование или Savings Plans, потому что за них платят независимо от того, переехала нагрузка или нет;
• ваша команда каждый день работает в этом облаке, и серверами заниматься некому.

Как посчитать стоимость репатриации

Сравнивайте полные расходы в месяц, а не цены виртуальных машин. Со стороны облака возьмите последние три-шесть счетов и разнесите каждую строку по нагрузкам: вычисления, диски и снимки, резервное копирование, IP-адреса, управляемые сервисы, план поддержки и передача данных. Со стороны фиксированной цены сложите аренду сервера или плату за размещение вместе с электричеством, резервные копии с копией вне здания, лицензии, второй интернет-канал, если офис теперь зависит от дата-центра, и часы администрирования. В нашем сравнении затрат за пять лет на офис, размещение, выделенные серверы и облако такой расчёт разобран со всеми допущениями.

Исходящий трафик: строка, которую легко упустить

Прайсовые цены на исходящий трафик в интернет на 27 сентября 2026 года:

На первой ступени каждый терабайт, ушедший наружу, стоит около 90 USD: 1024 GB по 0.09 USD в AWS дают 92.16 USD, по 0.087 USD в Azure 89.09 USD. Учитывайте исходящий трафик дважды: как ежемесячный расход работающего сервиса, который исчезает для переехавших нагрузок, и как разовый расход на выгрузку данных.

Бесплатный выход из облака и Data Act ЕС

Оба поставщика по запросу не берут плату за разовую выгрузку данных при уходе. AWS не взимает плату за исходящий трафик в интернет при переезде из AWS: сначала вы обращаетесь в AWS Support, запрос рассматривают на уровне аккаунта, и после одобрения у вас есть 90 дней, чтобы завершить переезд; закрывать аккаунт не требуется. Azure компенсирует плату за исходящий трафик клиентам, которые уходят из Azure: вы открываете запрос в поддержку с плановой датой начала и ожидаемым объёмом, и затем у вас 60 дней на передачу данных или больше, если в запросе описан график. Перед запросом компенсации нужно отменить все подписки Azure в аккаунте, поэтому для большинства клиентов частичный переезд под это условие не подходит.

Data Act ЕС, который применяется с 12 сентября 2025 года, задаёт юридический минимум. До 12 января 2027 года поставщики могут брать за смену поставщика и выгрузку данных только затраты, связанные с этой сменой, а с 12 января 2027 года плата за смену поставщика, включая плату за исходящий трафик, отменяется полностью. Ни программы бесплатного выхода, ни Data Act не касаются повседневного трафика сервисов, которые остаются в облаке, поэтому в гибридной схеме ежемесячная плата за исходящий трафик остаётся в вашем сравнении.

Перенос в дата-центр по шагам

1. Инвентаризация. Составьте список всех виртуальных машин, баз данных, бакетов хранилища, DNS-зон, сертификатов, заданий по расписанию и внешних интеграций, указав для каждой позиции объём, стоимость в месяц и ответственного.
2. Зависимости. Нарисуйте, что с чем связано: какое приложение читает какую базу, какой сервис опирается на облачную очередь, сервис идентификации или объектное хранилище, и какие ваши IP-адреса партнёры разрешили в своих файрволах. Тому, что остаётся в облаке, нужен защищённый путь к тому, что переезжает, обычно site-to-site VPN.
3. Цель для каждой нагрузки. Ровные серверы переезжают на выделенные серверы или на размещение в дата-центре, небольшие сервисы на VPS. Каждый управляемый сервис либо пересобирают, например управляемая база данных становится сервером БД с репликацией и резервными копиями, либо сознательно оставляют в облаке.
4. Сборка и репетиция. Подготовьте серверы, сеть, файрвол, резервное копирование и мониторинг, восстановите копию данных и проверьте приложение, пока облачная версия продолжает обслуживать пользователей.
5. Передача данных. Сначала скопируйте основной объём, затем поддерживайте его в синхронном состоянии репликацией базы данных или повторными инкрементными копиями файлов, чтобы финальная разница была небольшой. Время оценивайте честно: на стабильных 500 Mbit/s один терабайт в лучшем случае идёт около четырёх с половиной часов, а пропускная способность на стороне облака может быть ниже скорости вашего порта.
6. Переключение DNS. За день-два снизьте TTL записей, которые будут меняться, например до 300 секунд, чтобы переключение дошло до пользователей за минуты. Проверьте записи SPF, списки разрешённых адресов у партнёров и сертификаты, в которых указаны старые адреса.
7. Переключение. В согласованное окно остановите запись на старой стороне, синхронизируйте последние изменения, переключите DNS или строки подключения и выполните заранее записанные проверки.
8. Параллельная работа. Оставьте облачную среду нетронутой, но без нагрузки, пока на новом месте хотя бы раз не отработают задания конца месяца, отчёты и резервное копирование.
9. Откат. До начала окна решите, какая проваленная проверка возвращает вас назад и как вернутся данные, записанные на новой стороне. Откат входит в план и не считается провалом.
10. Вывод из эксплуатации. Только после этого удаляйте облачные ресурсы, снимки и неподключённые диски, запрашивайте компенсацию за исходящий трафик, если она положена, и проверьте два следующих облачных счёта на забытые позиции.

Где здесь CloudHosting

CloudHosting SIA сам держит свой дата-центр на Bērzaunes iela 1 в Риге. Он независим от операторов связи и построен по принципам Tier 3+: питание и охлаждение N+1, ИБП и дизель-генератор, собственная сеть AS58269 с двумя аплинками. Дата-центр охраняется, посетителей внутрь не пускаем, доступ есть только у ограниченного числа наших специалистов. Если вы привозите свои серверы, вы передаёте их в нашем офисе, а устанавливают их наши инженеры.

Мониторинг и реагирование на инциденты работают 24/7, инженеры отвечают в рабочие дни 9:00-17:00 по рижскому времени. Доступность 99.9% для нас цель, а не SLA, записанный в договоре. Договор заключается с CloudHosting SIA по латвийскому праву, счета выставляются в EUR, подписывается соглашение об обработке данных. Каждая строка счёта за размещение разобрана в статье о ценах на размещение серверов в Риге в 2026 году.

Наша услуга переноса инфраструктуры включает обследование, письменный план с откатом на каждом шаге, репетицию, переключение в согласованное окно и мониторинг после него. Для обычной корпоративной среды обследование входит в подготовку предложения, а работы по переносу оцениваем до их начала. Мы подходим не для всего: если нагрузка пиковая, глобальная или построена на управляемых сервисах, мы так и скажем и посоветуем оставить её на месте. Чтобы начать, пришлите нам список нагрузок и какой-нибудь недавний счёт за облако.