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

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

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

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

Поэтому Runtime-биллинг смотрит на фактическую нагрузку:

• Сколько раз Runtime действительно выполнялся
• Сколько процессорного времени он потребил
• Сколько памяти и как долго он занимал
• Сколько времени экземпляры держались в готовом состоянии

Так модель лучше отражает реальную себестоимость.

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

1. Выполнения (invocations)

Каждый запрос, который дошёл до пользовательского Runtime и получил ответ.

2. Процессорное время (cpu_seconds)

Фактическое время работы CPU на выполнение вашего кода.

3. Время-памяти (memory_gb_seconds)

Не только «сколько памяти», но и «как долго». 1 GB в течение 10 секунд = 10 GB-s.

4. Время удержания (residency_seconds)

Время, когда экземпляр удерживается в состояниях готовности и потребляет ресурсы платформы.

5. Дополнительные метрики (опционально)

Если план это включает, отдельно считаются:

• Длительность потоковой выдачи (streaming_seconds)
• Время WebSocket-соединений (websocket_connection_seconds)

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

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

Где в этом месте CRU

CRU удобно использовать как сводный индикатор нагрузки. Он помогает сравнивать релизы и проекты между собой.

Но финальный счёт формируется по отдельным измерениям (line items), чтобы расчёт был прозрачным и проверяемым.

Совет

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

Публичная нормативная версия методики: Pricing Appendix (Runtime).