一位在 AWS 早期就为其摇旗呐喊的工程师，15 年后因研究需求重返 AWS，却在四天内经历了账号封禁、业务中断与无尽等待。本文记录这段真实的踩坑经历，并从中提炼出可供工程团队参考的决策框架与风险规避策略。
从狂热到疏离：一位 AWS 老兵的心路
Andrew Stuart 是墨尔本最早接触 AWS 的工程师之一，甚至组织过该地区首场 AWS 活动，亲眼见证了云计算如何让初创公司跳过数据中心建设、在几分钟内拥有完整的基础设施。这段经历让他成为持续约 15 年的「真信徒」，AWS 的每一项新服务他几乎都第一时间尝鲜。
关系的崩塌总是渐进的。Stuart 在博客中列举了那些逐渐消磨热情的细节：AWS 在最初六年里不提供官方客户端库，而是让社区志愿者免费编写 Python 等语言的 SDK；DynamoDB 的第一天使用就产生了 75 美元的账单，且使用体验极差；出口流量费用从最初的每 GB 20 美分「优化」到如今仍然贵得离谱的 9 美分；计费系统充满隐匿的叠加计费陷阱；IAM 的复杂性被形容为「路西法在地狱第九层专为 AWS 用户发明的折磨」；Lambda 的冷启动延迟与开发复杂度带来的 vendor lock-in…… 这些问题的累积，最终让 Stuart 某天突然意识到：「这段关系已经结束了」。
事故始末：一次研究测试引发的四天噩梦
Stuart 重返 AWS 的初衷相当简单：测试 Claude 在 Bedrock 上的表现，以及租用一台 192 核、1TB 内存的 EC2 竞价实例来跑代码基准测试。这些都是临时性的研究需求，用完即撤。
然而当他启动那台高价位的 192 核机器、跑了约三小时后，一封来自 AWS 的邮件彻底打乱了计划：「您账户疑似遭受安全入侵」。Stuart 理解平台出于安全考虑的防护机制，甚至对此表示赞同 —— 问题在于随后的连锁反应：AWS 直接限制了他的账户，导致他留在 AWS 上的唯一业务 ——AWS WorkMail—— 彻底无法使用，所有人无法再通过该邮箱发送邮件；他无法创建任何新的 AWS 资源，甚至连原本要做的测试也无法继续。
Stuart 随即向支持团队发送工单，说明情况并强调「没有被黑、没有账单异常」。但在免费支持通道下，他得到的响应是「24 小时内回复」。三天过去，杳无音讯。
在 AWS 论坛上求助后，有人建议他改用在线聊天而非网页表单，因为「聊天才是真正有人回复的渠道」。Stuart 照做后，在等待半小时终于接通客服，完成了密码重置、密钥吊销等全部安全检查，坐席人员表示满意并承诺提交内部处理。四天后，即文章撰写时，账户仍未解封，业务邮箱依然瘫痪，而他已经对「申请配额」才能使用大型实例感到畏惧。
代价拆解：那些 AWS 不会主动告诉你的成本
从 Stuart 的经历和长期观察来看，AWS 的成本结构存在几个典型的「踩坑点」，值得工程团队在做预算规划时重点评估：
DynamoDB 的第一天账单陷阱。Stuart 提到一次「随意试用」就产生了 75 美元的账单。DynamoDB 的按需容量模式和预置吞吐量的切换逻辑复杂，对于不熟悉其计费粒度的团队而言，极易在测试阶段产生意外支出。在评估 NoSQL 方案时，应将 DynamoDB 的成本模型与自托管 Cassandra 或 PlanetScale 等替代品做对比基准测试，并将出口流量成本纳入计算。
出口流量费用的非线性增长。从最初的每 GB 20 美分「降至」9 美分，看似在改善，但 9 美分仍然远高于竞品。数据出口是云服务中少数没有规模效应降价的项目之一，对于数据密集型应用，这个成本会随时间显著累积。若你的架构涉及大量跨区域数据同步或频繁的数据导出，应在采购阶段就与 AWS 核算实际流量成本，而非仅关注计算资源的标价。
内部数据传输的隐形成本。Stuart 指出的「在自己的系统内移动数据也会被计费」是另一个常见盲区。跨 AZ 的流量、同 VPC 内不同服务之间的数据交换，在某些配置下同样会计入出口流量费用。对于微服务架构，这一成本可能在账单出账前完全不可见。建议在架构设计阶段使用 Cost Explorer 标记所有可能产生内部流量的路径，并在测试环境做小规模验证。
WorkMail 即将停服的迁移压力。AWS 已通知 Stuart 在 12 个月后关停 WorkMail，这意味着即使没有这次封禁事故，他也面临邮件系统迁移的倒计时。这种「平台级服务突然终止」的案例并非孤例 —— 工程团队应避免将核心业务依赖在单一云厂商的生命周期上，应提前规划数据导出路径与替代方案。
IAM 地狱：权限管理的复杂度代价
Stuart 对 IAM 的批评虽然带有强烈的个人情绪，但折射出一个工程现实：IAM 的复杂度是有代价的。在大型组织中，IAM 策略的调试是运维团队最耗时的任务之一，误配置导致的权限过大或服务间无法通信时有发生。
对于 IAM 复杂度的应对策略，建议团队在初始化阶段使用 aws:PrincipalAccount 和 aws:RequestedRegion 等全局条件键建立基础防护层；利用 Service Control Policies (SCP) 在组织层级定义禁止超越的边界权限；对于需要跨账户访问的场景，优先使用角色而非长期访问密钥。此外，AWS Security Hub 和 Config Rules 可以自动化检测过于宽松的 IAM 策略，建议将其纳入 CI/CD 安全检查流水线。
Lambda 的锁定期：退出成本比想象中高
Stuart 特别提到，Lambda 是他离开 AWS 时「最难撤销」的部分。这并非技术上的不可行，而是架构层面的深度耦合 —— 当一个系统的业务逻辑以函数粒度散布在 Lambda 上时，迁移到自托管服务器或其他函数计算平台的重写成本往往高到让人望而却步。
这意味着，在评估 Lambda 时，团队不仅要看启动延迟（冷启动在某些场景下可达数秒）、并发限制和超时配置的显性约束，更要评估业务逻辑与 Lambda 运行时环境之间的耦合深度。建议在项目启动前定义好「退出策略」：如果 Lambda 成本超出预期或厂商策略发生重大变化，迁移路径是什么？这个成本应该在技术选型阶段就纳入计算，而非等到账单惊人时才面对。
支持层级的选择：免费与付费的工程意义
这次封禁事件暴露的一个关键教训是：免费支持的响应速度和解决问题的实际能力，与付费支持相差甚远。四天的等待对于一个依赖 WorkMail 做业务通信的团队而言是不可接受的。
对于生产环境，建议团队至少订阅 Business Support 计划（响应时间目标为 1 小时），关键系统应考虑 Enterprise Support 以获得 TAM（技术账户经理）和更短的响应 SLA。如果成本敏感，至少应在账户级别保持至少一个「非关键但有业务价值」的资源在付费支持保护下，以便在紧急时刻能快速获得人工响应。同时，在架构层面建立多账户隔离策略，避免一个账户的风控操作连带影响其他业务，是值得投入的基础设施设计原则。
决策树：何时选 AWS，何时考虑替代
Stuart 的经历并非否定 AWS 的全部价值，而是提醒工程团队在选择平台时应更加审慎。基于他的案例，可以提炼出以下决策参考：
适合留在 AWS 的场景：需要快速启动全球分布的基础设施但缺乏自建运维能力；核心业务对某个 AWS 独占服务（如 Bedrock 的特定模型）有强依赖；组织已有成熟的 IAM 和账单管理流程。对于这类场景，接受 AWS 的复杂性溢价是合理的。
值得评估替代方案的场景：数据库成本超出预期且 DynamoDB 的数据模型优势不明显；出口流量成本在整体账单中占比过高；Lambda 的锁定期望超出团队可接受范围；无业务连续性需求但依赖单一邮箱系统（此时应优先考虑 Google Workspace 或独立邮件服务商）。
迁移前的必要检查清单：确认所有数据已导出且格式兼容；测试替代平台的功能完整性；制定 DNS 和域名迁移的灰度切换方案；在新平台完成功能验证后再关闭原账户 —— 最后一点尤其重要，Stuart 的案例正是「留了一小部分业务没迁移」导致被动挨打。
结论：信任需要成本，冗余需要规划
Stuart 在文章结尾写道：「我很庆幸多年前已经离开了 AWS，重返后的遭遇只是提醒我需要加快完成收尾工作 —— 迁出 WorkMail，转走域名，永不回头。」这句话背后是一个朴素的工程真理：对任何单一平台的深度依赖，都是一种需要管理的风险，而非可以忽视的背景噪音。
对于正在使用 AWS 或计划迁移到 AWS 的团队，这个案例提供了一个难得的「从内部视角审视平台风险」的素材：成本不只体现在账单数字上，还体现在支持响应速度、账户隔离策略、服务终止风险等隐性维度。做好这些维度的冗余设计，才是真正对业务负责的做法。
资料来源：Andrew Stuart, I returned to AWS - and was reminded HARD why I left, Four Light Years Blog.
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。