Три мелочи в облачном счёте, которые дают треть суммы

MAATRIX

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

Почему мелкие статьи счёта остаются незамеченными

Крупные статьи счёта — вычислительные ресурсы, диск, лицензии на managed-сервисы — обычно занимают одну-две строки и хорошо видны в любой детализации. Мелкие статьи устроены иначе: они размазаны по десяткам позиций, каждая на копейки, и в стандартном отчёте провайдера сворачиваются в общую категорию вроде «Network» или «Other services». Чтобы увидеть конкретную причину, нужно провалиться на два-три уровня вглубь детализации — а этого никто не делает, пока сумма не начинает пугать.

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

Третья причина чисто психологическая: мелкую статью не с чем сравнивать. Счёт за вычислительные ресурсы можно сопоставить с ценами конкурентов. А сколько «нормально» платить за десяток статических IP или за хранение логов за 90 дней — обычно неизвестно, и просто платят, что насчитали.

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

Мелочь №1: плата за каждый выделенный IP-адрес

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

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

• Сервер пересоздали или мигрировали на новый инстанс, а старый адрес отвязали и забыли освободить — он остался «в резерве» на аккаунте.
• Под тестовое окружение выделили отдельный адрес, тест закончился месяц назад, окружение снесли, а IP остался.
• Настроили балансировщик с несколькими адресами про запас «на будущий рост», но выросли не так, как планировали.

Отдельная разновидность той же проблемы — адреса, привязанные к серверу, который давно выключен или простаивает.

Как минимизировать. Раз в месяц — это буквально пять минут — стоит выгружать полный список выделенных адресов на аккаунте и сверять его со списком реально работающих серверов и сервисов. Практически у всех провайдеров это можно сделать через API или CLI одной командой:

# Псевдокод, у каждого провайдера свой синтаксис API,
# но логика запроса всегда одна и та же
curl -s -H "Authorization: Bearer $TOKEN" \
  "https://api.<provider>/v1/addresses?status=reserved" \
  | jq '.[] | {ip: .address, attached_to: .instance_id, since: .created_at}'

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

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

Мелочь №2: трафик между зонами доступности внутри одного облака

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

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

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

Как минимизировать. Первый шаг — узнать объём: у большинства провайдеров межзональный трафик выделен отдельной строкой в детализации (иногда «regional data transfer» или «cross-AZ transfer»), но по умолчанию свёрнут в общую сетевую статью. Дальше — по каждому источнику трафика спросить: это обязательная синхронная операция (тогда плата — разумная цена за надёжность) или фоновая репликация «на всякий случай», которую можно делать реже или ограничить. Не весь межзональный трафик — издержка, которую нужно убрать: часть его — прямая цена за отказоустойчивость, и её лучше платить осознанно, чем случайно.

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

Мелочь №3: мониторинг и логи сверх бесплатного лимита

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

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

Частые причины, из-за которых эта статья разрастается:

• Уровень логирования debug оставили в проде. Включили для отладки конкретного инцидента, инцидент закрыли, уровень забыли вернуть на info. Объём логов при этом может вырасти в разы — точная пропорция у каждого приложения своя, это ориентир, а не измеренное значение.
• Кастомные метрики множатся с высокой кардинальностью. Метрика с меткой (label) вида user_id или request_id создаёт отдельный временной ряд на каждое уникальное значение метки — вместо одной метрики получаются десятки тысяч, а тарифицируют большинство сервисов мониторинга именно по числу уникальных рядов.
• Срок хранения выставлен «с запасом» и никогда не пересматривался. 90–180 дней имеет смысл для аудита безопасности, но для оперативной отладки обычно достаточно 14–30 дней — остальное можно архивировать в холодное хранилище, которое стоит на порядок дешевле.
• Дашборды и алерты дублируются между командами, которые настраивают похожие метрики независимо, не зная о существующих.

Как минимизировать. Практический план на вечер: проверить конфиги на оставшийся debug/trace; отсортировать кастомные метрики по кардинальности и найти лидеров роста (почти всегда это метки вроде user_id или request_id, которые лучше логировать, а не превращать в метку); свести срок хранения к реальной потребности команды; объединить дублирующиеся дашборды и алерты.

Пример конфига ретенции для типового self-hosted стека логирования, где срок хранения задан явно, а не «по умолчанию навсегда»:

# Пример для стека логирования на своём сервере
retention:
  hot_storage_days: 14     # быстрый доступ, для активной отладки
  cold_storage_days: 90    # архив, дешевле на порядок, доступ медленнее
  debug_level_enabled: false
  debug_level_ttl_hours: 24  # если включили debug — автоматически выключить через сутки

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

Как найти эти статьи в своём текущем счёте

Все три статьи объединяет одно: они не видны в сводной сумме и требуют явного провала в детализацию. Порядок действий одинаковый для всех трёх:

1. Выгрузить детализацию счёта за последний полный месяц, а не смотреть общую сумму на дашборде — у большинства провайдеров это отдельный раздел биллинга с разбивкой по категориям и, если повезёт, по тегам ресурсов.
2. Сгруппировать по категории, а не по серверу. Сумма за конкретный сервер обычно доминируется вычислительными ресурсами, и на её фоне статические IP или межзональный трафик того же сервера теряются. Группировка по категории («Network», «IP addresses», «Logging») сразу показывает долю каждой мелкой статьи.
3. Сравнить месяц к месяцу, а не абсолютную величину. Важно не сколько стоят IP-адреса сейчас, а выросла ли эта сумма за последние три месяца без роста числа серверов — если да, это почти всегда забытый ресурс, а не оправданный рост.
4. Отметить теги ресурсов, если провайдер это поддерживает: тег project или owner на каждом IP-адресе и источнике логов сильно ускоряет разбор, когда возникает вопрос «а зачем нам вообще это».

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

Что реально можно сделать за один вечер

Если совсем нет времени на глубокий аудит, вот минимальный набор действий, каждое из которых занимает 10–20 минут и не требует согласований с командой:

• Выгрузить список зарезервированных IP-адресов без привязанного инстанса и составить список кандидатов на освобождение.
• Проверить, включена ли синхронная межзональная репликация там, где хватило бы репликации внутри одной зоны плюс регулярных бэкапов.
• Найти в конфигах прод-окружения уровень логирования debug или trace, оставшийся после последнего инцидента, и вернуть его на info.
• Посмотреть топ-10 кастомных метрик по кардинальности и решить, действительно ли каждая из них нужна как метрика, а не как обычный лог.
• Сверить срок хранения логов с реальной потребностью команды — часто достаточно 14–30 дней горячего хранения вместо 90.

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

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