两天重构一份 823 美元的 AWS 账单：一套低负载生产系统如何把月费压到预计 180～220 美元

云成本优化不是简单地“换小服务器”，而是先理解业务负载，再用账单和监控寻找真正的成本来源，最后通过滚动发布、健康检查和冷启动测试，证明调整后的系统仍然可靠。

背景：正式生产环境中的固定成本

这是一套已经正式上线、承载真实业务的 SaaS 系统，同时维护 Production 和 Staging 两套 AWS 环境，包含 Dashboard、Gateway API、OpenAPI、SuperAdmin、异步 Worker，以及 Aurora、Valkey、ALB、NAT Gateway 和 CloudWatch 等基础设施。

系统整体负载和资源利用率并不高，但 AWS Cost Explorer 记录的优化前完整账期 UnblendedCost 达到了 822.96 美元。项目希望把月度成本控制在 100～200 美元，同时保留未来快速扩容的能力。

这两个目标存在天然张力：完全按高可用架构配置，会产生大量与流量无关的固定费用；如果为了省钱把所有服务塞进一台机器，又会增加单点故障和未来迁移成本。

因此，我们先确定了三条边界：

• Production 调整不能造成长时间中断；
• 扩容路径必须保留；
• 任何资源都不能只凭感觉删除。

先看账单，而不是先改服务器

我们先按 AWS 服务拆分了优化前账期的费用：

• Amazon ECS：276.59 美元
• RDS：174.79 美元
• EC2 – Other：142.32 美元
• Elastic Load Balancing：77.82 美元
• CloudWatch：57.10 美元
• VPC：41.84 美元

继续拆分后发现，EC2 – Other 中仅两套 NAT Gateway 的小时费和数据处理费就占了 135.72 美元；ALB 的 LCU 流量费很少，主要成本是多个负载均衡器的固定小时费；CloudWatch 则几乎全部来自指标监控。

这说明账单高并不是因为请求量大，而是多套常驻计算、入口、网络出口、数据库实例和增强监控同时计费。

优化顺序也随之明确：先处理按小时收费的固定资源，再处理随使用量变化的小额费用。

先决定哪些能力不能动

成本优化最容易犯的错误，是只按价格排序，却没有先定义业务边界。

Production 已经承载真实业务，因此数据库、缓存、对象存储、密钥管理和稳定的公网入口都要继续保留；可以调整的是副本数量、任务规格和重复资源。Staging 的职责是测试和发布验证，不要求全天在线，因此可以用启动等待时间换取更低的常驻成本。

我们也没有把所有服务迁到一台低价主机。单机方案确实可能继续降低费用，但会把应用、入口和部署集中到一个故障点，还会改变现有发布流程。

继续使用 ECS、ALB 和 Aurora，意味着未来扩容仍然只需提高任务数、任务规格或数据库容量，不必重新设计整套架构。

因此，每项调整都需要回答三个问题：

1. 当前负载是否需要这项容量？
2. 移除后会失去什么能力？
3. 业务增长时能否快速加回来？

这三个问题比“还能不能再便宜十美元”更重要。

合并 ALB，保留成熟的入口层

ALB 可以理解为系统入口处的流量调度器。最初 Production 和 Staging 都有多个 ALB，分别服务不同子系统。低负载时，每个 ALB 的固定小时费比实际流量费更明显。

最终每个环境只保留一个共享 ALB，通过 Host Header 和 Path Rule，将 Dashboard、Gateway、OpenAPI 和 SuperAdmin 的请求转发到各自的 Target Group。

这样多个域名仍然对应独立服务，只是共用同一个入口。

切换时，我们先创建转发规则和 Target Group，确认新目标健康，再修改 DNS。所有域名、证书和业务入口验证正常后，才删除旧 ALB 及其配套资源。

我们也评估过 Cloudflare Tunnel，但它会引入新的账号权限、入口依赖和排障方式，因此最终保留 AWS 原生 ALB。

这一类切换最需要防范的是 503，因此验证不能只看 ALB 状态为 Active，还要检查：

• Listener Rule 是否命中正确的 Target Group；
• 健康检查路径是否返回成功；
• DNS 是否已经指向新入口。

旧 ALB 在切换验证完成前一直保留，确保问题出现时仍有明确的回退路径。

用监控数据指导 Fargate 降配

Production 的 API 和 Web 原本配置较为保守。

降配前的连续 24 小时监控显示：

• API CPU 平均约 2.60%、峰值约 5.86%；
• Web CPU 平均约 2.36%、峰值约 5.60%；
• 内存峰值不到 4%。

我们将 API 和 Web 逐步降到 0.25 vCPU / 0.5 GB。OpenAPI 和 SuperAdmin 已经处于最低规格，不再压缩。

每次修改都使用 ECS 滚动更新：先启动新任务，等 ALB 健康检查通过，再排空旧任务。

降配后的 24 小时监控显示：

• API CPU 平均约 4.84%、峰值约 12.88%；
• Web CPU 平均约 5.34%、峰值约 17.28%；
• 两者内存峰值仍低于 7%。

Production 最终保留四个最低规格在线任务，月度 Fargate 费用预计约 36 美元。闲置 Worker 没有删除，而是设置为 desired=0，需要时可以快速恢复。

降低任务规格并没有改变容器镜像、网络接口或部署方式。未来负载提高时，可以先增加 desired count 横向扩容；如果单个请求确实需要更多 CPU 或内存，再发布更大的 Task Definition。

把扩容路径保留下来，是这次敢于降低常驻容量的前提。

这里存在明确取舍：单任务不是传统意义上的多副本高可用。任务异常时 ECS 会自动重建，但恢复期间可能短暂不可用。当负载、SLA 或业务规模提高后，首先应该恢复的就是关键服务副本数。

Reader 有价值，但当前是否值得常驻？

Production Aurora 原本有一个 Writer 和一个 Reader。

Writer 负责写入和事务，也可以处理读取；Reader 与 Writer 使用同一个 Aurora 分布式集群存储，通过独立实例承接只读查询。它既能分担 Writer 的读取压力，也能在 Writer 故障时被提升为新的 Writer，缩短恢复时间。

检查应用连接、数据库会话和实际请求链路后，我们确认 Reader 正在承载业务读取，它并不是闲置资源。

真正需要判断的是：

当前读取量和故障恢复收益，是否足以覆盖一个常驻实例的成本？

结合整体负载和连接规模评估后，Reader 当前分担的压力有限，Writer 仍能承接这部分读取。

删除前，我们先把读取连接安全切回 Writer，滚动重启应用并验证读取路径；随后查询 PostgreSQL 的 pg_stat_activity，确认 Reader 上只剩 rdsadmin 内部连接，业务流量已经排空，才执行删除。

最终 Production 只保留一个最低容量为 0.5 ACU 的 Serverless v2 Writer。

按当前单价计算，减少一个 Reader 每月可节省约 43.20～44.64 美元。

代价是失去可立即接管的数据库实例；Aurora 存储仍然跨可用区保存，但 Writer 故障时的恢复时间可能更长。未来读压力或恢复目标提高时，可以重新创建 Reader 并恢复读写分离。

数据库调整还涉及 Terraform 资源身份。

原配置使用 count 管理两个实例，直接把数量从 2 改为 1，可能因为数组索引变化而让计划看起来要替换错误的实例。我们先改为稳定的 for_each 标识，并用 moved block 保留 Writer 的资源身份，确认 Plan 只删除目标 Reader 后才执行。

让 Staging 真正按需运行

Staging 原本在工作日定时启动和停止，但测试环境并非每天使用，定时启动仍会产生不必要的计算费用。

我们最终关闭自动启动，将四个 Staging ECS 服务默认设为 0，并把 Aurora 最低容量设为 0 ACU，空闲 15 分钟后自动暂停。

同时提供统一脚本执行 start、status 和 stop，一次管理全部 Staging 服务。

脚本完成后，我们实际执行了从启动、健康检查到停止的完整恢复演练，四个公开入口均通过验证。

按需环境只有被证明能够正常启动，才是真正可靠的按需环境。

日常需要测试时，只需运行：

staging-on-demand.sh start

等待服务和数据库恢复后开始验证；使用结束再执行：

staging-on-demand.sh stop

这比依赖人工在控制台逐个调整服务更容易形成固定操作习惯，也减少了测试结束后忘记关停的可能。

删除 NAT 前，先证明系统不依赖它

NAT Gateway 通常是私有子网访问公网的统一出口。它既收取小时费，也按经过的数据量计费。

优化前账期内，两套 NAT 的小时费约 77.38 美元，数据处理费约 58.34 美元。

我们将 ECS Fargate 任务迁移到公网子网并分配公网 IP，但安全组不开放任何公网 CIDR 入站，只允许 ALB Security Group 访问应用端口。数据库和 Valkey 继续留在私有网络中。

两个 VPC 的私有路由表还增加了免费的 S3 Gateway Endpoint，降低私有路由对 NAT 的依赖。

公网子网不等于容器端口直接暴露到互联网。

公网 IP 解决的是任务主动访问 ECR、Secrets 等服务的出站路径；真正控制入站访问的是安全组。

最终核查中，任务安全组没有 0.0.0.0/0 或公网 IPv6 入站规则，应用端口只能由 ALB 的安全组访问。

删除 NAT 前，我们验证了：

• 镜像拉取；
• Secrets；
• CloudWatch Logs；
• 数据库；
• Valkey；
• ALB 健康状态；
• 业务域名。

Staging 在无 NAT 的情况下完成从 0 冷启动，Production 也成功滚动启动全部新任务。确认系统不再依赖 NAT 后，才删除两套 NAT Gateway 和专用 EIP。

扣除新增的 Fargate 公网 IPv4，固定费用预计净减少约 60～70 美元/月；如果流量接近优化前账期的水平，还会避免相应的 NAT 数据处理费。

这种方案适合当前安全边界，但如果未来需要固定出口 IP、严格私网合规或更复杂的网络控制，就应重新评估 NAT 或 PrivateLink。

处理其他固定费用

Production 两个 ECS Cluster 的 Container Insights 已关闭，基础日志和 ECS 标准指标仍然保留。

优化前账期的 CloudWatch 费用为 57.10 美元，但关闭后的实际降幅需要等待完整账期确认，因此不把预测写成已经实现的节省。

Bastion 改为按需启动并释放公网 IP，预计节省约 7 美元/月；停止的 Worker 预计节省约 8～10 美元/月。

两套 Valkey Serverless 则继续保留：它们已经处于约 0.1 GB 的最低存储计费水平，ECPU 费用合计不到 0.01 美元，继续降低只能通过删除服务，不符合当前需求。

每次只改变一个成本点

整个过程遵循同一条验证链路：

读取现状 → 修改一个成本点 → 滚动发布 → 检查健康状态 → 请求真实域名 → 查看日志和指标 → 再处理旧资源。

Terraform Plan 中一旦出现计划外的替换或删除，我们就停止执行，先修正资源身份或生命周期配置。

例如 Bastion 停止后，状态差异曾导致 Plan 准备重新创建实例；修正生命周期规则并重新检查后，计划才回到预期范围。

优化完成后，Production 和 Staging 分别使用正确的 workspace 和变量文件执行 Plan，最终均为 No changes。

最终费用：优化后的月度成本预估

最终核对显示：

• 两个环境各保留一个 ALB；
• NAT Gateway 均为 0；
• Production 有四个最低规格在线任务；
• 一个停止的 Worker；
• 一个 Aurora Writer；
• Staging ECS 全部停止；
• Staging Aurora 可以自动暂停。

Staging 基本不启动且构建较少时，预计约 180～200 美元/月；正常低负载运行约 190～220 美元/月；构建频繁或 Staging 使用较多时，可能达到 215～245 美元/月。

与优化前完整账期相比，正常低负载月份预计降低约 73%～77%。

优化发生的当月同时包含调整前后的资源费用，Cost Explorer 也可能延迟，因此最终效果应看下一个完整账单周期。

总结

这次优化的核心不是把每项配置都降到最低，而是让资源成本与当前业务负载重新匹配：入口可以共享，计算可以按监控降配，测试环境可以按需启动，Reader 是否保留要同时考虑读取压力和故障恢复，网络出口则必须在验证依赖后才能删除。

最值得复用的原则只有五条：

1. 先看账单，再看监控；
2. 优先处理按小时计费的固定成本；
3. 先迁移和验证，再删除旧资源；
4. Production 使用滚动更新；
5. 为每项降配保留清晰的扩容和恢复路径。

从 823 美元降到预计 180～220 美元，账单有望减少约四分之三。

更重要的是，我们现在清楚每一笔费用为什么存在，也知道未来业务增长时，应该优先把哪些能力加回来。

数据口径：优化前完整账期的费用来自 AWS Cost Explorer 的 UnblendedCost；资源状态、任务规格和安全组来自优化完成后的 AWS API 只读核验；性能数字来自 CloudWatch 的 5 分钟采样点；月度预测按公开 On-Demand 单价和约 730 小时折算，不包含未来可能发生的税费、Support、折扣、Credits 和流量突增。文中的项目名称、域名、账号和资源标识均已脱敏，预测不构成 AWS 官方报价。