Биллинг: базовый уровень

Эта страница для случая «хочу быстро понять, за что именно плачу».

Зачем нужна модель из нескольких метрик

Если считать только количество запросов, лёгкий и тяжёлый запросы стоят одинаково. Это несправедливо.

Поэтому биллинг смотрит на фактическую нагрузку: сколько вычислительных ресурсов занято, сколько данных доставлено пользователю и как долго хранятся файлы. Billable-метрики тарифицируются с первой единицы и затем покрываются usage credit плана.

Compute — серверный runtime

Полноценный runtime для ресурсоёмких задач: SSR, API, бэкенд-операции.

Что считается

1. Process Compute (process_compute_cu_seconds) — единая CU-метрика для серверного runtime
2. В расчёт входят фактическое CPU, фактическая память во времени, активное удержание процесса, streaming/WebSocket и discounted warm retention после freeze
3. 1 CU соответствует 1 vCPU + 4 ГБ RAM. Низкая нагрузка с долгим удержанием процесса получает минимальный CU-floor, а CPU/RAM-heavy нагрузка считается по фактическому потреблению

Что не считается

• Запросы, отклонённые до запуска пользовательского кода
• Полностью статическая выдача без выполнения Runtime
• Технические системные ретраи без пользовательского ответа

Isolate — edge runtime

Лёгкий runtime для edge-сценариев: edge functions, middleware, ISR.

Что считается

1. Isolate Compute (isolate_compute_cu_seconds) — единая CU-метрика для edge runtime
2. Процессорное время (cpu_seconds) — активное runtime CPU-like время, без ожидания внешнего I/O
3. Время-памяти (memory_gb_seconds) — интеграл effective memory limit на время выполнения
4. Внешние операции (subrequests) — обращения isolate к внешним сервисам: операции KV, HTTP fetch

Заметка

Память isolate считается по effective memory limit, а не фактическому потреблению. В счёте Isolate показывается одной compute-строкой, а CPU/память остаются breakdown для оптимизации.

Что не считается

• ISR cache hits без выполнения isolate-кода
• Внутренние health-check и telemetry вызовы
• Системные ретраи без пользовательского ответа

Static — доставка файлов

Доставка статических файлов, хранение артефактов деплоя, оптимизация изображений.

Что считается

1. Egress (egress_gb) — объём данных, доставленных пользователю
2. Storage (storage_gb_month) — хранение файлов деплоя
3. Image transforms (image_transforms) — трансформации изображений (resize, конвертация формата)
4. Origin fetch (origin_fetch_gb) — запросы к origin-серверу при cache miss

Что не считается

• Внутренний service-to-service трафик платформы
• Кэш-хиты, не создающие origin egress
• Retry/rehydration без пользовательского ответа

Managed PostgreSQL

Managed PostgreSQL с автомасштабированием, ветвлением баз данных и pay-as-you-go биллингом.

Что считается

1. CU-часы (cu_hours) — CU-weighted время работы сервера (cu_size × active_time). 1 час на 2 CU = 2 CU-часа
2. Storage (storage_gb) — пиковый объём данных и WAL за расчётный период (стоимость включает written_data)
3. Data transfer (data_transfer_gb) — объём данных, переданных между приложением и базой
4. Базы данных (extra_databases) — количество активных БД за период
5. Ветки БД (extra_branches) — количество активных веток за период

Что не считается

• Время простоя (auto-suspend) — за suspended сервер compute не начисляется
• Внутренние операции платформы (репликация, бэкапы)
• Autoscale events (compute автоматически учитывает resize через CU-секунды)

Заметка

CU-часы тарифицируются блоками по 1 CU-час. Auto-suspend помогает значительно снизить compute. Storage использует пиковое значение за период.

Common — платформенные метрики

Часть метрик считается вне конкретного runtime-слоя:

1. build_minutes — время сборки проектов
2. kv_storage_gb_month — billable объём KV хранилища во времени
3. kv_read_million_units и kv_write_million_units — операции KV, нормализованные по размеру payload

Итог

Финальный счёт формируется по отдельным gross line items каждого слоя. Затем применяется included usage credit плана. Это делает расчёт прозрачным и проверяемым: всегда можно определить, какая метрика какого слоя дала основной вклад, какая часть покрыта credit и какая часть попала в extra usage.

Совет

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

См. также

• Слои и метрики
• Pricing Appendix