Бесплатные SSL, CDN и мониторинг: когда за них всё-таки приходит счёт

MAATRIX

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

Почему бесплатное вообще бывает бесплатным

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

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

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

SSL-сертификаты: лимит по числу доменов и по частоте выпуска

Бесплатные SSL-сертификаты через центры сертификации, работающие по протоколу ACME (классический пример — Let's Encrypt), выдаются автоматически и без ограничения на количество *сайтов*, которыми вы владеете. Но у автоматической выдачи есть два скрытых потолка.

Первый — лимит на количество сертификатов, выпускаемых для одного зарегистрированного домена за определённый период. Он существует, чтобы защититься от автоматических скриптов, которые перевыпускают сертификат при каждом деплое. Если у вас CI/CD дёргает certbot renew --force-renewal на каждый пуш в main, а не только раз в 60 дней при реальном приближении срока истечения, вы рискуете упереться именно в этот лимит — и тогда сертификат просто не выпустится, сайт останется без валидного SSL.

Второй, менее очевидный — лимит на число поддоменов в одном сертификате (SAN, Subject Alternative Names) или на общее число параллельно живых доменов на бесплатном тарифе, если вы используете не «голый» ACME-клиент, а SSL как часть платформы (панель управления, CDN со встроенным SSL, PaaS). Здесь граница обычно завязана не на технологию, а на бизнес-модель конкретного провайдера: N доменов — бесплатно, N+1-й — уже отдельная строка в счёте или отдельный платный тариф.

# типичная проверка: сколько поддоменов реально покрыто сертификатом
echo | openssl s_client -servername example.com -connect example.com:443 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Практический момент: если вы вручную настраиваете Let's Encrypt на своём сервере, вы физически не привязаны к чужому платному лимиту — свои ограничения там технические (частота выпуска), а не коммерческие. Мы разбирали типичные проблемы такой настройки в статье про частые ошибки Let's Encrypt на сервере — и там же видно, что большинство «сюрпризов» с сертификатами — это не коммерческие лимиты, а забытый автопродление или неверный DNS.

CDN: бесплатный трафик кончается быстрее, чем кажется

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

Бесплатные тарифы CDN обычно ограничивают одновременно несколько параметров:

• объём исходящего трафика в месяц (гигабайты/терабайты);
• число запросов (HTTP-запросов к CDN, а не только объём в байтах — тяжёлый сайт с редкими большими файлами и лёгкий сайт с миллионом мелких иконок нагружают лимит по-разному);
• число обслуживаемых доменов/зон;
• иногда — доступные регионы edge-серверов (бесплатный тариф может не покрывать нужный вам регион, и трафик оттуда либо не кешируется, либо тарифицируется отдельно).

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

Отдельная ловушка — исходящий трафик с вашего собственного сервера *к* CDN (fetch/origin traffic), который редко попадает в маркетинговые описания бесплатного тарифа, но иногда учитывается отдельно и может незаметно накапливаться, если кеш CDN настроен неоптимально и он слишком часто «доходит до оригинала». Подробнее о том, почему исходящий трафик — это статья расходов, о которой узнают позже остальных, — в материале про egress-трафик как статью счёта.

Мониторинг: лимит по метрикам, алертам и глубине хранения, а не по «просто пользоваться»

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

• число проверяемых чек-пойнтов (URL, портов, cron-задач) — превысили число бесплатных проверок, добавляя новый сервис или поддомен;
• частота опроса — на бесплатном тарифе интервал проверки может быть, скажем, раз в несколько минут, а не раз в 30 секунд, и более частый опрос уже платный;
• число одновременно активных алертов или каналов оповещения (email — бесплатно, а SMS/звонок/интеграция с мессенджером — уже отдельная опция);
• глубина хранения истории метрик — бесплатный тариф хранит данные неделю-две, а для разбора инцидента месячной давности нужен платный retention;
• число dashboard'ов, пользователей команды с доступом, число kустомных метрик сверх базового набора (CPU, диск, память).

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

Что происходит на границе лимита: три разных сценария

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

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

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

Как заранее посчитать порог и не попасть на сюрприз

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

1. Найти реальные текущие цифры лимита на странице pricing провайдера, а не полагаться на память или на статьи вроде этой — цифры меняются, иногда в сторону сокращения бесплатного тарифа.
2. Определить, какой из ваших параметров ближе всего к лимиту. Для CDN — обычно трафик и число запросов; для SSL — число поддоменов и частота перевыпуска; для мониторинга — число проверяемых точек и частота опроса. Считать нужно не «в среднем», а по пиковым дням/часам — именно пики упираются в лимит первыми.
3. Прогнать текущую нагрузку через панель провайдера, если она показывает процент использования лимита — большинство современных сервисов это делают. Если такой панели нет — оценить вручную: логи сервера дают реальный объём трафика, метрики самого мониторинга — число уже настроенных проверок.
4. Найти явное описание поведения при превышении — тот самый раздел про отключение/деградацию/автотарификацию из предыдущего блока.
5. Заложить план роста на 6–12 месяцев вперёд, а не только текущее состояние. Если проект растёт на 20–30% в квартал, к лимиту можно подойти незаметно уже через два-три квартала — момент планирования сервера или бюджета инфраструктуры на год, который часто забывает лишние статьи расходов, — хороший повод пересчитать и лимиты бесплатных вспомогательных сервисов.
6. Настроить собственный алерт на приближение к лимиту, если провайдер не делает этого сам — например, простую cron-проверку объёма трафика за сутки с оповещением, когда накопленная сумма за месяц приближается к порогу.

# грубая прикидка месячного трафика по логам nginx за сутки
awk '{sum+=$10} END {print sum/1024/1024, "MB за сутки"}' /var/log/nginx/access.log
# и умножить на ~30, держа в уме, что трафик распределён неравномерно

Отдельно стоит держать в голове: если и SSL, и CDN, и мониторинг однажды перестанут быть бесплатными для вашего проекта, дешевле не переключаться панически между провайдерами, а заранее прикинуть, что выгоднее в перспективе года — платный тариф текущего сервиса, альтернативный провайдер с более щедрым бесплатным лимитом, или часть функциональности перенести на собственный сервер (свой Let's Encrypt вместо SSL от платформы, свой кеширующий узел вместо части CDN-трафика, self-hosted мониторинг вместо облачного). Это тот же вопрос, что мы разбирали для трафика в целом: с какого объёма CDN на своём сервере окупается против коммерческого — считать стоит заранее, а не в момент, когда счёт уже пришёл.

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