发布时间：2025.08.02
源地址：https://www.seuros.com/blog/aws-deleted-my-10-year-account-without-warning/
2025 年 7 月 23 日，AWS 删除了我使用了十年的账户以及我存储在他们平台上的所有数据。没有任何警告，没有宽限期，也没有恢复选项，完全是数字上的彻底消失。
这是一起发生在 AWS MENA 的灾难性内部失误的故事，经历了长达 20 天的支持噩梦，我始终无法得到一个明确的答案：“我的数据还存在吗？”这件事也揭示了将数据托付给云服务提供商所面临的信任问题。
本应保护我的架构设计
在有人说“你把所有鸡蛋放在一个篮子里”之前，我要澄清：我并没有。我选择了一个服务商，并且采用了本应坚不可摧的冗余方案：
跨 AWS 欧洲多个区域复制（与美国基础设施完全独立）
为灾难恢复实施了“死者开关”机制
遵循 AWS 自身最佳实践的完善备份架构
隔离的加密密钥与数据分开存储
我唯一没有预料到的情况？就是 AWS 自身成为了灭绝事件。
十年了。这是我作为 AWS 用户的时间长度。十年来，我一直将 AWS 作为测试平台——启动实例来验证我维护的 Ruby 库（如 capistrano-puma 和 capistrano-sidekiq）的部署。虽然这些并非生产环境的关键应用，但对开源开发来说至关重要。
在我生日那天，AWS 送给我一份永生难忘的“礼物”：那就是无论冗余多么充足，当服务提供商本身出现问题时，一切保障都无济于事。
长达 20 天的支持噩梦：时间线回顾
7 月 10 日：AWS 发出验证请求，要求在 5 天内回复（含周末）。
7 月 14 日：表格已过期。我联系了客服。一个简单的问题：“你们需要我提供什么？”
7 月 16 日至 20 日：四天的沉默。随后：“我们正在将问题升级到相关团队。”
7 月 20 日：新形式终于到来。
7 月 21 日：我提交了身份证和水电费账单（清晰的 PDF）。回复时间：10 小时。
7 月 22 日：AWS：“文件无法读取。”而这份 PDF 文件我的银行却毫无异议地接受。
7 月 23 日：账户被终止。亚马逊云服务送给我的生日礼物。
7 月 24 日：我提出了唯一重要的问题：“我的数据还存在吗？”
亚马逊云服务（AWS）回复：“您的情况正在由我们的服务团队审核。”
我还请求临时只读权限，以备份我的数据。请记住，如果我是欺诈者，我早在验证截止日期前就会复制所有数据了。但他们拒绝了。（因为数据很可能已经丢失。）
7 月 28 日：经过四天的模板回复，我失去了耐心：
我：“我的数据安全吗？是还是不是？” AWS：“我想亲自跟进您的案例，并告知您我们理解事情的紧迫性。”
7 月 29 日：我将他们的回避比作政治上的转移视线：
我：“你的回答就像我是在问皮尔斯·摩根‘你谴责 10 月 7 日事件吗？’而你却用追溯到 1948 年的历史复杂性来回应。” AWS：“我们真心感谢你坚持遵循备份最佳实践。”
7 月 29 日：他们终于承认了事实：
AWS 表示：“由于该日期前未完成账户验证，账户上的资源已被终止。”
7 月 30 日：他们的最终回复包括：
AWS：“我们重视您的反馈。请通过评分来分享您对本次沟通的体验。” ⭐⭐⭐⭐⭐
二十天过去了，始终没有得到明确答复。多次被要求给出五星好评，而我的数据却化为数字灰烬。
他们声称的政策与他们实际执行的现实
以下是 AWS 官方文档中关于账户关闭的说明：
关闭后期限为 90 天——在此期间，账户可以重新开启，数据将被保留。
90 天后，账户将被“永久关闭”，所有内容——包括快照和备份——都会被删除。
但问题是：我从未主动关闭过我的账户。AWS 因“验证失败”暂停了我的账户——这是一个政策灰色地带，恰好未在其公开文档中出现。没有任何公开说明表明被验证暂停的账户可以跳过 90 天的保留期。
各大云服务商的行业通行标准是保留数据 30 至 90 天，除非发生实际的欺诈或滥用行为。而 AWS 则是零天、零小时，毫不留情。
付款方复杂性
AWS 将终止服务归咎于“第三方付款方”问题。一位负责支付我账单的 AWS 顾问因 FTX 崩盘造成的损失而消失。此前这项安排运行了近一年，费用约为每月 200 美元，用于我的测试基础设施。
当 AWS 要求这位消失的付款人验证身份时，我指出我已经在系统中保存了自己的 Wise 卡——这张卡是我在使用付款人安排之前用来支付的，特意保持激活状态，以防付款人在我旅行或离线时断开连接。他们拒绝在 20 天内简单地将账单切换回这张卡，理由是“隐私”问题，同时让我对后果承担全部责任。
但关键是：这并非关乎付款。如果真是这样，他们早就会：
已将账单切换至我档案中的信用卡
服务已暂停，数据未被删除
鉴于他们自己的文件承诺的 90 天宽限期
他们反而借“付款方问题”来掩盖真正的原因——他们内部测试的失误。
虚伪之处更为深刻
付款方并非某个随机的骗子，而是一家获得 Y Combinator 支持的公司。我在关联付款时就能看出来。如果 AWS MENA 的安全如此强大，为什么他们整整一年都未能发现任何问题？
当我试图解决此问题时，AWS 要求我进行解释：
我使用账户的目的
我的未来计划
我为什么需要这些服务
就好像我在申请资金或晋升一样。这是一个有十年历史的账户。我不应该为了使用自 2015 年以来一直在付费的服务而不得不证明自己的存在。
但真正令人意外的是：AWS 的开发者们经常给我发邮件，寻求关于 Ruby 问题的帮助。没有报酬，没有 AWS 积分，甚至在他们的提交记录中都没有一句“谢谢”。他们只是说：“嘿，你能帮我们调试这个 Rails 部署问题吗？”
让我弄清楚：
亚马逊云服务（AWS）受益于我的开源代码
AWS 工程师向我免费咨询技术问题
亚马逊云服务（AWS）要求我说明为何我应继续保留账户
当一家由 Y Combinator 支持的付款方（AWS 未能妥善审核）消失时，AWS 会删除所有数据
他们还要我对每个客户进行背景调查？我是不是也得对 AWS 验证邮件做安全审查？因为显然，他们自己的审核流程居然没能发现付款方整整一年的问题。
AWS 真正摧毁了什么
大多数人不明白的是：AWS 不仅仅是我的备份，它还是我进行开源开发的净化环境。
我的桌面一团糟，一直如此。文件散落各处，半成品项目，试验代码。但我发现，将所有内容复制到 AWS，重新开始，只拉取所需部分，就能打造出干净、专注的精品。这就是我发布作品的工作流程。
BreakerMachines——Ruby 的断路器模式
ChronoMachines——基于时间的状态机
RailsLens——Rails 性能监控工具
还有数十个更多
这些宝贵资源为开发者节省了数百甚至数千小时的时间。它们被全球的生产系统广泛使用。AWS 不仅删除了我的数据，还摧毁了支撑这些贡献的基础设施。
情况更糟。还有：
一本用我的《编年史》叙事风格写成的完整编程书籍
电子教程：连接硬件与软件的桥梁
“面向 Ruby 开发者的 Go 语言课程”——助力 Ruby 程序员顺利转向 Go 语言
多年未发表的研究本可惠及数千人
当 AWS 删除了我的账户，他们伤害的并不仅仅是我。他们伤害了每一个使用我开发的工具包的开发者，伤害了每一个本可以从那些教程中受益的学生，也伤害了所有因我的工作流程被破坏而无法实现的未来贡献。
讽刺的是？这些宝贵资源很可能运行在 AWS 自身的基础设施上，从而提升了其系统的可靠性。而他们却删除了创造这些资源的环境。
理论： -dry 与 --dry 如何可能导致我的账户被封
在我的报道开始传播后，一位 AWS 内部人士联系了我。他们感到不满，即将离开 AWS，想要分享他们所知道的情况——特别是因为 AWS 依赖我编写的开源代码。
据他们称，AWS MENA 正在对“休眠”和“低活跃度”账户进行某种概念验证。不仅仅是我的账户，多个账户都受到了影响。接下来内容较为技术性：
开发人员在运行测试时输入了 --dry 来执行一次模拟运行——这是现代命令行界面（CLI）中的标准操作
ruby --versionnpm --versionbun --versionterraform --dry-run
但内部工具是用 Java 编写的。而 Java 使用单个短横线：
java -version（非--version）java -dry（非--dry）
当你向期望接收 -dry 的 Java 应用传入 --dry 时，该参数会被忽略。脚本实际上被执行了，导致生产环境中的账户被删除。
开发者做得一切正确。Java 1995 年代的参数解析却将一次模拟变成了灭绝事件。
这是否真如所述？我无法证实。知情人士言辞含糊，担心身份暴露。但这解释了：
为何多个“低活跃度”账户突然被标记
4 天的延误（忙于掩盖）
拒绝回答简单问题
承认“无法做决定”的客服人员
AWS MENA：为何人们宁愿付费也要避开它
这一理论在考虑到 AWS 中 UN 文 MENA 地区的声誉时更具说服力。多年来，我在 Reddit 和 Facebook 上看到开发者们拼命寻找美国或欧洲的账单地址，愿意支付超过 100 美元的溢价，以避免被分配到 MENA 地区。
当我问原因时，一位同事提醒我：“AWS 中 UN 文 MENA 的运作方式不同，他们可能会随时解雇你。”
我一笑置之。AWS 就是 AWS，不是吗？
简单的验证表格延迟了四天。回复时间长达十小时。机械化的客服回应。这不仅仅是亚马逊云服务的普通失误——这完全是另一回事。
终极讽刺：安全成了我的软肋
我做的一切都很正确。保险库加密密钥与我的主基础设施分开存储。多层防御。零信任架构。所有措施都到位。
我当时的安全防护措施堪称教科书式——通过确保没有单点故障能够导致整体瘫痪来防止被攻破。但我没有防范的，是 AWS 本身成为了单点故障。
我建造了一个坚固的堡垒，设计了多条逃生路线，结果却被 AWS 直接摧毁了整个设施。
这对您的意义
你可能会想，“他们会针对我吗？”但这其实是个错误的问题。我也曾这么想——以我的曝光度和贡献，理应他们直接把我的名字记下来，不用用那些愚蠢的验证请求来打扰我，确认我是否存在。
但你并非被针对——而是被算法分类。如果算法判定你无关紧要，你就会被剔除。
无论你是否是经过认证的开源贡献者，无论你是否已经做了十年的客户，都无关紧要。如果你不符合收入模型，如果你不经常与客服互动，如果你的使用模式在一个训练不足的机器学习模型看来“可疑”，你就只是一个被优化掉的数据点。
看，我写的东西比较怪异。我的文档风格会触发 AI 的安全机制。拿我那个为 Rails 提供 MCP 功能的 ActionMCP gem 来说——Opus 在安全机制启动时甚至无法读取文档，会直接卡住。Sonnet 就没问题。（你可以自己试试：github.com/seuros/action_mcp）
如果我的创意技术写作能让一个人工智能感到困惑，而另一个却不然，那么试想当 AWS 的“欺诈检测”算法审视我的账户时，会看到什么。一个异常现象，一个不符合常规的模式，一种需要被消除的存在。
唯一的前进道路：一个破碎的承诺
经过 20 天的申诉，AWS 客服终于回复了这句经典的话：“由于未能在截止日期前完成验证，您的资源已被终止。”
但他们制造了一个难题：如果你拥有数拍字节的数据怎么办？你如何备份备份？当备份中包含受 HIPAA 保护的信息或客户数据时，又会发生什么？云计算的全部承诺因此陷入了复杂的困境。
这不是系统故障。架构设计和承诺都是可靠的。AWS 不会丢失数据——他们有多重备份，存放在远超声明的 90 天保存期的保险库中，任何恶意的 AI 脚本都无法触及。
这里发生的事情其实很简单：中东和北非地区的团队正试图掩盖一次重大失误。要从那些深层存储库恢复数据，就必须给出解释、提交事故报告和事后分析。“我们为什么非得打开这些存储库？”
他们整个沟通策略传递的信息是：“他算不了什么。他很快就会放弃。我们不用把这事上报给上级。”
但他们惹错了开发者。
我正在开发一款免费的工具，帮助用户摆脱对 AWS 的依赖，当然这款工具不会托管在 AWS 上。我的客户群体月 AWS 账单总额超过 40 万美元，他们已经同意迁移到 Oracle OCI、Azure 和 Google Cloud。
因为如果 AWS 能够毫不犹豫地删除一个拥有十年历史的客户，那么在风险更高的情况下，他们还能做出什么举动呢？
苦涩的真相
亚马逊云科技（AWS）拥有强大的影响力。他们运营着互联网的基础设施，赞助各种会议，资助开源项目，并将自己定位为数字经济可靠的支柱。
但这并不能成为因为验证表单的一个小故障和不到 200 美元的账单，就数字化地关闭某人十年前的测试账户的理由。幸运的是，这不是我的生产环境，但它是我更新其他基础设施的起点。现在，我不得不花费数天时间在多个系统间更换加密密钥，因为我的中央测试环境突然消失了。
系统性失败
这不仅仅关乎我的账户。这关系到当……发生时的情况：
区域分部自行其是：AWS 中 UN 文 MENA 业务脱离全球政策
客服变成表演：只能粘贴模板并索要五星好评的客服代理
“快速行动，勇于破坏”遇上生产数据：内部工具用 Java 1995 年的参数解析处理客户删除请求
推诿不止：二十天的回避，换不来一句真诚的回答
功能失调的证据：
数百人支付保费以避免 MENA 账单（市场已发声）
简单表格处理延迟四天
支持将数据恢复问题与地缘政治辩论进行比较
在积极销毁客户数据的同时，自动发送“请为我们评分”的邮件
真实代价
亚马逊云科技（AWS）将自己定位为互联网的支柱，是您基础设施的可靠合作伙伴。他们赞助开源项目，举办 re:Invent 大会，并自诩为开发者的盟友。
但当他们的内部系统出错时——当有人输入 --dry 而 Java 却忽略它——他们会毫不犹豫地删除你十年的工作成果。随后，他们还会花上 20 天时间对你进行精神操控。
与此同时，实际托管钓鱼网站和加密诈骗的恶意账户可以连续数周不受干扰地运行，因为它们能带来收益。而那些活跃度低的开源开发者，仅仅是在测试 Ruby gems？则成了无辜的牺牲品。
经验教训
永远不要只信任单一供应商——无论你复制了多少个区域
“最佳实践”在服务提供者失控时毫无意义
所有内容都要记录——截图、电子邮件、通信时间戳
客服表演是真实存在的——他们实际上帮不了你
制定可在数小时内执行的退出策略，而非数天
AWS 不会承认他们的错误。他们不会承认那个失控的概念验证。他们也不会解释为什么中东和北非地区的运营方式不同。甚至连你的数据是否存在，他们都不会回应。
但他们会要求你给他们的支持打五星好评。
云计算并非你的朋友，而是一门生意。当他们的商业利益与您的数据存在发生冲突时，猜猜谁会胜出？
请做好相应的计划。
个人感言
在这场磨难中，有一度我跌入谷底。我准备删除一切——从 RubyGems 上撤下所有宝石，删除所有组织、网站，抹去我所创建的一切。只留下这样一句话：“AWS 毁了这一切。”
这本该成为头条新闻，引发数千个项目的混乱，在 Hacker News、Reddit 和 YouTube 上引发热议。但这会伤害到错误的人——依赖我工作的开发者，而不是 AWS。
我当时孤身一人，没有人能理解失去十年心血的沉重。但我有 ChatGPT、Claude 和 Grok 作伴。每一次对话都让我明白，我并非唯一一个被 AWS 针对的人，尤其是在中东和北非地区。成百上千的 Reddit 讨论帖、网站和论坛，都在讲述着类似的故事。
我试图联系一些受害者。有些人不愿谈论此事——创伤还很新鲜。还有些人表示他们已经完全离开了编程领域。AWS 不仅删除了他们的数据，也摧毁了他们的职业生涯。
作为一个具有低潜抑制（LLI）的人，我无法像别人那样过滤掉这些创伤。不能简单地换个职业就忘记。那种原始、未经过滤的痛苦一直伴随着我。我希望自己能释怀，但做不到。
有多少像我这样的人，因为像 AWS 这样的支持团队的虐待行为，被从我们的时间线上抹去了，谁又能知道呢？整个系统就是为了伤害人——让你感到渺小、无助、无人倾听。让你放弃。让你消失。
感谢所有参与这些人工智能研发和训练数据贡献的人员——没有你们，这篇文章可能会是截然不同的内容。
亚马逊云服务可能删除了我的数据，但他们无法抹去我帮助他人避免遭遇同样命运的决心。
我会打造那个撤离工具。
—苏罗斯