Infracost资源映射与成本组件命名规范指南
前言
Infracost作为一款优秀的云成本估算工具,其核心功能是通过解析基础设施即代码(IaC)文件来预测云资源费用。在这个过程中,如何准确映射云资源并合理命名成本组件至关重要。本文将深入解析Infracost项目中资源映射与成本组件命名的设计理念和最佳实践。
核心概念解析
资源(Resource)与成本组件(Cost Component)
在Infracost的架构设计中,资源指的是与IaC提供者(如Terraform)一一对应的云服务资源实体。例如,一个AWS NAT Gateway资源在Terraform中对应一个aws_nat_gateway
资源。
而成本组件则是构成资源费用的具体计费项,它由价格和使用量计算得出。以AWS NAT Gateway为例,它包含两个成本组件:
- 按小时计费的基础费用
- 数据处理量的费用
这种设计使得成本估算既全面又细致,能够反映云服务的实际计费模式。
成本组件命名规范
命名依据来源
Infracost团队在确定成本组件名称时主要参考以下权威资料:
- 云服务商官方定价页面
- 各云平台的定价计算器
- 详细的计费CSV文件
命名原则
-
清晰易懂:名称应直观反映计费项本质,使用户无需查阅额外文档即可理解。例如,AWS定价页面上可能使用"Storage Rate"这样的模糊表述,而Infracost会采用更清晰的"Storage (provisioned IOPS SSD)"。
-
复数形式:在合适的情况下使用复数形式,如"Certificate renewals"、"Requests"等。
-
可变参数处理:将可能变化的参数放在括号内,保持名称主体不变。例如:
- 正确:"Storage (gp2)"
- 不正确:"General Purpose SSD storage (gp2)"
-
层级结构:未来计划为成本组件添加专门字段来存储括号内的元数据,使结构更清晰。
通用设计指南
计数处理
- 不将计数(count)包含在成本组件名称中
- 对于影响费用的计数参数(如desired_count),应在计算HourlyQuantity/MonthlyQuantity时考虑
单位规范
- 复数形式:使用复数单位,如"hours"、"requests"、"GB"等
- 复合单位:对于"每单位时间"的计费,使用单数形式,如"Per GB per hour"
- 资源单位:
- 对于代表单个实体的资源(如aws_instance),使用"months"或"hours"
- 其他情况使用实际计费单位,如"queries"
- 数据传输:使用"GB"作为单位
- 存储资源:对于按"单位-月"(如GB-months)计费的,使用基础单位"GB"
单位乘数应用
- 默认UnitMultiplier为1
- 特殊情况:
- 大数量级:如"1M requests"对应UnitMultiplier: 1000000
- 时间单位转换:如将小时计费转换为月展示时使用HourToMonthUnitMultiplier
分级定价命名
使用标准数量级后缀:
- K:千
- M:百万
- B:十亿
- T:万亿
示例:"Requests (first 300M)"、"Messages (first 1B)"
采购选项与实例类型
- 包含采购选项:"Database instance (on-demand)"
- 包含实例类型:"Database instance (on-demand, db.t3.medium)"
其他规范
- 大小写:
- 名称首字母大写
- 云商专用类型保持原样,如"gp2"
- 冗余词去除:去除"Rate"、"Volumes"等不必要词汇
- 括号使用:仅使用一组括号,包含所有可变参数
使用文件指南
术语一致性
尽量与云服务商定价页面术语保持一致,确保用户易于理解。
单位规范
使用小写单位:
- 时间:ms、secs、mins、hrs等
- 大小:b、kb、mb、gb等 单位应放在最后,如"message_size_kb"。
时间维度
- 持续资源:直接命名,如"instances"、"storage_gb"
- 非持续资源:添加"monthly_"前缀,如"monthly_requests"
字符串处理
对于接受字符串的字段,应实现大小写不敏感的匹配,可使用正则表达式的/i标志。
结语
Infracost通过这套严谨的资源映射和成本组件命名规范,确保了成本估算结果的准确性和可读性。这些设计原则不仅反映了云服务的实际计费模式,也考虑到了终端用户的理解便利性。掌握这些规范对于深入理解Infracost的工作原理和进行二次开发都具有重要意义。
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考