我重返 AWS，想起了当初离开的原因

# 我重返 AWS——并再次被狠狠提醒当初为何离开 来源：http://fourlightyears.blogspot.com/2026/05/i-returned-to-aws-and-was-reminded-hard.html 早在 AWS 刚刚诞生之际，我便是其最早的拥趸之一——那时只有 SQS、S3、EC2 和 SimpleDB，规模远比现在小得多。事实上，当 AWS 代表从美国飞来布道时，我还组织墨尔本举办了首届 AWS 活动。 云计算是一场令人头脑风暴的革命——突然间，初创公司可以在几分钟内运行自己的计算机系统，而无需在数据中心自行安装和维护硬件。这绝对是颠覆性的变革。当时我对 AWS 深信不疑，彻底沉浸其中，毫无保留地投入了全部热情。 在大约 15 年的时间里，我一直是 AWS 的超级粉丝——一个真正的“真信徒”——对 AWS 毫无保留。 但关系的破裂往往是渐进的——起初只有一两件事让你感到困扰，**你总体上依然热爱它**，虽然承认这里那里存在一些小缺点。不过没关系！它依然非常棒，你依然喜欢它，对吧？但你开始注意到越来越多不对劲、不喜欢、损坏或糟糕的地方。直到某天，最后一根稻草出现，天平彻底倾斜，你突然意识到——**“我不再爱这段关系了”**。 以下是随着时间推移逐渐侵蚀我信任的一些因素： - 在 AWS 存在的头六年里，它竟然没有构建自己的客户端库，而是将这项工作留给“我们优秀的社区”，让社区为 Python 等语言实现客户端库。AWS 很乐意让程序员牺牲周末和夜晚，免费编写软件来惠及 AWS。 - AWS 在从 Python 2 迁移到 Python 3 的过程中耗费了荒谬长的时间，这让我非常恼火。 - DynamoDB——我讨厌的软件不多，但天哪，DynamoDB 简直是一堆令人抓狂的垃圾。我尝试使用后，当天结束时收到了一张 75 美元的账单。这不仅仅是成本问题，它在各方面都是我所能想象到的最糟糕的系统。 - 每千兆字节 20 美分的出站流量费——天哪，你有多清楚这有多昂贵吗？虽然随着时间的推移降到了每千兆字节 9 美分，但这依然贵得离谱。这他妈的简直贵得发指。如果你使用 AWS，且每千兆字节 9 美分的出站流量费没有时刻挂在心上，那么请在镜子前照照——那个傻瓜就是你。 - 疯狂而隐蔽的复杂计费方式：他们因数据在其系统内部的移动而收费，甚至双重或三重计费。计费陷阱和地雷无处不在，你必须成为资深专家才能避开它们。 - IAM——这套令人望而生畏的复杂认证和访问规则系统，仿佛是路西法坐在第九层地狱燃烧的王座上，为那些因使用 AWS 而被打入地狱的人设计的终极折磨。 - 无处不在的复杂性——一旦我注意到了 IAM 的复杂性，我就再也无法无视 AWS 中其他地方的复杂性了。最奇怪的是，AWS 的“真信徒”们声称：“你必须使用 AWS，因为自行运行计算机系统、Linux、硬件网络和安全措施过于复杂。”这些真信徒对自己视而不见，忽略了 AWS 中几乎*所有*事情令人难以置信的巨大复杂性。AWS 复杂得离谱，你需要雇佣一支昂贵的专家团队才能运转起来。 - AWS Lambda——是的，我曾真的相信它的营销说辞——“它是可扩展的！！！”，而我忽视了其缓慢的启动时间和*巨大*的开发复杂性。与自行运行 Web 服务器相比，AWS Lambda 并没有真正的优势，反而有诸多缺点。当我最终离开 AWS 时，最难处理的就是 AWS Lambda 相关的问题。厂商锁定是真实存在的。如果你使用 AWS Lambda，你就不得不不断说服自己这比自己的 Web 服务器更好。不断说服自己使用 AWS Lambda 不是一个可怕的错误。 - AWS 打压开源项目——尽管 Elasticsearch、Redis 和 MongoDB 等项目明确表示不希望被克隆并商业化，AWS 依然强行推出了 OpenSearch、Valkey 和 DocumentDB，在那些社区和公司建立市场后攫取了托管服务的利润；其结果是出现了一波诸如 SSPL、Elastic License、RSAL 及其他“源代码可用”模式的防御性许可证，这些许可证设计的目的与其说是要阻止普通用户，不如说是要阻止 AWS 拆解开源基础设施、垄断客户关系。AWS 是一个掠食者。 - 还有很多很多讨厌 AWS 的理由，但我不甚至不想思考 AWS，所以我不想通过多想一些讨厌 AWS 的理由来毁掉我的早晨。 关系的破裂是缓慢的，直到突然意识到一切都结束了——这正是我对 AWS 的感情发生的变化。有一天，我的开关突然翻转，我瞬间从粉丝变成了讨厌者。我将所有内容从 AWS 迁移出去，并关闭了除一个之外的所有账户。我在 AWS 上保留了一点内容，因为它对我来说确实是合适的解决方案——我将在 Route53 上保留我的域名，在 S3 上保留一些备份，并继续使用 AWS WorkMail（他们刚刚通知我将在 12 个月内停止服务）。 最近，我又回到了 AWS。什么？！？！？为什么？你可能会问。为了进行一些研究。做几个测试，进去又出来。 我想看看 Claude/Anthropic 在 AWS Bedrock 上的表现如何（Claude Code 的工作原理相同，但速度较慢，而且比直接订阅 Anthropic 贵得多，贵得多）。 我想在一台超级快的机器上对我的代码进行基准测试——我家里最快的机器是一台 20 核心、32GB 内存的机器，我想看看我的代码在一台 192 核心、1TB 内存的机器上能运行得有多快。 所以我在大约一个月前登录了我的 AWS 账户并进行了 AWS Bedrock 测试——当时没有问题。完成测试后我关闭了所有服务——我不打算再在 AWS Bedrock 上使用 Claude 了——如果你需要隐私保护，它确实不错，但天哪，成本太高了。 最近我再次登录，启动了一个 192 核心的 EC2 Spot 实例，测试了大约 3 小时后，我收到了一封来自 AWS 的邮件：“疑似您的账户发生安全漏洞”。 在 AWS 深处的某个地方，某种安全警报被触发了，可能是因为我的这个几乎休眠的账户突然开始在一台昂贵的计算机上运行任务。我理解他们为什么要这样做——这是一件好事——AWS 想要保护其用户。我对此表示赞赏。 **但是**他们暂停/限制了我的账户。 现在我的 AWS WorkMail——我的主要商业账户——无法正常工作——任何人都无法再发送电子邮件。 我无法创建任何类型的 AWS 资源，无法完成我试图进行的测试。 我回复了他们的支持通知，询问为何暂停我的账户，并告诉他们账户并未被黑客攻击，没有问题，也没有账单异常。没有回复。 当然，我没有购买高级支持，所以我必须等待他们所说的 24 小时回复时间。现在已经过去 3 天了，AWS 支持团队仍未回复。 于是我在 AWS 论坛上发帖，恳求有人回应——有人说“专注于执行邮件中指示的操作，然后使用聊天功能而不是网页提交，因为他们实际上会回复聊天”。好吧。我照做了——我做了他们要求的一切——更改密码、撤销访问令牌、检查账单等，然后在等待半小时后与 AWS 代表进行了一次长时间的聊天。最后那位代表似乎满意了，他说他会让内部处理此类事务的人员跟进。那是 24 小时前的事了。我在 8 小时后跟进询问何时解除账户暂停，他们回复说“请耐心等待”。 所以，在账户被暂停的第四天，我依然想在大机器上进行测试。我 dread（害怕）不得不“申请配额”才能被允许这样做。我的商业邮件系统仍然无法工作。 这提醒了我当初为何离开 AWS，以及我需要完成剩下的工作：彻底离开 AWS WorkMail，将域名从 Route53 迁移出去，并且永不回头。 我很庆幸多年前就离开了 AWS，遗憾的是，这次重返 AWS 竟导致了我留在 AWS 上的邮件系统崩溃，真是愚蠢的信任。俗话说，被骗一次是别人的错，被骗两次是自己的错。 也许有一天，他们最终会解除对我账户的暂停。