Сколько стоит вытащить свои данные из облака: считаем цену выхода

MAATRIX

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

Почему исходящий трафик — это не мелочь, а барьер

У подавляющего большинства облачных провайдеров загрузка данных внутрь (ingress) бесплатна или почти бесплатна, а вот выгрузка наружу (egress) — платная, и часто ощутимо. Это не случайность и не техническая необходимость — это экономическая модель. Провайдеру выгодно, чтобы данные заходили к нему легко и без трения, а вот покидали с трудом: каждый гигабайт, который вы выгружаете при миграции, превращается в отдельную строку счёта, причём именно в тот момент, когда вы уже приняли решение уходить и меньше всего готовы спорить о цене.

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

Как работает vendor lock-in через плату за выход

Классический vendor lock-in — это когда сменить поставщика формально можно, но экономически невыгодно. Плата за egress создаёт ровно такой барьер, и работает он тем сильнее, чем дольше вы остаётесь с одним провайдером:

• Данные накапливаются быстрее, чем вы планируете съехать. Бэкапы, снапшоты, архивы логов, медиаконтент — объём растёт почти всегда монотонно, и «цена выхода» растёт вместе с ним, даже если вы ничего специально не делаете.
• Решение об уходе принимается после того, как данные уже накоплены. Вы не выбираете объём данных под миграцию — вы выбираете миграцию, уже имея объём данных. Это меняет расклад: сравнение «остаться или уйти» теперь включает разовый платёж, которого не было бы, если бы вы ушли раньше.
• Барьер асимметричен во времени. Стоимость подписки вы платите равномерно и видите каждый месяц. Стоимость выхода — это одноразовый скачок, который легко недооценить, потому что его не с чем сравнить в моменте.

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

Методика: как прикинуть свою цену выхода

Точную цифру вы получите только по факту переноса, но прикидочную оценку можно сделать за десять минут — этого достаточно, чтобы понять порядок величины и решить, стоит ли откладывать переезд дальше. Базовая формула:

Цена_выхода ≈ V_данных × P_egress − Free_tier_egress + Доп_расходы

где:
V_данных        — суммарный объём данных, который нужно выгрузить (ГБ)
P_egress        — цена вашего провайдера за 1 ГБ исходящего трафика
                  (смотрите в прайс-листе / калькуляторе провайдера,
                  часто цена ступенчатая и падает с объёмом)
Free_tier_egress — бесплатный лимит исходящего трафика в месяц,
                  если он есть у вашего тарифа
Доп_расходы     — плата за API-запросы на чтение/листинг объектов,
                  если провайдер тарифицирует и их отдельно

Порядок действий:

1. Посчитайте V_данных. Сложите объём всего, что реально нужно перенести: продакшн-базы, файловое хранилище, бэкапы и снапшоты, которые вы собираетесь сохранить, медиатеку, архивы логов, если они вам нужны. Проще всего смотреть по биллинговой панели провайдера — там обычно есть отчёт по занятому объёму хранилища за последний период.
2. Найдите P_egress в своём тарифе. Это единственная переменная, которую нельзя усреднить «по рынку» — у разных провайдеров и даже у разных типов трафика (внутри региона, между регионами, наружу в интернет, через CDN) цена может отличаться в разы. Берите цифру именно из своего прайс-листа или калькулятора, а не из общих ощущений.
3. Вычтите бесплатный лимит, если он есть — у некоторых тарифов бесплатны первые N гигабайт исходящего трафика в месяц. Если объём данных большой, а лимит маленький, вычитание почти ничего не изменит, но для небольших проектов это может обнулить весь расчёт.
4. Добавьте побочные расходы, если провайдер тарифицирует не только сам трафик, но и операции чтения/листинга — при большом количестве мелких файлов это может дать заметную добавку сверх стоимости самого трафика.
5. Прикиньте окно переноса. Если у тарифа есть бесплатный лимит в месяц, можно растянуть выгрузку на несколько месяцев и уложиться в лимит — но тогда к цене выхода добавляется ещё N месяцев параллельной оплаты старого и нового окружения.

Это прикидка, а не точный расчёт — реальная цена может отличаться из-за ступенчатых тарифов, скидок за объём или особенностей конкретного API. Но даже грубая оценка обычно даёт достаточно ясности: если она сопоставима с несколькими месяцами подписки — это разумная плата за независимость. Если сопоставима с годовой подпиской — вопрос стоит того, чтобы отложить и подумать заранее, а не постфактум.

Пример расчёта: от блога до продакшн-базы

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

Смысл таблицы не в конкретных X, а в том, что цена выхода растёт линейно с объёмом данных, а не с длительностью использования сервиса. Проект, который годами копил логи и снапшоты «на всякий случай», платит за выход не за годы использования, а за гигабайты, которые физически лежат в хранилище на момент переноса. Это прямое следствие того, о чём мы писали в разборе снапшотов, которые копятся годами — то, что не удаляется вовремя, увеличивает не только текущий счёт, но и будущую цену выхода.

Что ещё входит в цену выхода, кроме трафика

Плата за egress — самая очевидная, но не единственная статья расходов на выход из облака. Прикидочная методика выше даёт нижнюю границу, к которой стоит добавить:

• Двойная оплата инфраструктуры на время переноса. Пока данные копируются, старое окружение должно продолжать работать — иначе сервис встанет. Это означает, что вы платите за старую и новую инфраструктуру параллельно, минимум на время самого переноса, а часто и дольше — на верификацию.
• Время инженера на перенос и проверку. Перенос терабайтов данных — это не запуск одной команды: нужна валидация целостности, тестовый прогон на новом окружении, план отката на случай проблем. Это время стоит денег, даже если вы не платите за трафик отдельно.
• Риск простоя при переключении. Смена DNS, финальная синхронизация данных, переключение трафика — на этом этапе легко потерять часть данных или получить простой, если не подготовиться заранее. Мы разбирали похожие грабли в статье про реальную стоимость переезда за вечер — то, что выглядит быстрой операцией, на практике часто занимает не один заход.
• Скорость самого переноса. Исходящая пропускная способность у облачных провайдеров нередко ограничена или зависит от тарифа — перенос 20 ТБ может физически занять несколько дней, и это время нужно закладывать в план, а не в последний момент.

Если считать честно, «цена выхода» — это не только счёт за трафик, а сумма разового платежа за egress и организационных издержек самого переезда. Формула из предыдущего раздела даёт вам финансовую часть; план самого переноса стоит делать отдельно — общий подход к этому мы описывали в материале про то, как составить план миграции на новый сервер.

Как выбирать провайдера с оглядкой на цену выхода

Главный практический вывод из всего разбора выше: цену выхода нужно оценивать до того, как вы завели в облако первый терабайт данных, а не после того, как решили уходить. Несколько пунктов, которые стоит проверить на этапе выбора или пересмотра провайдера:

• Посмотрите тариф на egress ещё до подписания договора. Это единственная цифра, которая определяет, насколько дорого будет уйти. Если раздел с ценой исходящего трафика в прайс-листе сложно найти или он написан невнятно — это само по себе тревожный знак.
• Проверьте, есть ли бесплатный лимит и насколько он реален для вашего объёма данных. Лимит в 1–10 ГБ бесполезен, если вы храните терабайты.
• Выбирайте форматы и API, совместимые с другими провайдерами, где это возможно — это снижает не финансовую, а техническую часть барьера: если данные лежат в стандартном формате и доступны через привычный протокол, перенос упрощается сам по себе, независимо от платы за трафик.
• Не давайте объёму данных расти бесконтрольно. Регулярно чистите старые снапшоты, логи и бэкапы, которые реально никому не нужны — это снижает не только текущий счёт за хранение, но и будущую цену выхода, если вы решите уйти.
• Сделайте «тренировку выхода» на небольшом объёме заранее. Выгрузите тестовый набор данных и посчитайте, во что реально обошлась операция — это куда надёжнее прикидки по прайс-листу и покажет подводные камни (лимиты скорости, платные API-запросы) до того, как они станут проблемой при полном переносе.
• Сравнивайте не только ежемесячную подписку, но и совокупную стоимость владения. Дешёвый на бумаге тариф с высокой платой за выход может оказаться дороже в перспективе трёх лет — подробнее об этом в разборе TCO выделенного сервера против облака и в материале о том, как считать ROI переезда на свой сервер.

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

Частые вопросы