AWS 的蜜月期已结束：云复杂性与供应商锁定案例研究

对于许多早期采用者来说，Amazon Web Services (AWS) 不仅仅是一场革命。能够在几分钟内启动服务器、存储和队列——而无需承担物理数据中心的开销——对于初创公司和独立开发者来说是一个游戏规则改变者。但对某些人来说，与这家云巨头的关系已经恶化。

最初表现为快速扩展和便利性的蜜月阶段，往往会演变成一种复杂的、对抗性的关系，其特征是“计费陷阱 (billing footguns)”、“不透明的安全协议”以及压倒性的管理开销。这种转变不仅仅关乎成本；它关乎托管服务带来的便利性与拥有自主基础设施之间的根本张力。

信任的侵蚀：从粉丝到怀疑论者

在中断一段时间后重新回到 AWS，通常会让人深刻意识到为什么许多开发者会离开。从“铁杆信徒”到怀疑论者的转变通常是渐进式的。它始于一些细微的烦恼——比如 Python 3 的缓慢采用或对社区驱动的客户端库的依赖——并最终在意识到平台的复杂性已成为负担而非益处时达到顶峰。

长期用户的经验中出现了几个反复出现的痛点：

复杂性陷阱： 像 IAM (Identity and Access Management) 这样的服务经常被指责极其复杂。虽然有人认为对于企业规模来说，细粒度的安全是必要的，但对许多人来说，这感觉像是过度工程，需要专门的专家团队来管理。
不透明的计费： “狡猾且复杂的计费”是一个常见的抱怨。用户报告称，在同一系统内的数据移动会被收取费用，存在重复或三重计费的情况，还有臭名昭著的数据流出 (data egress) 成本（历史上大约为每 GB 9 美分）。
托管服务的悖论： 虽然像 AWS Lambda 这样的服务承诺了可扩展性和零维护，但它们可能会引入显著的供应商锁定。从无服务器架构迁移出去所需的努力通常远大于维护传统 Web 服务器的努力。

云体验中最直观的例子之一是账户停用的随意性。在一个有记录的案例中，一个休眠账户突然为了研究目的启动了一个高核心数的 EC2 实例，结果被标记为“疑似安全违规”。

这引发了一连串的失败：业务电子邮件 (WorkMail) 被切断，支持响应被延迟了数天。这突显了云模型中的一个关键脆弱性：当你将核心基础设施外包给单一供应商时，一个自动化的安全标记可能会瘫痪你的整个业务运营。

社区对于“云”是否仍然是大多数人的正确选择仍存在分歧。

一些开发者认为，复杂性是换取核心服务可靠性和成熟度的公平交易。

"AWS 的核心服务集仍然很棒：EC2, S3, IAM, EKS, Route53, RDS 等... 每次我尝试使用其他供应商提供的、据称可以替代这些服务的酷炫新功能时——我都能理解 AWS 的服务是多么成熟且完善。"

其他人指出，对于小规模项目，如果保持在免费额度内，像 Lambda 这样的无服务器选项可能比最便宜的 VPS 还便宜。

相反，一种向“回归 (repatriation)”的趋势正在增长——将工作负载迁移回本地服务器或托管中心。其论点主要基于经济和性能：

成本效率： 用户报告称，通过将托管服务（如 GCP's Datastore 或 AWS's ElastiCache）替换为在专用硬件上自管理的 Postgres, Mongo, 和 Redis，每月账单从数千美元降至几百美元。
性能： 一些开发者指出，云端 CPU 可能会感觉很慢，且 EBS (Elastic Block Store) 卷引入了对于高性能工作负载而言无法接受的延迟。
自主权： 远离云端可以消除账户被随意停用的风险，以及云供应商“掠夺性”地克隆开源项目的行为（例如，创建 OpenSearch 和 DocumentDB）。

云的诱惑在于“阻力最小路径”的便利性。然而，正如原贴作者所建议的那样，这条路径可能会导致陷阱。陷阱要么是提取“免费”数据提取的难度，要么是管理一个庞大且半成品的生态系统所带来的复杂性，便利的成本往往伴随着对自主权和理智的隐形税收。

对于现代开发者来说，目标可能不是完全撤离云端，但可以进行战略性多元化：将云用于它最擅用的长处（如用于备份的 S3 或用于 DNS 的 Route53），同时将核心计算和数据保留在他们真正控制的基础设施上。