Где именно облако становится дороже VPS: точка перелома в цифрах

MAATRIX

Счёт за облако в конце месяца почти никогда не совпадает с тем, что вы прикидывали при заказе — то дешевле, то ощутимо дороже, и разобраться, почему так, на глаз не получается. На самом деле у сравнения облака и VPS есть конкретная точка перелома по нагрузке, и её можно посчитать по своим же метрикам за 15–20 минут, а не гадать по чужим статьям с чужими цифрами.

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

Эластичное биллинг-ядро облака устроено просто по механике и сложно по факту оплаты. Типовая модель тарификации (у разных провайдеров есть нюансы, но принцип один):

• vCPU-часы — цена за ядро в час, умноженная на фактическое время работы инстанса и число выделенных vCPU.
• RAM-часы — то же самое для памяти, часто отдельной строкой от CPU.
• Диск — плата за выделенный объём (обычно посуточно/помесячно, вне зависимости от заполненности) плюс иногда отдельная плата за IOPS сверх базового пакета.
• Трафик — исходящий трафик почти всегда платный сверх бесплатного лимита, входящий обычно бесплатный.
• Простой инстанса — если инстанс выключен (stopped/deallocated), CPU и RAM не тарифицируются, но диск и статические IP чаще всего продолжают тарифицироваться.

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

Формально это можно записать так:

Цена_облако_за_месяц ≈ Σ (потреблённые_единицы_ресурса × цена_за_единицу_с_премией) + трафик_сверх_лимита

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

Как VPS считает деньги: фиксированная цена за фиксированный лимит

С VPS всё линейнее: вы платите фиксированную сумму в месяц за пакет из vCPU, RAM, диска и (обычно) безлимитного или порогового трафика — вне зависимости от того, простаивает сервер большую часть суток или работает на пределе.

Цена_VPS_за_месяц = фиксированная_плата (не зависит от факта использования CPU/RAM в рамках лимита)

Экономика VPS строится на усреднении по множеству клиентов: провайдер закладывает в тариф статистическое ожидание, что не все арендаторы физической машины утилизируют свой пакет ресурсов одновременно на 100%, и продаёт overcommit по CPU (реже — по RAM). Это позволяет держать цену за единицу ресурса ниже, чем в эластичной модели, — но взамен вы теряете возможность мгновенно и без переплаты выйти за пределы пакета: превышение лимита либо throttling, либо требует смены тарифа/сервера.

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

Где облако выигрывает: два конкретных сценария

Эластичность окупается ровно в двух формах нагрузки, и важно уметь их различать.

Сценарий 1 — сильно переменная или пиковая нагрузка. Если сервис большую часть времени потребляет мало ресурсов, а иногда — кратно больше (маркетинговый всплеск, батч-обработка раз в сутки, сезонный пик, вебинар на 2 часа раз в месяц), то VPS вам придётся покупать «под пик» и оплачивать простаивающий запас всё остальное время. Облако в этом случае платит только за фактически потреблённые в пике часы, а в спокойные периоды автоматически откатывается к дешёвому базовому уровню. Чем выше отношение пиковой нагрузки к средней (peak-to-average ratio) и чем реже случается пик, тем сильнее выигрыш облака.

Сценарий 2 — очень маленькая базовая нагрузка. Если сервису реально нужно 0.2 vCPU и 300 МБ RAM большую часть времени (тестовый стенд, вебхук раз в час, личный проект), у большинства облачных провайдеров есть тарификация с шагом мельче, чем минимальный VPS-пакет. Здесь выигрывает не эластичность как таковая, а просто более мелкая гранулярность прайсинга — вы платите за долю ресурса, которую физически невозможно купить отдельным VPS-тарифом дешевле минимального пакета провайдера.

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

Где VPS выигрывает: стабильная нагрузка и цена за эластичность, которой не пользуются

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

Это касается не только «постоянно нагруженных» сервисов — то же самое верно и для сервиса с низкой, но стабильно низкой нагрузкой (условно 15–20% от минимального VPS-пакета, без скачков). Раз нагрузка не скачет, вы не получаете выгоды сценария 1 (нет пиков, которые надо покрывать эластично), а выгода сценария 2 актуальна только пока абсолютный объём настолько мал, что не дотягивает даже до минимального VPS. Как только средняя нагрузка приближается к объёму минимального или следующего VPS-тарифа — премия за гибкость облака начинает перевешивать выгоду от мелкой гранулярности.

Грубое эмпирическое правило (не универсальный закон, а ориентир для первой прикидки): если коэффициент вариации нагрузки за месяц низкий (то есть отклонение от средней небольшое) и средняя утилизация приближается к 40–60% от объёма, который вам вообще нужен с запасом, — стоит в первую очередь считать VPS, а не облако. Дальше это надо проверить расчётом, а не поверить на слово — методика ниже.

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

Идея методики: снять фактическое потребление ресурсов за представительный период (минимум 2–4 недели, лучше месяц, с захватом рабочих и выходных дней), посчитать среднюю и пиковую утилизацию, а затем сравнить два числа — стоимость такого же профиля потребления в облаке и стоимость сопоставимого по объёму VPS.

Шаг 1. Снять фактическую утилизацию

Если сервер уже работает — не гадайте, а возьмите реальные метрики. Простейший вариант через sar (пакет sysstat), если он уже стоит и копит историю:

# среднее CPU за сутки (все ядра), в процентах
sar -u -f /var/log/sysstat/sa01 | awk '/Average/ {print 100-$NF"% CPU used"}'

# использование памяти
sar -r -f /var/log/sysstat/sa01 | awk '/Average/ {print $4"% RAM used"}'

Если sysstat не стоял заранее — накопите свежие данные за 2–4 недели, а не пытайтесь восстановить прошлое: apt install sysstat, включить сбор в /etc/default/sysstat (ENABLED="true"), перезапустить systemctl restart sysstat.

Более удобный вариант для не-Linux-провайдеров или готовых дашбордов — выгрузить CSV с метриками CPU/RAM из мониторинга облачной панели (почти у всех провайдеров есть экспорт за произвольный период) и посчитать среднее и 95-й перцентиль скриптом:

import csv

values = []
with open("cpu_usage.csv") as f:
    reader = csv.DictReader(f)
    for row in reader:
        values.append(float(row["cpu_percent"]))

values.sort()
avg = sum(values) / len(values)
p95 = values[int(len(values) * 0.95)]
peak = max(values)

print(f"среднее: {avg:.1f}%  p95: {p95:.1f}%  пик: {peak:.1f}%")

Значение p95 важнее пика — единичный выброс не должен определять весь расчёт, а вот «почти всегда ниже этого уровня» — определяет.

Шаг 2. Перевести проценты в абсолютные единицы

Если у вас сейчас 4 vCPU / 8 GB RAM и средняя загрузка CPU 35%, а RAM — 50%, то фактическое среднее потребление — это примерно 1.4 vCPU и 4 GB RAM. Именно эти цифры, а не номинальные 4 vCPU/8 GB, нужно подставлять в тариф облака при сравнении «среднего» сценария — то, за что вы реально платили бы по эластичному счётчику.

Шаг 3. Собрать два счёта на бумаге — иллюстративный пример

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

Условные вводные: сервису в среднем нужно 1.5 vCPU и 3 GB RAM, пиковая нагрузка (несколько раз в месяц, по 1–2 часа) — до 3 vCPU и 5 GB RAM, диск — 40 GB SSD, трафик — 300 GB исходящего в месяц.

Смысл таблицы не в конкретных X, а в структуре: в условном облаке каждая строка — это отдельная позиция счёта, которая растёт вместе с фактическим потреблением, а в VPS почти всё, кроме явного превышения пакета, — это одна фиксированная сумма. Если ваша реальная нагрузка близка к среднему профилю из примера (то есть пики редкие и небольшие по амплитуде), фиксированный пакет почти всегда обходится дешевле, потому что вы не платите премию за возможность мгновенно вырасти в 10 раз, которой пользуетесь пару часов в месяц.

Шаг 4. Найти точку перелома через отношение пика к среднему

Практическое эмпирическое наблюдение (не строгая формула, а ориентир для первой прикидки, который стоит проверить своими цифрами): чем выше отношение p95-нагрузки к средней нагрузке, тем больше смысла в облаке. Если p95 находится в пределах 1.2–1.5x от среднего (нагрузка довольно ровная) — почти всегда выгоднее фиксированный VPS-пакет, взятый под p95 с небольшим запасом. Если p95 в 3–5 раз выше среднего и такие всплески случаются нечасто — облако начинает выигрывать, потому что VPS под пик означал бы избыточный пакет, простаивающий большую часть месяца.

Практический вывод: на какой стороне перелома вы сейчас

Чтобы не считать в теории, а получить ответ для своего случая, нужно пройти четыре шага именно в таком порядке:

1. Снять фактические метрики CPU/RAM/диска/трафика за 2–4 недели (не за один день — один день не показывает форму нагрузки).
2. Посчитать среднее, p95 и максимум по каждому ресурсу отдельно — CPU и RAM редко масштабируются синхронно.
3. Перевести облачный тариф в стоимость такого же профиля потребления (средняя нагрузка + доплата за реальные пиковые часы) и сравнить с ценой VPS-пакета, рассчитанного на p95 с запасом 20–30%.
4. Пересчитать через 2–3 месяца, если профиль нагрузки меняется (рост аудитории, новый функционал, сезонность) — точка перелома не статична, и то, что было выгодно на старте, может перестать быть выгодным при росте базовой нагрузки.

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

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

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