AWS无预警删除我十年账号及全部数据

一位拥有十年历史的 AWS 用户，其账户及所有数据因一次内部错误而被无预警删除，并经历了一场长达 20 天的噩梦般的支持体验。尽管该用户遵循了多区域复制和备份等最佳实践，但 AWS MENA 的一次“验证失败”导致其数据被立即清除，完全无视了官方文档中承诺的 90 天保留期。一个可能的解释是，AWS MENA 的内部测试工具在参数解析上出现失误（将--dry误读为-dry），导致在生产环境中执行了真实的删除操作。这一事件不仅摧毁了该用户的开发环境和未发表的作品，也揭示了将数据完全托付给单一云服务商的巨大风险。

本应万无一失的架构

许多人可能会说“你不该把所有鸡蛋放在一个篮子里”，但事实并非如此。我把它们放在了一个供应商那里，但采用了本应是万无一失的冗余措施：

    • 多区域复制：数据同步复制到与美国基础设施完全隔离的 AWS 欧洲区域。
    • 灾难恢复：实施了“死亡开关”以应对突发状况。
    • 合规备份：遵循 AWS 官方的最佳实践来构建备份架构。
    • 密钥隔离：将加密密钥与数据分开存放。

我唯一没有预料到的情况是：AWS 本身成为了那个导致灭绝的事件。

十年来，AWS 一直是我的试验场，用于验证我维护的 Ruby gems（如 capistrano-puma）的部署。就在我生日那天，AWS 送了我一份大礼：证明了当供应商本身失控时，再多的冗余也毫无意义。

20 天的噩梦：一场与客服的拉锯战

    • 7月10日: AWS 发送验证请求，限期5天（包含周末）。
    • 7月14日: 表格过期，我联系客服，只问了一个简单问题：“我需要提供什么？”
    • 7月16日-20日: 四天的沉默，然后得到回复：“我们正在上报给相应团队。”
    • 7月21日: 我提交了身份证和水电费账单的清晰 PDF 文件。
    • 7月22日: AWS 回复：“文件无法读取。” 而我的银行却能毫无问题地接受同一个 PDF。
    • 7月23日: 账户被终止。这是我收到的生日礼物。
    • 7月24日: 我问了唯一重要的问题：“我的数据还存在吗？” AWS 的回复是：“您的案例正在由我们的服务团队审核。”

在我请求临时只读权限以备份数据时，他们拒绝了。这让我怀疑，数据可能早已不复存在。

我：“我的数据安全吗？是或不是？”

AWS：“我想亲自跟进您的案例，并告知您我们理解此事的紧迫性。”

在他们最终承认数据已被删除后，收到的最后一封邮件竟然还包含一个请求：

AWS：“我们重视您的反馈。请通过评价本次通信来分享您的体验。” ⭐⭐⭐⭐⭐

承诺与现实的鸿沟

AWS 的官方文档明确指出，账户关闭后有 90 天的保留期，在此期间可以重开账户并恢复数据。然而，我的账户并非自愿关闭，而是因“验证失败”被暂停——这是一个官方文档中未提及的政策灰色地带。没有任何公开条款说明，因验证失败而暂停的账户会绕过 90 天的保留期。

行业标准是 30-90 天的数据保留期，除非涉及欺诈或滥用。AWS 的做法是：零天，零小时，毫不留情。

真正的导火索是什么？

AWS 将问题归咎于一个“第三方付款人”。一位曾为我支付账单的 AWS 顾问因 FTX 崩盘而消失。我指出我的账户上一直绑定着自己的 Wise 银行卡，并要求切换回来，但 AWS 以“隐私”为由拒绝了长达 20 天。

然而，这根本不是支付问题。如果是，他们本可以：

    • 将账单切换到我备用的信用卡。
    • 暂停服务，而不是直接删除数据。
    • 提供他们自己承诺的 90 天宽限期。

他们只是利用付款人问题，来掩盖内部测试失误的真相。

被摧毁的不仅仅是数据

AWS 不仅是我的备份，更是我进行开源开发的“洁净室”。我通过将代码复制到 AWS，从零开始，只取回必要部分，创造出了整洁、专注的 gems。这个工作流程诞生了许多项目，包括：

    • BreakerMachines: 用于 Ruby 的熔断器模式。
    • ChronoMachines: 基于时间的状态机。
    • RailsLens: Rails 性能监控工具。

这些工具为全球开发者节省了成千上万小时的工作量。但现在，这一切都被摧毁了。同时消失的还有：

    • 一本完整的编程书籍。
    • 连接硬件和软件的电子教程。
    • 帮助 Ruby 开发者转向 Go 的课程。
    • 多年来未发表、本可以帮助数千人的作品。

讽刺的是，我开发的某些 gems 可能就运行在 AWS 自己的基础设施中，而他们却摧毁了创造这些工具的环境。

一个内部人士的猜测：--dry vs -dry

一位即将离开 AWS 的内部人士联系了我，他透露 AWS MENA（中东和北非）区域正在对“休眠”和“低活跃度”账户进行某种概念验证测试。问题可能出在一个简单的技术失误上。

运行测试的开发人员可能输入了 ruby --version 或 terraform --dry-run 中常见的 --dry 参数，意图进行一次模拟运行。但他们内部的工具是用 Java 编写的，而 Java 的参数格式是单破折号，如 java -version。

当一个期望 -dry 的 Java 程序接收到 --dry 时，它会忽略这个参数。结果，本应是模拟的脚本在生产环境中真实地执行了，删除了包括我在内的多个账户。

这个理论解释了为什么多个“低活跃度”账户突然被标记，以及为什么客服在长达四天的时间里支支吾吾，无法给出明确答复——他们可能在忙着掩盖这个巨大的失误。

这对你意味着什么

你可能认为这种事不会发生在你身上，但你并非被“针对”，而是被“算法分类”。如果算法判定你是可抛弃的，你就消失了。

    • 你的贡献无关紧要：无论你是不是知名的开源贡献者。
    • 你的忠诚度毫无价值：即使你已是十年的老客户。
    • 你的行为模式可能被误判：如果你的使用习惯对于一个训练不足的机器学习模型来说显得“可疑”，你就会被当作一个需要被“优化”掉的数据点。

我的技术写作风格甚至能让一些 AI 模型（如 Opus）的防护机制触发并宕机。如果我的文字都能迷惑 AI，想象一下 AWS 的“欺诈检测”算法在看到我的账户时会怎么想？一个异常，一个不匹配的模式，一个需要被清除的东西。

唯一的出路：打破信任

AWS 最终的回应是：“由于验证未在截止日期前完成，您账户上的资源已被终止。”

这暴露了一个根本性的问题：当云服务本身成为最薄弱的环节时，所有的安全最佳实践都将失效。我建立了一个坚固的堡垒，却被 AWS 自己从内部引爆了。

他们的沟通策略似乎在说：“他是个无名小卒，很快就会放弃，我们就不必向上级汇报了。”

但我不会放弃。我正在构建一个免费工具，帮助人们从 AWS “出埃及”。我的客户们（每月在 AWS 上花费超过 40 万美元）已经同意迁移到 Oracle OCI、Azure 和 Google Cloud。

因为，如果 AWS 能毫不犹豫地删除一个十年老客户的数据，当赌注更高时，他们又会做出什么？

核心教训

    • 永远不要信任单一供应商，无论你在多少个区域进行复制。
    • 当供应商本身出问题时，“最佳实践”毫无意义。
    • 记录一切，包括截图、邮件和通信时间戳。
    • 准备好一个能在几小时内执行的退出策略。

云不是你的朋友，它是一门生意。当他们的商业需求与你数据的存在发生冲突时，猜猜谁会赢？请做好相应的计划。