Undifferentiated Heavy Lifting 的本质 - AWS 解决的问题与不解决的问题之间的边界
深入探讨 AWS 反复使用的 Undifferentiated Heavy Lifting 这一概念的真正含义，解析托管服务的责任边界、共享责任模型的实际情况，以及全托管的幻想与现实。
什么是无差异化的繁重工作
Undifferentiated Heavy Lifting 是 AWS 在营销和技术演讲中频繁出现的短语。2006 年 Jeff Bezos 在 MIT 演讲中介绍了这一概念，意为「无论哪家企业来做结果都一样的、不能带来差异化的繁重工作」。服务器上架、网络布线、操作系统补丁更新、存储容量管理、数据中心空调管理——这些工作对于业务运营不可或缺，但无论做得多好，都不会成为客户选择该企业的理由。AWS 的提议很明确：将无差异化的繁重工作交给 AWS，企业应专注于创造自身竞争优势的活动。这一提议本身是正确的，但实际上哪些工作可以交给 AWS，其边界并不像想象中那么清晰。
共享责任模型的实际情况
AWS 的共享责任模型将安全责任分为「云的安全」（AWS 的责任）和「云中的安全」（客户的责任）。AWS 保护基础设施的物理安全、虚拟化层和网络基础。客户管理客户操作系统配置、应用程序安全、数据加密和 IAM 设置。这种分工在概念上很清晰，但在实际工作中，边界模糊的情况频繁发生。以 RDS 为例。RDS 是「全托管」的关系型数据库服务。AWS 管理数据库引擎的安装、补丁更新、备份自动化和故障转移。然而，即使备份是自动进行的，恢复测试仍然是客户的责任。如果不定期验证备份能否正常恢复，在紧急情况下可能无法恢复。参数组设置、慢查询优化、连接数管理、加密启用等都是客户侧的工作。
托管的 4 个层级 - 抽象度与约束的权衡
AWS 的服务根据客户管理的范围大致可分为 4 个层级。第一层级是以 EC2 为代表的 IaaS。提供虚拟机，从操作系统以上的所有内容由客户管理。自由度最大，但操作系统补丁更新、中间件配置、扩展设计也全部需要自行完成。第二层级是以 ECS 和 EKS 为代表的容器托管。容器编排由 AWS 管理，但容器镜像构建、应用程序配置、网络设计是客户的责任。使用 Fargate 可以从服务器管理中解放出来，但容器设计本身不变。第三层级是以 Lambda 为代表的无服务器。基础设施管理几乎完全委托给 AWS，客户只需专注于代码。但需要接受执行时间上限（15 分钟）、内存上限、冷启动延迟等约束。第四层级是以 Bedrock 为代表的模型托管。基础模型的训练、托管、扩展全部由 AWS 管理，客户只需调用 API。但模型选择、提示词设计、输出质量管理是客户的责任。抽象度越高，AWS 承担的范围越广，但同时客户需要接受的约束也越多。如果这些约束不适合自己的用例，就需要选择抽象度更低的服务。
全托管的幻想 - 运维自动化与设计自动化是不同的
对托管服务最危险的误解是「因为是托管的所以不需要考虑设计」这种想法。DynamoDB 是「全托管」的 NoSQL 数据库，但如果分区键设计错误，就会产生热分区，超过预置容量的请求会被限流。表设计、访问模式分析、GSI（全局二级索引）设计全部是客户的责任。Aurora 是「全托管」的关系型数据库，但查询执行计划优化、索引设计、连接池配置由客户完成。Aurora 托管的是复制、故障转移、存储自动扩展等基础设施层的运维。Lambda 是「无服务器」的，但函数的内存设置直接影响性能和成本。最小化冷启动的架构设计、并发执行数控制、错误处理设计是客户的工作。也就是说，托管服务自动化的是「运维」而非「设计」。服务器预置、补丁更新、备份、扩展等运维任务由 AWS 承担，但如何使用该服务的设计责任始终在客户手中。
边界的判断方法 - 服务评估清单
评估新的托管服务时，不仅要确认「它承担了什么」，还要确认「它不承担什么」。从以下角度进行整理。关于可用性：SLA 是多少百分比，低于 SLA 时的补偿是否仅为服务积分，多可用区或多区域配置是自动还是手动。关于备份：自动备份的频率和保留期限是多少，是否支持时间点恢复，恢复测试由谁执行。关于安全性：静态加密是否默认启用，传输中加密是否强制，访问控制的粒度有多细。关于扩展：自动扩展是否有上限，扩展时是否会产生停机，缩容是否有约束。关于监控：标准提供哪些指标，是否可以添加自定义指标，告警设置由谁完成。对这些问题的回答为「客户的责任」的项目，就是即使使用托管服务也需要自行设计和运维的范围。 要深入理解云运维设计，相关书籍 (Amazon) 也可作为参考。
总结
Undifferentiated Heavy Lifting 的概念是理解 AWS 承担责任范围的起点。共享责任模型在概念上很清晰，但在实际工作中边界模糊的情况很多，托管服务的抽象度越高，AWS 的责任范围越广，同时约束也越多。最重要的认识是，托管服务自动化的是运维而非设计。在选择服务时，明确「它不承担什么」，准确把握自己的责任范围，是活用托管服务的本质技能。