多邻国打卡打到 AWS 发烧？小绿鸟年省 20% 实录

引言

当你为多邻国连续打卡 365 天骄傲时，这只让人又爱又恨的小绿鸟——背后的工程师们，在默默处理一件更“烧脑”的事：

那就是 AWS 账单上支出的天文数字。

如何将模糊的云账单转化为清晰的明细去向？如何在几个月之内砍掉数百万美元的云成本？如何在保证产品功能不受影响的情况下精准配置计算资源？

本文将带你走进多儿真实的一线复盘。

01/背景

如今，多邻国已从最初的小众产品成长为语言学习巨头。

近年来，我们持续升级用户喜爱的" Stories "功能，并推出沉浸式课程" DuoRadio "和" Adventures "等创新内容。

尽管对产品未来充满期待，但我们必须面对一个残酷现实：AWS 的账单可不是靠“未来可期”就能支付的。

每一个光鲜的功能都需要资源维护，且往往伴随着高昂成本。多年累积下来，这些支出已达到每年数百万美元！

因此在2024年初，我们发起了一项重大行动：在不影响产品的前提下削减云支出。

数十名工程师通力合作，仅用数月便实现了20%的年度成本节省！以下是我们的实战经验总结。

02/可观测性至关重要

要降低云成本，首先必须看清每一笔支出的去向。

我们需要明确回答两个核心问题：

• “我们花了多少钱？都用在了什么地方？”

• “这些开支随着时间是如何变化的？”

一开始，我们引入了一款第三方工具 CloudZero，将模糊的云账单转化为可查询的明细数据。

通过分析头部支出项，我们发现了不少意外情况！

比如，某个 Staging 环境的开销竟然比生产环境还贵，原因竟是某位工程师在测试时手动扩容后忘记缩回了...

让更多工程师关注成本，是削减开支的重要第一步，所以我们提升了成本数据的可发现性和可访问性：

• 扩大监控范围：不再局限于 AWS，还扩展到了 OpenAI 等其他云服务。

• 集成指标系统：将云支出数据整合到现有的监控体系中，做到可视化管理。

• 建立周报机制：每周发送云成本报告，工程师无需主动查询就能掌握服务成本变化，实现"被动监控"。

03/核心原则：按需付费

这听起来很简单，实际清理时，你很可能会因为那些被浪费的云成本账单感到大吃一惊。

（想想你那些还没取消的订阅😱）

我们在排查时发现了大量闲置资源，例如：

• 废弃的 ElastiCache 集群

• 无人使用的完整数据库

• 甚至已下线的微服务

这些僵尸资源大多来自已下线但未彻底清理的遗留功能——代码虽然已经废弃，但相关基础设施还在默默运行并产生费用。

如果当初开发者知道这些"技术债"每月将产生数万美元的实际账单，他们清理代码的积极性绝对会大幅提高！

清理策略升级

削减成本不仅仅是删除未使用的资源，还涉及数据管理优化。

以下是我们节省开支的几个实际案例：

1. S3 存储优化

📌问题：

• 活跃使用的S3存储桶保留了完整的修改历史版本；

• 备份数据过于久远，远超业务需求

🔎方案：

• 为最大存储桶添加生命周期策略，大幅节省了存储成本。

2. DynamoDB 过期数据清理

📌问题：

• DynamoDB 表中堆积了大量过期数据，但我们仍在为这些数据买单。

🔎方案：

• 添加存活时间（Time To Live）策略。

⚠️ 注意：TTL规则仅对新数据生效，旧数据需手动清理（可能很麻烦！

3. 日志成本优化

📌问题：

• 无采样机制，导致日志量爆炸

🔎方案：

• 很多服务在 CloudWatch 上的日志花费巨大，但我们通过优化日志策略节省了大量成本。

💡 小贴士：堆栈追踪日志（Stack Trace）非常占空间，不要在生产环境中直接记录！

精准配置计算资源

计算资源优化同样需要贯彻"按需付费"原则。

我们发现大多数服务都存在明显的资源过度配置问题，通过针对性调整取得了显著的成本优化效果。

对于低内存使用率的服务，就像租了一套两居室却只用了一间。

• 优化方案： 降低其内存分配。

• 成果： 几乎所有服务在 90% 甚至 95% 的内存利用率下都能稳定运行。

同样地，低 CPU 使用率的服务，就像是租了 10 辆卡车来搬小公寓。每一辆“卡车” 代表一个 “任务（task）”——你需要为每个任务付费，所以应该最大化其利用率。

• 优化方案：我们降低了最小任务数阈值，并调整了自动伸缩策略，让任务增加得不那么激进。

• 成果：有一项服务的过度配置尤其严重，仅优化其任务分配就实现了每年节省数十万美元！

或许这个例子对过度配置的服务来说有些夸张，但它确实是真实存在的。

04/利用内置的优化策略

在深入研究 AWS 文档后，我们发现了一些适用于特定读写模式的 DynamoDB 和 RDS 成本优化策略。

此外，AWS 还提供弹性伸缩和任务调度配置，因此我们无需全天 24/7 以满负载运行来应对流量波动。

仅仅通过将一台数据库切换到 Aurora I/O 优化版本，每年就节省了数十万美元！

另一项降本增效的措施是优化我们的预留实例策略。

我们追踪了 EC2 实例、RDS 和 ElastiCache 的使用情况和资源配置，从而明确了计算资源的基本需求，指导我们批量采购预留实例（RI），以获取现有 Spot 实例中无法提供的计算资源。

这些看似基础的优化策略，往往能带来意想不到的成本节约效果。关键在于系统性地分析工作负载特征，并匹配AWS 提供的各种优化机制。

05/云流量优化

在微服务架构中，每个请求都可能引发连锁反应——一个服务调用通常会触发五个以上的后续调用。

这不仅增加了负载均衡和可用区（AZ）带宽成本，还意味着每个服务都需要部署更多任务实例来处理请求！

我们采用了两种优化策略来降低流量和成本：

1. 重构低效代码：

我们发现一个遗留服务存在间接副作用处理问题，其中部分副作用涉及网络依赖，导致大量无节制的API调用。

经过重构后，我们惊讶地发现，仅此一项优化每天减少了 21 亿次不必要的 API 调用！

2. 延长缓存 TTL：

针对一个频繁请求但极少变更资源的服务，我们将其缓存 TTL 时间从 1 分钟延长至 1 小时，成功将下游服务流量降低了 60% 以上。

ETag 缓存有效期延长后，请求量明显下降。
（图中未体现：一位工程师正焦急等待任务数同步下降）

06/结论

我们的许多成本优化措施大多涉及清理技术债和简化复杂代码。这不仅帮助我们节省了大量资金，还提升了代码库的整体健康度！

追求卓越的工程实践往往会带来经济收益，而将云成本纳入设计决策则能推动团队做出更合理的技术选择。

哪怕无法全身心投入成本优化，更重要的是将云成本意识融入架构文化中，因此我们可以采取如下措施：

1. 文化培育

• 将成本意识融入架构文化

• 指导团队成员掌握成本分析方法

• 在技术方案中纳入云成本评估环节

2. 持续优化机制

• 按季度审查团队支出趋势

• 集体研讨高 ROI 的优化策略

从成本可视化到按需使用资源、 充分利用弹性伸缩，多邻国的实践证明：技术上的“精打细算”不仅不会影响产品质量，反而能促使工程团队更健康地发展。

成本优化不需要是一蹴而就的大扫除，而是一场技术能力、工程文化与团队协作的长期较量。

欢迎关注⌈ CloudPilot AI ⌋，后续我们将为您带来更多云成本优化干货！

PS：如果你今天还没优化云成本——Duo 可能不会放过你。🐦

推荐阅读

MCP Server实践，轻松搞定AWS云成本分析
KubeCon EU 2025：一个非典型参与者的现场观察
「出海匠」借助CloudPilot AI实现AWS降本60%，支撑AI电商高速增长