云成本模型
一个把架构映射到月度美元数的表格或脚本，在构建前算出。
为什么
云账单是事后且不透明的——账单到了才发现出口花了 1.4 万美元，而架构已定型。设计阶段建的成本模型让你在拍板前比较"这设计 3 千/月、那设计 9 千/月"，并在还能改时暴露昂贵组件（出口、托管 DB IOPS）。没有成本模型的团队常选出技术优雅但财务不可持续架构。
何时使用
系统设计时，在选托管服务或多区域布局前。2-4 小时。架构变更时重跑。
如何做
1. 列出架构将用的每个资源（计算、存储、网络、托管服务） 2. 每个查定价单位（每小时、每 GB、每请求、每 IOPS） 3. 估算每单位体量（小时/月、GB 存、请求/月） 4. 相乘求和；加 20% 缓冲应对增长 + 未计开销 5. 标出前 3 成本驱动——优化投入在这里回报最高 6. 在同一模型里比较至少 2 个架构备选 7. 每月用实际用量重跑以校准未来估算
示例
架构：4 台 t3.medium 上的 API + RDS + S3 + CloudFront 成本模型（月）： 计算： 4 × $30/月（t3.medium） = $120 RDS： $93/月（db.t3.small）+ $20 存储 = $113 S3： 500GB × $0.023 = $11.50 出口： 2TB 出 × $0.09 = $180 ← 头号驱动 CloudFront：2TB × $0.085 = $170 合计 ≈ $594/月（+20% 缓冲 = $713） 备选（Lambda 上 API + DynamoDB）：≈ $310/月 → Lambda 成本胜；权衡：冷启动（见 ADR）
常见问题
- ⚠漏掉出口——常占账单 30% 且在每资源定价页不可见；永远显式建模数据传输。
- ⚠用标价而不应用承诺使用或免费层折扣——模型高估并以假成本毙掉好架构。
最佳实践
- ✓建模 p50 和 p90 成本而非点估——用量方差意味着最坏月对预算重要。
- ✓第一天就给每个资源打成本分摊标签，让模型能按组件对真实账单验证。