深色模式
云成本优化
摘要：云成本优化不是「一次性降配」，而是持续的发现—决策—执行循环。本文给出四类最容易见效的抓手：清理闲置、规格降配、预留/节省计划、存储与流量优化，并强调所有降本动作都必须先验证业务指标。
适用环境
bash
# 需要云厂商的成本分析（Cost Explorer / 账单）只读权限
aws ce get-cost-and-usage --help >/dev/null && echo "ok"
which jq bc1
2
3
2
3
操作步骤
一、先看清钱花在哪
bash
# 按服务维度看最近 30 天成本
aws ce get-cost-and-usage \
--time-period Start=2026-09-09,End=2026-10-09 \
--granularity MONTHLY --metrics BlendedCost \
--group-by Type=DIMENSION,Key=SERVICE \
--query 'ResultsByTime[].Groups[].[Keys[0],Metrics.BlendedCost.Amount]' --output table
# 按标签维度（前提是有打标签）
aws ce get-cost-and-usage \
--time-period Start=2026-09-09,End=2026-10-09 \
--granularity MONTHLY --metrics BlendedCost \
--group-by Type=TAG,Key=env1
2
3
4
5
6
7
8
9
10
11
12
2
3
4
5
6
7
8
9
10
11
12
先找出占比最大的两三项，优化才有意义——在占比 1% 的项目上折腾是浪费时间。
二、清理闲置资源（见效最快）
bash
# 1) 未挂载的云盘（最常见浪费）
aws ec2 describe-volumes --filters Name=status,Values=available \
--query 'Volumes[].[VolumeId,Size,CreateTime]' --output table
# 2) 未绑定的弹性公网 IP（闲置也计费）
aws ec2 describe-addresses --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' --output table
# 3) 孤立的快照（原实例已删除但快照还在）
aws ec2 describe-snapshots --owner-ids self \
--query 'Snapshots[].[SnapshotId,StartTime,VolumeSize]' --output table
# 4) 空闲的负载均衡（后面没有健康实例）
aws elbv2 describe-load-balancers \
--query 'LoadBalancers[].[LoadBalancerName,CreatedTime]' --output table
# 5) 长期低 CPU 的实例（降配候选）
aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0abc --start-time 2026-09-09T00:00:00Z \
--end-time 2026-10-09T00:00:00Z --period 86400 --statistics Average Maximum1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
危险
删除资源是不可逆的。删除快照和云盘前，必须确认：① 有更新的备份；② 该资源没有关联任何线上业务；③ 已通知资源 owner。建议先做快照再删除，并保留 7 天观察期。
三、规格降配
降配前必须用数据支撑——看 30 天的 CPU、内存、磁盘 IO 峰值：
bash
# 查看实例 30 天 CPU 最大值
aws cloudwatch get-metric-statistics --namespace AWS/EC2 --metric-name CPUUtilization \
--dimensions Name=InstanceId,Value=i-0abc \
--start-time 2026-09-09T00:00:00Z --end-time 2026-10-09T00:00:00Z \
--period 3600 --statistics Maximum \
--query 'Datapoints | sort_by(@, &Timestamp) | [-1]' --output table1
2
3
4
5
6
2
3
4
5
6
判断标准：CPU 峰值长期低于 30%、内存峰值长期低于 50%，则可考虑降一档。降配后要观察 48 小时业务指标（响应时间、错误率）。
四、预留实例 / 节省计划
对稳定运行一年以上的基础负载，用承诺消费换折扣：
bash
# 查看当前预留实例的覆盖率与利用率
aws ce get-reservation-coverage \
--time-period Start=2026-09-09,End=2026-10-09 --granularity MONTHLY
aws ce get-reservation-utilization \
--time-period Start=2026-09-09,End=2026-10-09 --granularity MONTHLY
# 让厂商推荐合适的预留方案
aws ce get-reservation-purchase-recommendation --service "Amazon Elastic Compute Cloud - Compute" \
--lookback-period-in-days SIXTY_DAYS --term-in-years ONE_YEAR --payment-option NO_UPFRONT1
2
3
4
5
6
7
8
9
2
3
4
5
6
7
8
9
注意
预留买的是「承诺消费」，用不满反而更贵。只给长期稳定的基础量买预留，弹性部分继续用按量付费。建议首单覆盖率控制在 50%-70%。
五、存储与流量优化
bash
# 1) 存储分层：30 天未访问转低频，90 天转归档（见对象存储生命周期规则）
aws s3api put-bucket-lifecycle-configuration --bucket my-bucket --lifecycle-configuration file://lifecycle.json
# 2) 快照保留策略：只保留最近 N 份，避免快照无限增长
aws rds modify-db-instance --db-instance-identifier prod-mysql --backup-retention-period 14
# 3) 跨地域/跨可用区流量：检查是否有不必要的跨 AZ 调用
# 同 AZ 内的服务间调用通常不收费，跨 AZ 双向收费1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
六、建立持续降本机制
text
每周：扫描闲置资源，通知 owner 认领或删除
每月：账单复盘会，看环比增长与异常项
每季：重新评估预留覆盖率与规格合理性1
2
3
2
3
验证
- [ ] 闲置云盘、未绑定 EIP、孤立快照数量归零或已记录豁免原因
- [ ] 降配机器的业务指标（响应时间、错误率）在观察期内无劣化
- [ ] 预留覆盖率与利用率报告显示利用率 > 95%
- [ ] 存储分层规则已生效，低频/归档容量占比可查
常见坑
- 只看折扣不看利用率：买了大量预留却用不满，比按量付费更贵。
- 删了还在用的资源：靠名称猜用途是危险的，必须打标签、查关联、问 owner。
- 优化完不验证：降配后 CPU 跑满导致响应变慢，省的钱抵不上业务损失。
- 忽略流量费用：计算、存储降下来了，跨 AZ 和公网出流量却占比很高。
- 一次性运动式降本：半年后又回到原点，必须固化成每周/每月的例行动作。