150万次请求，1个泄露的密钥：我们如何在6小时内烧掉了3.5万美元的Gemini费用

项目的“实验阶段”本应是最有趣的部分。对我们这样一家专注于AWS原生架构的公司来说，我们最近决定拓展业务，尝试在谷歌云平台（GCP）上测试Gemini 3.1 Pro图像模型。

我们做了每个快速推进的团队都会做的事：绑定了公司信用卡，获取了一个API密钥，然后开始开发。20天后，我们收到了一张3.5万美元的账单，CEO惊慌失措，我们也为此付出了昂贵的一课——深刻理解了GCP默认配额和计费延迟机制的运作方式。

如果你正在“随便试试”AI API，请在醒来发现账单变成五位数之前，先读完本文。

“完美风暴”时间线

这次攻击并不复杂，但却持续不断。由于当时我们正处于实验阶段，尚未将标准的企业级安全协议应用到这个新环境中。

• 美国东部时间凌晨3点：一个未设限制的API密钥被泄露（很可能是通过被入侵的开发环境）。一个自动化僵尸网络开始疯狂调用我们的Gemini 3.1 Pro图像接口。
• 美国东部时间上午8点：我们的CEO收到一条自动计费警报：1.1万美元。
• 美国东部时间上午8点15分：团队紧急行动。我们立即轮换密钥并停用项目计费功能。我们当时真心以为损失止步于1.1万美元。
• 美国东部时间上午11点： “计费幽灵”出现了。 由于GCP的计费数据存在3至5小时的延迟，仪表盘上的金额仍在持续攀升，因为早上的请求终于被系统处理完毕。

最终损失：150万次请求。烧掉了3.5万美元。

事故原因：默认配额陷阱

作为来自AWS生态系统的团队，我们对GCP默认配额之宽松感到震惊。当你启用生成式语言API时，默认的“每分钟请求数”（RPM）往往设置得非常高，足以让一个僵尸网络在你喝完第一杯咖啡之前就掏空一家初创公司的银行账户。

再加上绑定了一张高额度的公司信用卡，整个系统只是忠实地执行了指令：无限扩展。

“绝不再犯”防护体系：我们的四步缓解方案

谷歌客服表示，鉴于这是首次发生此类事件，他们可能会考虑退款，但前提是必须提交一份严谨的整改方案。以下就是我们实施的“金库级”防护措施，确保此类错误永不再现。

1. 实时可观测性（Datadog集成）

标准的计费警报是被动式的——它们只能告诉你已经花掉的钱。我们需要知道的是此刻正在花多少钱。

• 我们集成了Datadog，直接从GCP日志中监控每秒请求数（RPS）和每秒事务数（TPS）。
• 熔断警报：如果Gemini请求量在10分钟移动平均值基础上激增200%，Datadog会立即触发PagerDuty警报。我们再也不用等到收到计费邮件才采取行动。

2. 迁移至服务账号（IAM优于API密钥）

裸露的API密钥是巨大的安全隐患。我们正在将所有工作负载迁移至GCP服务账号。

• 我们不再使用可能被泄露的静态字符串，而是采用短期有效的令牌和IAM角色。
• 本地开发：开发人员现在必须使用gcloud auth application-default login命令进行身份验证，而不能再生成永久性、易受攻击的密钥。

3. 设置硬性配额

免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。