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

MAATRIX

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

Что на самом деле происходит при выключении сервера

«Выключить» виртуальный сервер и «остановить процессор» — не одно и то же. Когда вы нажимаете Stop в панели управления или выполняете shutdown -h now изнутри системы, происходит следующее:

• Гипервизор прекращает выделять серверу такты CPU и оперативную память — вычислительный процесс действительно останавливается, конкретная физическая машина больше не тратит на ваш инстанс циклы планировщика.
• Виртуальный диск (block storage / volume), на котором лежит ваша операционная система и данные, никуда не девается. Это отдельная сущность в системе хранения провайдера — обычно на распределённом хранилище (Ceph, аналогичные системы), а не «внутри» гипервизора, который считал CPU.
• Сетевые настройки, привязка к IP-адресу, конфигурация сервера (vCPU/RAM профиль, к которому вы сможете вернуться одной кнопкой) — тоже сохраняются как метаданные.

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

Важно понимать разницу между несколькими состояниями сервера, потому что в биллинге они ведут себя по-разному:

• Running (запущен) — тарифицируется всё: CPU/RAM, диск, IP, иногда сетевой трафик.
• Stopped (остановлен, но не удалён) — CPU и RAM не тарифицируются (или тарифицируются по сильно сниженной ставке), но диск и, часто, IP — да.
• Terminated/Deleted (удалён) — тарификация прекращается полностью, но вместе с сервером обычно исчезает и диск, если вы заранее не сняли снапшот или не отсоединили volume.

За что именно продолжает капать плата

Разберём по отдельности статьи расходов, которые остаются активными у выключенного сервера.

Дисковое пространство

Виртуальный диск — это выделенный физический ресурс на хранилище провайдера, даже если сама операционная система не запущена и ничего с диска не читает и не пишет. Провайдер зарезервировал под вас конкретный объём (например, 50 ГБ SSD), эти блоки физически недоступны для других клиентов, и хранение тарифицируется отдельно от вычислительного времени — обычно по формуле «цена за ГБ в месяц», которая не зависит от состояния Running/Stopped. Это логично: место на дисках — конечный физический ресурс, который провайдер закупает и обслуживает вне зависимости от того, крутится ли ваша ОС.

Зарезервированный IP-адрес

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

Резерв под слот в вычислительном пуле

Это менее очевидная статья, но она встречается у части провайдеров, особенно там, где выключенная машина не мигрирует свободно между физическими хостами. Чтобы гарантировать вам мгновенный запуск именно с тем же профилем vCPU/RAM, который вы выбрали, система размещения (scheduler) может резервировать под остановленный инстанс слот в конкретном пуле мощностей — грубо говоря, обещание, что при включении ресурсы точно найдутся. За это обещание тоже иногда берут отдельную, обычно небольшую плату — либо явно, либо скрыто внутри платы за диск и конфигурацию.

Снапшоты и резервные копии, которые продолжают тикать

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

Почему это устроено именно так

С точки зрения провайдера логика полностью рациональна, и полезно понимать её, чтобы не считать это «разводом».

Облачный провайдер продаёт не абстрактную «мощность вообще», а конкретные физические ресурсы: место на дисковых массивах, адреса из ограниченного пула, слоты в кластере виртуализации. Когда вы останавливаете сервер, вы освобождаете только один из этих ресурсов — вычислительное время CPU и оперативную память, потому что именно их гипервизор может немедленно перераспределить другому клиенту (или использовать для оверкоммита). А диск, IP и конфигурация продолжают быть закреплены конкретно за вами, потому что именно в этом и состоит обещание сервиса: «нажмёте Start — и через несколько секунд получите тот же сервер с теми же данными и тем же адресом».

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

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

Stopped, Terminated и снапшот — что списывается в каждом случае

Наглядно свести три сценария в одну таблицу.

Здесь и кроется практическая развилка: если вам действительно важна возможность вернуться к серверу «как есть» за 10 секунд — держите его Stopped и платите за это удобство. Если такой срочности нет, а горизонт простоя измеряется неделями или месяцами — экономически разумнее перейти на нижнюю строку таблицы: удалить сервер, сохранив данные отдельным снапшотом или бэкапом.

Когда выгоднее удалить сервер, а не держать выключенным

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

Ориентировочно (без привязки к конкретным цифрам, которые различаются у каждого провайдера и тарифа) экономика выглядит так:

• Выключенный сервер с диском и закреплённым IP продолжает стоить заметную долю от полной цены — часто это диск (самая тяжёлая по объёму статья) плюс IP, то есть далеко не «почти бесплатно», как многие ожидают.
• Снапшот того же диска обычно стоит дешевле полноценного volume того же объёма — экономия тем заметнее, чем компактнее реальные данные внутри диска (пустые блоки в снапшот, как правило, не попадают).
• Освобождённый IP снимает свою статью расходов полностью, а при повторном разворачивании вы либо получаете новый адрес, либо (если это критично, например ради DNS и белых списков firewall) можете заранее продумать, что адрес сменится — подробнее о безопасной смене IP в статье про смену IP-адреса без потери клиентов.

Практическое правило: если горизонт простоя сервера — часы или дни (тестовый стенд, который вот-вот снова понадобится), Stopped оправдан ради мгновенного возврата. Если горизонт — недели и тем более месяцы (проект заморожен, сезонная нагрузка закончилась, клиент взял паузу), почти всегда выгоднее удалить сервер, сохранив данные снапшотом, и развернуть новый инстанс из этого снапшота, когда он снова понадобится. Разворачивание из снапшота занимает минуты, а не секунды, — это единственная цена, которую вы платите за экономию на месяцах простоя.

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

Как правильно удалить сервер, не потеряв данные

Если вы решили, что простой затянется надолго, порядок действий такой:

1. Снимите снапшот диска или полный бэкап — через штатный механизм панели управления или изнутри ОС. Для минимального риска — оба варианта сразу:

# Пример: холодный снапшот диска через провайдерский CLI (псевдо-команда, синтаксис зависит от провайдера)
provider-cli snapshot create --volume-id vol-xxxxxxxx --name "pre-delete-$(date +%F)"

# Дублирующий бэкап важных данных наружу — не полагайтесь на один снапшот у одного провайдера
tar czf - /var/lib/app-data | ssh backup-host "cat > /backups/app-data-$(date +%F).tar.gz"

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

dpkg --get-selections > server-packages.txt   # для Debian/Ubuntu
cp -r /etc/nginx /etc/systemd/system/*.service /backups/configs/
crontab -l > /backups/configs/crontab.txt

1. Зафиксируйте сетевые параметры, которые придётся воссоздавать: используемый IP (если он не сохраняется), правила firewall, записи DNS, которые указывали на этот сервер. Если IP освобождается — заранее снизьте TTL у DNS-записей на этот адрес, чтобы при развороте на новом IP переключение прошло быстро.

1. Удалите сервер и, если провайдер тарифицирует IP отдельно от инстанса, явно освободите адрес — в части панелей отвязка IP и удаление сервера не происходят автоматически одним действием, это два разных шага.

1. Проверьте, что снапшот действительно хранится независимо от удалённого сервера — в редких случаях снапшот, привязанный к volume, удаляется каскадно вместе с volume, если явно не выбрана опция «оставить снапшот». Это стоит проверить сразу после удаления, а не через полгода, когда сервер снова понадобится.

Чек-лист перед долгим простоем сервера

Прежде чем решать между Stopped и Terminated, пройдитесь по короткому списку:

• Сколько реально продлится простой — дни или месяцы? Если счёт идёт на месяцы, экономика почти всегда в пользу удаления со снапшотом.
• Критична ли неизменность IP-адреса для внешних интеграций, белых списков или DNS с высоким TTL? Если да — оцените отдельно, стоит ли резервирование IP своих денег, или проще заранее спланировать смену адреса.
• Есть ли у диска данные, которые не попадают в стандартный снапшот (например, управляемой базе данных, которая тарифицируется и бэкапится отдельно)? Их нужно сохранить отдельным экспортом.
• Настроены ли автоматические снапшоты по расписанию, которые продолжат тикать после остановки сервера? Если политика больше не нужна — отключите её отдельно, остановка сервера её не выключает.
• Задокументирована ли конфигурация настолько, чтобы развернуть сервер заново без «археологии» по старым записям в блокноте?
• Сравнили ли вы фактическую стоимость Stopped (диск + IP помесячно) со стоимостью снапшота того же объёма? Часто разница более заметна, чем кажется на глаз.

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

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