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

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

我们做了每个快速推进的团队都会做的事：绑定了公司信用卡，获取了一个API密钥，然后开始开发。20天后，我们收到了一张3.5万美元的账单，一位惊慌失措的首席执行官，以及一堂代价高昂的课程——关于GCP默认配额和计费延迟机制的惨痛教训。

如果你正在“仅仅做实验”地使用人工智能API，请在醒来发现账单变成五位数之前，先读完本文。

“完美风暴”时间线

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

• 美国东部时间凌晨3点：一个未设限制的API密钥被泄露（很可能是通过被攻破的开发环境）。一个自动化僵尸网络开始疯狂攻击我们的Gemini 3.1 Pro图像接口。
• 美国东部时间上午8点：我们的首席执行官收到一条自动计费警报：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. 设置硬性配额

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