📌 核心知识点
成本优化实战
📖 成本管理基础
AWS 的成本管理是一个重要且复杂的主题。在 EC2 等服务上,需要在工程投入(更多分析、更多工具、更复杂的架构)和 AWS 支出之间做权衡。如果你的成本较小,很多优化工作可能不值得投入。但当成本增长超过一名工程师的薪水时,认真投资优化通常是值得的。
📒 Cost Explorer ∙ Billing 文档 ∙ 定价计算器
🖼️ 成本优化图解补充

看图重点:Right Sizing 的第一步是先把实例家族选对,而不是只改实例大小。

看图重点:高可用方案会增加成本,设计时要明确可用性目标与预算平衡。

看图重点:入口层设计会影响 LCU 与跨可用区流量成本,需结合监控调优。

看图重点:容器成本不仅是算力,还包括镜像拉取、网络与日志开销。
免费套餐
# AWS 免费套餐允许非常有限地免费使用资源
# 例如:微型实例和小量存储
# 注意:
# - 很多服务只在账户创建后的前 12 个月免费
# - 部分服务永久提供免费用量
# 创业公司福利:
# AWS Activate 计划为特定基金或加速器的创业公司
# 提供数万美元的免费额度
成本可见性工具
# 🔹 启用账单报告,安装开源工具监控 AWS 资源使用
# 推荐工具:
1. Teevity Ice (Netflix 开发) - 首选
2. Security Monkey - 安全监控
3. Cloud Custodian - 资源管理
# 🔸 Ice 的局限:不涵盖预留实例的分摊成本
# 第三方服务:
# - Cloudability
# - CloudHealth Technologies
# - ParkMyCloud
# 注意:有些按账单百分比收费,可能很贵
💡 不要害怕向你的客户经理咨询降低账单的建议。让你满意地使用 AWS 是他们的工作。
成本优化原则
AWS 成本优化的四大支柱:
成本优化
├── 右侧选型 (Right Sizing)
│ └── 选择合适的实例类型和大小
├── 提升弹性 (Increase Elasticity)
│ └── 根据需求自动扩缩容
├── 选择正确的定价模型
│ └── 按需、预留、Spot
└── 优化存储和传输
└── 选择合适的存储类和传输方式
Cost Explorer
功能概览
| 功能 | 用途 |
|---|---|
| 成本可视化 | 按服务/账户/标签查看费用 |
| 预测 | 预测未来 12 个月费用 |
| 预留建议 | RI/Savings Plans 推荐 |
| 右侧选型 | 实例降配建议 |
常用分析维度
按服务分析:
└── 哪个服务花费最多?
按账户分析:
└── 哪个团队/环境花费最多?
按标签分析:
└── 哪个项目花费最多?
按时间分析:
└── 费用趋势如何?
成本标签策略
随着基础设施增长,理解成本来源是管理成本的关键。强烈建议标记资源,并随着复杂度增长有效地分组。

看图重点:标签维度要从一开始统一命名规范,否则后续分析会碎片化。

看图重点:账单可按标签聚合,快速定位“哪个团队/项目在拉高费用”。
# 启用成本分配标签后,可以按组织、产品、个人工程师等维度查看费用
aws ce get-cost-and-usage \
--time-period Start=2024-01-01,End=2024-01-31 \
--granularity MONTHLY \
--metrics "BlendedCost" \
--group-by Type=TAG,Key=Environment
# 推荐的标签策略:
# - Environment: prod, staging, dev
# - Team: frontend, backend, data
# - Project: 项目名称
# - Owner: 负责人邮箱
# - CostCenter: 成本中心
# ❗ 成本分配标签只能向前生效
# 不能追溯应用到已计费的项目
详细账单报告
# 如需自定义分析原始账单数据,或发送给第三方服务
# 启用详细账单报告功能
# 报告发送到指定 S3 存储桶
# 包含资源级别的详细成本明细
合并账单
# 多个 AWS 账户可以使用 Consolidated Billing 关联
# 大型企业可能需要复杂的账单结构
# 使用 AWS Organizations 集中管理多个账户
# 未使用的预留实例容量可以跨账户应用
Savings Plans
类型对比
| 类型 | 折扣 | 灵活性 |
|---|---|---|
| Compute | 中等 (约 66%) | 最灵活 |
| EC2 Instance | 最高 (约 72%) | 锁定实例族 |
| SageMaker | 中等 | ML 专用 |
购买建议
Compute Savings Plans:
├── 可用于 EC2, Fargate, Lambda
├── 可跨区域、跨实例族
└── 推荐: 大多数场景首选
EC2 Instance Savings Plans:
├── 锁定特定实例族和区域
├── 更高折扣
└── 推荐: 稳定、可预测的工作负载
覆盖率分析
# 查看 Savings Plans 覆盖率
aws ce get-savings-plans-coverage \
--time-period Start=2024-01-01,End=2024-01-31 \
--granularity MONTHLY
预留实例策略
RI 类型
标准 RI:
├── 1年期: ~40% 折扣
├── 3年期: ~60% 折扣
└── 不可修改
可转换 RI:
├── 1年期: ~31% 折扣
├── 3年期: ~54% 折扣
└── 可转换为其他实例类型
RI 关键特性
# 预留实例不绑定到特定 EC2 实例
# 它们在账单级别应用于符合条件的计算小时
# 合并账单下的 RI 共享:
# - 一个账户未使用的 RI 容量可以应用到另一个账户
# - 前提:相同区域、可用区、实例类型
# ⚠️ 可用区名称在账户间不同
# AWS 会打乱可用区名称以均衡资源使用
# 你的 us-east-1a 可能和另一个账户的 us-east-1a 不在同一物理数据中心
# Reserved Instance Marketplace:
# 如果购买了多余的标准 RI,可以在市场上转售
# 帮助收回未使用 EC2 计算实例时间的成本

看图重点:RI 本质是账单折扣承诺,不是绑定到某一台固定实例。
RI 注意事项
# 📜 可转换 RI 可能需要批量转换
# 有报告说如果一次购买 5 个可转换 RI
# 你可能无法只转换其中 2 个
# 如有影响,请咨询客户经理
# ❗ 架构变化可能导致计算需求变化
# 长期合同看起来有吸引力但可能变得麻烦
RI vs Savings Plans
| 特性 | Reserved Instances | Savings Plans |
|---|---|---|
| 覆盖范围 | 单个服务 | 多服务 |
| 灵活性 | 较低 | 较高 |
| 最大折扣 | 更高 | 略低 |
| 管理复杂度 | 复杂 | 简单 |
购买策略
建议策略:
1. 核心稳定负载 → Savings Plans (Compute)
2. 特定大型实例 → EC2 Instance Savings Plans
3. RDS 数据库 → Reserved Instances
4. 波动负载 → 按需 + Spot
Spot 实例
Spot 实例让你以显著折扣(通常比按需价格便宜数倍)获取 EC2 资源,前提是你愿意接受它们可能在很少或没有警告的情况下被终止。
Spot 使用场景
✓ 批处理作业
✓ CI/CD 构建
✓ 大数据分析
✓ 容器化微服务
✓ 测试/开发环境
✓ 可重启且不维护长期状态的资源
✗ 数据库
✗ 需要持久状态的应用
✗ 单点故障敏感
Spot 定价机制
# Spot 价格是基于 AWS 未使用容量库存的市场驱动浮动价格
# 价格通常较低,但可能会飙升
# 关键点:
# - 你设置一个高出价表示愿意支付的最高价
# - 你只支付市场价,不是出价
# - 如果市场价超过出价,你的实例可能被终止
# 价格因实例类型和可用区而异
# 同一实例类型在不同区域价格可能差异很大
# 💡 更大的实例在 Spot 市场不一定更贵
# 查看 Bid Advisor 找到成本效益最高的实例
Spot Fleet 配置
使用 Spot Fleet 可以在实例类型、可用区甚至区域之间竞标,实现更大的成本降低和更好的稳定性:
{
"SpotPrice": "0.05",
"TargetCapacity": 10,
"LaunchSpecifications": [
{
"InstanceType": "c5.large",
"WeightedCapacity": 2
},
{
"InstanceType": "c5.xlarge",
"WeightedCapacity": 4
}
],
"AllocationStrategy": "diversified"
}
Spot 最佳实践
# 1. 应用性能分析
# - 分析应用的运行时特性
# - 确定最低 CPU、内存、磁盘需求
# - 有了这些信息后才能优化 Spot 成本
# 2. 跨实例类型竞标
# - 不要固定实例类型
# - 跨多种符合需求的实例类型竞标
# - 例如:需要 4 核 CPU,选择任何 ≥4 核且 Spot 价格最低的
# 3. 价格监控
# - Spot 价格随实例类型、时间、区域、可用区波动
# - 使用 AWS CLI 和 API 查询 Spot 价格元数据
# - 基于历史价格构建算法:优化成本、最大化可用性、提供可预测性能
# 4. 实例池化 (高级)
# - 对于大量突发性任务,考虑实例池化
# - 创建和维护 Spot 实例,用完不终止,促进复用
# - 典型池化可带来 45-60% 成本优化,40% 创建时间减少
# - Netflix 的池化实现: techblog.netflix.com
中断处理
# EC2 实例中断通知处理
import requests
import time
def check_spot_interruption():
try:
response = requests.get(
'http://169.254.169.254/latest/meta-data/spot/instance-action',
timeout=2
)
if response.status_code == 200:
# 2 分钟后将被终止
graceful_shutdown()
except:
pass # 没有中断通知
# 也可以通过 CloudWatch Events 监控终止事件
Spot 管理注意事项
# 🔸 无生命周期保证
# Spot 实例的生命周期完全取决于竞价
# 不适合有强 SLA 的时间敏感任务
# AWS 在终止前提供 2 分钟警告
# 🔹 API 返回数据粒度不同
# 请求最近 10 分钟历史 → 细粒度数据
# 请求最近 2 天历史 → 粗粒度数据
# 不要假设会获取所有数据点,会有跳过的间隔
# ❗ 不要过度优化
# 如果只用几台机器,成本可接受,故障率低
# 不要尝试复杂的 Spot 管理
# 为省几百美元而花大量精力构建/维护是不值得的
数据传输费用
对于涉及大量网络流量的部署,AWS 支出的很大一部分与数据传输相关。在可用区之间、区域之间、区域内部、以及 AWS 和互联网之间的数据传输成本会有显著差异,取决于部署选择。

数据传输定价规则
| 传输类型 | 费用 |
|---|---|
| 同区域 EC2 ↔ S3 | 免费 |
| 同区域 EC2 ↔ RDS | 免费 |
| 跨区域传输 | $0.02/GB |
| 出 Internet | $0.09/GB (前 10TB) |
| 入 Internet | 免费 |
| CloudFront 出站 | $0.085/GB (比直接出 S3 便宜) |
⚠️ 数据传输常见陷阱
# 🔸 AZ 之间的流量
# EC2 跨 AZ 流量实际上与跨区域相同!
# 例如:Cassandra 集群跨 AZ 部署有助于高可用,但会增加网络成本
# 🔸 使用不必要的公网 IP
# 如果使用 EC2 的 Elastic IP 或公网 IP,
# 即使在同一 AZ 内本地访问也会产生网络费用!
# 🔸 托管 NAT Gateway 数据处理费
# 使用托管 NAT Gateway 让流量从私有子网出站
# 会在数据传输定价基础上额外收取 4.5¢/GB 数据处理费
# 超过一定规模后,自建 NAT 实例更划算
# 🔸 某些服务免费跨 AZ 传输
# 你可能没注意到的隐藏价值:
# EFS, RDS, MSK 等服务提供免费的跨 AZ 数据传输
优化数据传输成本
- 使用 VPC 端点: 避免通过 Internet 访问 S3
- 选择正确区域: 尽量让相关服务在同一区域
- 使用 CloudFront: 缓存内容减少源站传输
- 压缩数据: 传输前压缩,减少传输量
- 避免不必要的公网 IP: 内部通信用私有 IP
- 评估自建 NAT: 大流量时考虑替代托管 NAT Gateway
存储优化
S3 存储类选择
| 存储类 | 场景 | 月成本/GB |
|---|---|---|
| Standard | 频繁访问 | $0.023 |
| Intelligent-Tiering | 访问模式不确定 | $0.023 |
| Standard-IA | 不频繁访问 | $0.0125 |
| Glacier Instant | 存档但需即时访问 | $0.004 |
| Glacier Flexible | 存档,分钟级恢复 | $0.0036 |
| Glacier Deep Archive | 长期存档 | $0.00099 |
生命周期策略

看图重点:生命周期策略要同时看“转储时间点 + 最小存储时长限制”,避免反向增加成本。
{
"Rules": [
{
"ID": "ArchiveOldLogs",
"Status": "Enabled",
"Filter": { "Prefix": "logs/" },
"Transitions": [
{
"Days": 30,
"StorageClass": "STANDARD_IA"
},
{
"Days": 90,
"StorageClass": "GLACIER"
}
],
"Expiration": { "Days": 365 }
}
]
}
EBS 优化
gp2 → gp3 迁移:
├── 基线 IOPS 提升: 3,000 (免费)
├── 成本降低: ~20%
└── 无需停机迁移
未使用 EBS 卷:
├── 定期清理未挂载的卷
└── 快照后删除不需要的卷
💡 EBS 成本优化技巧:
# 🔹 标准和 gp2 EBS 卷的 IOPS 随大小增加
# 简单增大卷大小可能比显式购买更好性能更划算
# 这种方式通常可以节省 2/3 的成本!
# ❗ EBS 卷类型说明
# "standard" (st1 或 sc1) 实际上是老式机械硬盘
# 只能提供数百 IOPS
# 除非真的要削减成本,否则不推荐
# 现代 SSD 类型:
# - gp3: 通用 SSD(推荐)
# - io1/io2: 预置 IOPS(高性能)
EFS 成本考虑
# EFS 按存储的数据量收费
# 成本大约是 gp2 EBS 的 3 倍!
# 选择 EFS 的场景:
# - 需要多个实例同时访问
# - 需要自动扩展存储
# - 简化文件共享
# ⏱ EFS 元数据操作消耗 Burst Credits
# 递归遍历包含数千文件的目录可能消耗大量 Burst Credits
# find 或 chown -R 等命令可能影响性能
资源优化
识别闲置资源
# 查找低利用率 EC2
aws ce get-rightsizing-recommendation \
--service EC2 \
--configuration '{
"RecommendationTarget": "SAME_INSTANCE_FAMILY",
"BenefitsConsidered": true
}'
常见浪费场景
| 资源 | 浪费场景 | 解决方案 |
|---|---|---|
| EC2 | 过度配置 | 降配或使用自动扩缩容 |
| EBS | 未使用卷 | 定期清理 |
| EIP | 未关联 | 释放或使用 |
| RDS | 过度配置 | 使用 Aurora Serverless |
| NAT Gateway | 跨 AZ 流量 | 每个 AZ 一个 NAT GW |
Budgets 告警
创建预算
aws budgets create-budget \
--account-id 123456789012 \
--budget '{
"BudgetName": "MonthlyBudget",
"BudgetLimit": {
"Amount": "1000",
"Unit": "USD"
},
"BudgetType": "COST",
"TimeUnit": "MONTHLY"
}' \
--notifications-with-subscribers '[
{
"Notification": {
"NotificationType": "ACTUAL",
"ComparisonOperator": "GREATER_THAN",
"Threshold": 80
},
"Subscribers": [
{
"SubscriptionType": "EMAIL",
"Address": "admin@example.com"
}
]
}
]'
💡 专家建议
先优化架构,再优化成本
不要为了省钱牺牲可用性。首先确保架构合理,然后在不影响性能的前提下优化成本。
⚠️ 常见陷阱
购买决策陷阱
- 过度购买 RI: 业务变化导致浪费
- 忽略可转换 RI 限制: 可能需要批量转换
- Fargate 成本估算不足: 可能比 EC2 贵数倍
传输费用陷阱
- 忽略数据传输费: 跨区域传输成本高
- AZ 间流量: 与跨区域成本相当
- 公网 IP 费用: 即使本地访问也收费
- NAT Gateway 处理费: 4.5¢/GB 额外费用
运营陷阱
- 开发环境 24/7 运行: 应该夜间关闭
- 未设置账单警报: 发现异常费用太晚
- S3 成为垃圾场: 用户随意上传到未清理的位置
- EBS 卷类型选错: st1/sc1 是机械硬盘
Spot 陷阱
- 过度优化 Spot: 为省小钱花大量工程时间
- 假设 API 数据完整: Spot 价格历史有跳过的间隔
- 忽略 2 分钟警告: 未实现优雅关闭
📚 本章小结
- 成本优化需要在工程投入和支出之间权衡
- AWS 免费套餐有 12 个月限制和永久免费两种
- 成本标签只能向前生效,不能追溯
- Savings Plans 比 RI 更灵活,推荐使用
- Spot 实例可节省高达 90%,但需要接受中断风险
- AZ 间流量与跨区域相当,规划时注意
- NAT Gateway 有额外 4.5¢/GB 处理费
- EBS 增大卷大小可能比购买更好性能更划算
- EFS 成本约为 EBS 的 3 倍
- 使用 Trusted Advisor 获取优化建议
- 不要害怕向客户经理咨询降低账单的建议