AWS CUR 深度分析 Amazon KVS 用量：三维拆解法
内容提要
本文介绍用AWS CUR分析Amazon Kinesis Video Streams用量的三维拆解法：将总用量分解为活跃设备数×推流时长×等效码率，通过Athena查询追踪各维度变化定位费用增长原因。文章详解KVS计费模型、CUR统计陷阱（如月初设备数虚高、BytesHr误导），并通过实战案例展示归因分析，最后给出清理Signaling Channel、优化存储分层等针对性建议。
延伸解读
三维拆解法的核心价值
三维拆解法将KVS总用量分解为活跃设备数、推流时长和等效码率的乘积，帮助定位费用增长的具体来源。通过分别追踪各维度变化，可量化设备数、时长或码率各自的贡献，避免笼统归因。该方法尤其适用于设备规模大、增长原因复杂的场景，为优化提供数据支撑。
CUR统计陷阱与规避
分析CUR时需注意三个陷阱：月初SignalingChannel记录导致设备数虚高，应仅用BytesIn统计活跃设备；DataTransfer的resource_id格式需先确认再过滤；BytesHr代表存储而非当天推流，统计活跃设备应使用BytesIn。规避这些陷阱才能获得准确数据。
优化建议的适用条件
文章建议清理未使用的Signaling Channel、优化存储分层、调整设备端推流策略等，但均需基于分析结果。例如，清理channel需确认channel数远超活跃stream数；迁移Warm Tier需计算存储打平点，低码率设备可能不划算。优化应针对具体根因，避免盲目操作。
Q&A
如何使用AWS CUR分析Amazon Kinesis Video Streams的用量？
可以使用三维拆解法：将总Ingest用量分解为活跃Stream数×平均活跃小时数×等效码率，通过Athena查询CUR数据，分别追踪每个维度的变化趋势，从而定位费用增长的原因。
Amazon KVS的计费模型包括哪些部分？
Amazon KVS的计费分为Video Stream和WebRTC两大模块。Video Stream包括Ingest（按GB计费）、Storage（按GB-Month计费）、Consumption（按GB计费）和Image Extraction（按千张计费）。WebRTC包括Signaling Channel（按channel/月）、Signaling Messages（按百万条）、TURN Streaming Minutes（按千分钟）、Media Ingested via WebRTC（按分钟）和Session Viewing with Multi-Viewer（按viewer分钟）。此外，2025年11月起存储新增Hot/Warm分层定价。
在CUR中统计活跃设备数时有哪些常见陷阱？
常见陷阱有两个：一是月初设备数虚高，因为SignalingChannel按活跃月计费，月初大量设备首次连接会产生大量记录，导致distinct resource_id统计偏高；二是BytesHr不代表当天推流，它是存储计费，只要数据在保留期内就会持续产生，因此统计活跃设备应使用BytesIn而非BytesHr。
如何通过CUR计算等效码率？
等效码率可以通过SQL查询计算：对每条BytesIn记录（每个stream每小时）的用量取平均，即avg_gb_per_stream_hour = sum(line_item_usage_amount) / count(*)。然后可转换为Kbps：码率(Kbps) = avg_gb_per_stream_hour × 1024 × 1024 × 8 ÷ 3600。
如何分析KVS费用增长的原因？
首先运行SQL-1查看活跃stream数和总ingest量的变化；然后运行SQL-2对比推流时长分布，看是否有时长增加；再运行SQL-3检查等效码率是否变化。通过三维分解，可以确定增长主要来自设备数、推流时长还是码率的变化。
针对KVS成本优化有哪些建议？
建议包括：清理未使用的Signaling Channel；优化存储分层，如缩短Hot Tier retention或迁移至Warm Tier（注意30天最低计费）；设备端优化，如采用H.265编码、自适应码率、事件触发推流；排查WebRTC TURN成本，改善ICE配置等。
Warm Tier迁移前需要计算哪些账？
需要计算两笔账：一是存储打平点，Warm Tier有30天最低计费，retention≥30天才开始省存储费，16天约持平，7天约贵2倍，2天约贵8倍；二是低码率设备额外注意，Warm Tier的Ingest按fragment条数计费，低码率设备可能不划算，需比较每月fragment数×Warm Ingest单价与每月节省的存储费。
