Жёсткие лимиты, spend cap и оверюз: как работают ограничения облачного биллинга

Под словом «лимит» продаются шесть разных механизмов

Жёсткая остановка отклоняет работу. Throttling принимает её с меньшей скоростью. Мягкая деградация отключает функцию. Бюджетное оповещение отправляет сообщение. Ограниченный spend cap блокирует только названные счётчики. Предоплаченный кредит заканчивается вместе с балансом — либо автоматически пополняется. Автоматический оверюз сохраняет сервис доступным, а счёт открытым.

Эксплуатационный результат важнее названия. Переход базы в режим только для чтения сохраняет чтение, но ломает checkout. Квота индекса логов защищает поисковое хранилище, но может удалить доказательства, нужные во время инцидента. Пауза хостинга защищает карту и делает недоступными все проекты.

Supabase — полезный пример ограниченного spend cap

Supabase документирует, что Pro Spend Cap покрывает egress, storage, логи, MAU, вызовы Edge Functions, сообщения Realtime и несколько других видов использования. Он не покрывает compute, read replicas, собственные домены, выделенные IOPS или throughput, IPv4, log drains, телефонные сообщения MFA и point-in-time recovery.^[1]

При включённом cap превышение покрытых квот после льготного периода может привести к ограничениям сервиса. Среди документированных исходов — приостановленные проекты, базы только для чтения, отключённые запуски функций и ответы HTTP 402. Отключение cap восстанавливает сервис, превращая превышение в оверюз.^[1][2][3]

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

Оповещения, квоты и остановки защищают разные плоскости отказа

Оповещения Grafana Cloud срабатывают, когда использование превышает порог; они не описаны как универсальная остановка ingest. Datadog может жёстко ограничить логи в индексе, пока другие пути логов продолжают работать. New Relic Free останавливает ingest и доступ к платформе после 100 ГБ, а платное использование продолжается по условиям тарифа.^[5][4][6]

Vercel Spend Management может уведомить, вызвать webhook или приостановить проекты на заданной сумме. Пауза сильнее письма, но превращает событие биллинга в событие доступности. Контроль провайдера нужно сочетать с rate limit приложения и независимым каналом оповещения.^[7]

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

Напишите контракт отказа биллинга

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

Затем проверьте границу ниже production. Исчерпайте небольшую sandbox-квоту, подтвердите точную ошибку, убедитесь, что один клиент не способен поглотить общий лимит организации, и докажите, что оператор восстановит сервис без удаления доказательств.

• Зафиксируйте, нужна ли платёжная карта и пополняются ли кредиты автоматически.
• Перечислите каждый счётчик вне spend cap, включая поддержку и выделенные дополнения.
• Установите бюджеты арендатора и операции раньше общего лимита аккаунта провайдера.
• Определите, что разрешено остановить первым: превью, преобразования, AI-вызовы, запись или всё приложение.
• Проверьте сброс на границе платёжного периода и ручной аварийный путь разблокировки.