2. AWS成本与性能度量体系
在AWS生产环境中做成本与性能的协同优化，第一步不是改配置，而是建立一套可信的度量体系。没有度量，优化就只能靠感觉：账单涨了不知道涨在哪里，延迟高了不知道是哪个环节，实例买大了还是买小了也说不清。本节围绕四类工具和两类基础数据（成本分摊标签、性能基线指标）展开，目标是让团队能够回答三个问题：钱花在谁身上、资源用得怎么样、下一步该动哪里。
四类工具的分工
AWS提供的度量工具并不是互相替代的关系，而是处在不同的观察层次上，理解它们的分工比记住功能列表更重要。
- Cost Explorer：面向“钱”的聚合与下钻。它按服务、账号、区域、标签、使用类型等维度展示历史成本与用量，支持按日/月粒度查看趋势，也能做简单的成本预测。它的价值在于把账单从一张总额变成可归因的结构。
- CloudWatch：面向“资源运行状态”的时序数据。它采集CPU、内存（需Agent）、磁盘IO、网络、请求延迟、错误率等指标，是性能基线的数据来源，也是告警的触发点。
- Trusted Advisor：面向“最佳实践检查”的规则引擎。它给出成本、性能、安全、容错、服务配额等类别的检查结果，例如闲置的负载均衡器、未关联的弹性IP、低利用率的EC2实例。它提供的是线索，不是精确结论。
- Compute Optimizer：面向“规格是否合适”的推荐引擎。它基于CloudWatch历史指标，对EC2、Auto Scaling组、EBS、Lambda等给出过度配置或配置不足的判断，并给出建议规格。它回答的是“这台机器该不该换型号”。
这四者的关系可以概括为：Cost Explorer告诉你钱在哪，CloudWatch告诉你资源在怎么跑，Trusted Advisor告诉你哪里可能有问题，Compute Optimizer告诉你具体换成什么。它们共同构成从“发现异常”到“定位对象”再到“给出动作”的链路。
成本分摊标签策略
Cost Explorer能按标签拆分成本，前提是资源上确实打了标签，而且标签键值规范统一。标签策略的核心不是“多打标签”，而是“用最少的标签键覆盖归因需求”。实践中建议固定四个维度：
- Env：prod / staging / dev，用于区分生产与非生产成本，避免开发环境消耗被误算进生产预算。
- Team：归属团队，用于内部结算和责任人定位。
- App：应用或服务名，用于按业务线归因。
- CostCenter：财务成本中心编码，用于与财务口径对齐。
标签落地要解决两个工程问题。第一是激活：在Billing控制台的Cost Allocation Tags中把自定义标签激活为成本分配标签，否则Cost Explorer看不到它们。第二是覆盖：EC2、EBS、RDS、S3、Lambda等主要计费资源都要打上，且要防止拼写漂移（例如“prod”和“Prod”会被当成两个值）。可以用AWS Config规则或Tag Policies约束允许的键值集合，把标签合规变成可检查项。
一个常见的判断依据是“未分配成本占比”。在Cost Explorer中按标签分组后，如果某个标签出现大量“No tag key”或空值，说明覆盖不足，此时任何按团队的成本结论都不可靠。建议把未分配成本控制在总成本的5%以内作为治理目标。
性能基线指标
性能基线是“正常运行时指标应该落在什么范围”的书面约定。没有基线，就无法判断一次延迟上升是异常还是正常波动。建立基线时，建议对每类资源选取少量关键指标，并明确统计口径：
| 资源类型 | 关键指标 | 建议基线口径 |
|---|---|---|
| EC2 / ASG | CPUUtilization、内存使用率 | 生产稳态CPU 20%–60%，内存 40%–75% |
| 应用负载 | P95响应时间、5xx错误率 | P95 < 300ms，错误率 < 0.5% |
| RDS | CPU、连接数、读延迟 | 连接数 < 最大连接数70% |
| EBS | VolumeQueueLength、吞吐 | 队列长度持续 < 1 |
基线不是拍脑袋定的，而是从CloudWatch历史数据中取一段稳定期（例如过去30天）的P50和P95，再结合业务SLO调整。基线一旦确定，就应配置对应的CloudWatch告警，让偏离可被自动发现。需要注意的是，内存、磁盘空间等指标默认不采集，需要在实例上安装CloudWatch Agent并配置采集项，否则基线里会缺一块。
把工具串成一条判断链
实际工作中，这四个工具通常按以下顺序使用：先用Cost Explorer按标签看月度趋势，发现某个Team或App成本环比上升；再用CloudWatch查看对应资源的CPU、内存、延迟是否同步变化；如果指标显示资源长期低负载，用Compute Optimizer获取规格建议；同时用Trusted Advisor检查是否存在闲置的EIP、未使用的负载均衡器等“零收益成本”。最后把结论落到变更上，并在变更后重新观察成本和性能两条曲线，确认优化没有以牺牲稳定性为代价。