Почему переезд в облако удорожает инфраструктуру втрое: разбор по статьям счёта

MAATRIX

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

Почему смета на бумаге не совпадает со счётом в конце месяца

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

Дальше подключаются метрики, о которых на этапе выбора тарифа обычно не думают вообще: сколько данных уходит наружу, с какой скоростью читает и пишет диск, сколько версий бэкапов хранится одновременно, сколько публичных IP занято, работает ли перед сервисом балансировщик, используются ли managed-версии базы данных или очереди вместо своих на том же сервере. Каждая из этих статей по отдельности выглядит скромно — несколько процентов от базового тарифа. Но они не взаимоисключающие: они складываются, и сумма может составлять кратную часть от того, что изначально закладывалось в бюджет как «сервер стоит X».

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

Вычислительные ресурсы — это входной билет, а не весь счёт

Стоимость vCPU и RAM в облачном прайсе устроена так, чтобы при сравнении с конкурентами выглядеть привлекательно: это самая заметная и самая сравниваемая цифра, поэтому именно на ней держится маркетинговое позиционирование «дешевле, чем свой сервер». Но инстанс сам по себе — это вычислительная мощность без диска нужного размера и типа, без сетевого интерфейса с публичным адресом, без резервного копирования, без мониторинга сверх базового.

Каждый из этих компонентов подключается отдельной строкой в тарификации и часто — по собственной модели ценообразования, не масштабируемой линейно вместе с ценой инстанса. Диск можно выбрать медленный и дешёвый или быстрый и кратно дороже при том же объёме. Резервное копирование включается по расписанию и накапливает объём, за который платят помесячно, даже если никто не смотрит старые копии. Трафик считается отдельно от вычислений и почти всегда асимметрично: входящий обычно бесплатный, исходящий — платный, и именно он растёт вместе с числом пользователей продукта.

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

Трафик: входящий бесплатно, исходящий — по счётчику

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

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

Отдельно стоит учитывать трафик между зонами доступности и регионами внутри одного облака — если архитектура распределена (например, база в одной зоне, приложение в другой ради отказоустойчивости), этот межзонный трафик тоже почти всегда платный, и в моменте разработки архитектуры про него часто забывают, потому что технически это выглядит как «внутренняя сеть провайдера». С точки зрения биллинга это не так.

Диск: платят не только за объём, но и за скорость

Дисковая подсистема в облаке — это минимум два независимых параметра тарификации: объём хранимых данных в гигабайтах и производительность в операциях ввода-вывода в секунду (IOPS) или в мегабайтах пропускной способности. Базовый тариф диска обычно рассчитан на объём с гарантированным, но скромным уровнем производительности. Как только приложению нужна более высокая скорость чтения-записи — база данных под нагрузкой, очередь сообщений, файловое хранилище с частым доступом — приходится либо переходить на диск более дорогого класса, либо докупать выделенную производительность отдельной строкой сверх базового тарифа.

На бумаге при планировании переезда обычно считают только объём: «нужно 500 ГБ — вот тариф за 500 ГБ». Требования к IOPS в эту прикидку не попадают, потому что до реальной эксплуатации сложно точно предсказать профиль нагрузки на диск. В результате через один-два месяца выясняется, что база данных «тормозит» именно из-за упора в лимит IOPS базового тарифа, и решение — доплата за более производительный класс хранилища сверх исходной сметы.

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

IP-адреса, балансировщики и другая «инфраструктурная мелочь»

За пределами вычислений, диска и трафика в облачном счёте есть слой инфраструктурных примитивов, каждый из которых кажется незначительным по отдельности, но в сумме формирует заметную часть счёта:

• Публичные IPv4-адреса. В условиях дефицита адресного пространства многие облака берут отдельную почасовую плату за каждый выделенный публичный адрес — включая адреса, которые формально «зарезервированы», но временно не привязаны ни к одному работающему инстансу.
• Балансировщики нагрузки. Тарифицируются одновременно по времени работы (почасово или посуточно) и по объёму обработанных данных — то есть это фактически второй счётчик трафика, отдельный от счётчика самого инстанса.
• NAT-шлюзы и приватные сети. Нужны для того, чтобы серверы без публичного IP могли выходить в интернет, и тоже тарифицируются по времени работы плюс по объёму прошедшего через них трафика.
• DNS-зоны и запросы к ним. Обычно дёшево по отдельности, но при высокой частоте обращений (особенно с низким TTL) превращается в заметную регулярную сумму.
• Мониторинг и логирование сверх бесплатного лимита. Базовые метрики обычно включены, но детальный мониторинг, длительное хранение логов или повышенная частота сбора метрик почти всегда переводятся на платный тариф.

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

Managed-сервисы: наценка за то, что вы не администрируете сами

Отдельная и часто самая крупная статья удорожания — переход на managed-версии сервисов вместо самостоятельно администрируемых на своём инстансе. Managed-база данных, managed-очередь сообщений, managed control plane оркестратора контейнеров — всё это снимает с команды задачу администрирования, патчинга, настройки резервного копирования и мониторинга. За это облако берёт наценку сверх стоимости эквивалентных по мощности вычислительных ресурсов — иногда кратную, потому что в стоимость включена не только инфраструктура, но и труд инженеров провайдера, которые эту инфраструктуру обслуживают на своей стороне.

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

То же самое касается managed Kubernetes: помимо оплаты рабочих узлов (обычных вычислительных инстансов) отдельно тарифицируется control plane — управляющий слой, который в самостоятельно поднятом легковесном дистрибутиве вроде k3s на своих серверах просто не существует как отдельная платная сущность. Для команды, которой не нужны все возможности полноценного managed-оркестратора, эта наценка — чистая переплата за неиспользуемое удобство.

Как считать TCO до переезда, а не после

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

1. Зафиксировать целевую конфигурацию инстансов — CPU, RAM, класс диска и его объём — под ожидаемую нагрузку, а не под минимально достаточную.
2. Оценить IOPS/пропускную способность диска отдельно от объёма — по факту профиля нагрузки приложения (много мелких случайных операций или редкие последовательные), а не по умолчанию.
3. Спрогнозировать исходящий трафик — отдача статики, ответы API, экспорт данных — и заложить его в расчёт как отдельную переменную величину, растущую вместе с аудиторией.
4. Учесть снапшоты и бэкапы с реальной политикой ротации (сколько копий хранится и как долго), а не предполагать, что это «бесплатно, потому что автоматически».
5. Перечислить все инфраструктурные примитивы — публичные IP, балансировщики, NAT, повышенный мониторинг — и оценить их по отдельности, а не одной строкой «прочее».
6. Сравнить managed-версии с самостоятельно администрируемыми аналогами и явно решить, за что команда готова платить наценку, а что можно администрировать своими силами.
7. Добавить запас 30-50% на рост каждой переменной метрики (трафик, объём данных, число снапшотов) на горизонте 6-12 месяцев — именно рост этих метрик, а не рост тарифа инстанса, чаще всего и создаёт кратное расхождение со сметой.

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

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

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

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