Перейти к содержимому

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

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

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

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

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

  1. Выполнения (invocations) — каждый запрос, дошедший до Runtime и получивший ответ
  2. Процессорное время (cpu_seconds) — фактическое время работы CPU
  3. Время-памяти (memory_gb_seconds) — не только «сколько памяти», но и «как долго». 1 GB в течение 10 секунд = 10 GB-s
  4. Время удержания (residency_seconds) — время в состояниях готовности (ready, reserved). Frozen-время не тарифицируется
  5. Streaming (streaming_seconds) — длительность потоковой выдачи
  6. WebSocket (websocket_seconds) — время WebSocket-соединений
  • Запросы, отклонённые до запуска пользовательского кода
  • Полностью статическая выдача без выполнения Runtime
  • Технические системные ретраи без пользовательского ответа

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

  1. Выполнения (invocations) — каждый isolate-запрос с пользовательским ответом
  2. Процессорное время (cpu_seconds) — wall-time выполнения isolate-кода
  3. Время-памяти (memory_gb_seconds) — интеграл сконфигурированной памяти на время выполнения
  4. Внешние операции (subrequests) — все обращения isolate к внешним сервисам: операции KV, HTTP fetch
  • ISR cache hits без выполнения isolate-кода
  • Внутренние health-check и telemetry вызовы
  • Системные ретраи без пользовательского ответа

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

  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 с автомасштабированием, ветвлением баз данных и 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-секунды)

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

  1. build_minutes — время сборки проектов
  2. kv_storage_mb — объём KV хранилища

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