导读

想了解亚马逊云科技如何持续扩展其全球基础设施吗？来了解亚马逊云科技如何建设新的区域！亚马逊云科技不断扩展其全球基础设施，在本次会议中，您将回顾亚马逊云科技区域的架构以及这一过程是如何演变的。了解亚马逊云科技基础设施中软件和硬件的融合，以及负责在新亚马逊云科技区域构建EC2的工程团队所获得的经验教训。本次会议面向那些有兴趣学习如何在大规模环境下架构以实现弹性，以及如何集中大型工程活动以实现规模化交付的构建者。

演讲精华

以下是小编为您整理的本次演讲的精华。

亚马逊云科技云跨越令人瞩目的108个可用区和34个地理区域，这见证了该公司对全球覆盖和弹性的不懈追求。然而，这个广阔的足迹仅仅是亚马逊云科技继续建设的基础，已经宣布了额外的18个可用区和6个新区域的计划。这些即将推出的区域遍布墨西哥、新西兰、沙特阿拉伯王国、泰国、台湾和备受期待的欧盟主权云等多个地区，凸显了亚马逊云科技满足全球客户不断变化需求的承诺。

当Don和Michelle深入探讨亚马逊云科技全球基础设施的复杂性时，他们阐明了分区的概念，这是一个更高层次的抽象，包含一个或多个区域。绝大多数亚马逊云科技区域位于商业分区内，满足全球企业和个人的需求。然而，亚马逊云科技还维护了专门的分区，如美国政府云、中国以及即将推出的欧盟主权云，以确保符合区域法规和数据主权要求。

分区还包含亚马逊云科技全球服务的实例，如CloudFront和Route 53，这些服务本质上是全球性的，跨越多个区域为全球客户提供无缝体验。

除了分区，亚马逊云科技基础设施还按区域进行组织，这些区域是在全球范围内战略部署的物理位置。每个区域包含多个可用区，这些独立的数据中心相距约60英里或100公里。这种有意的分离是亚马逊云科技弹性策略的关键组成部分，旨在防止相关故障，并确保影响一个可用区的自然灾害或其他本地事件不太可能影响同一区域内的其他可用区。

同一区域内的可用区通过多条独立的高带宽光纤连接相互连接，促进低延迟通信和数据传输。此外，亚马逊云科技还采用了传输中心，这些专门的设施不仅将可用区互连，还提供与亚马逊云科技全球骨干网络的连接。

这个全球骨干网络是一个私有维护的跨越全球的光纤网络，使得从一个区域发出并前往另一个区域的流量能够保持在亚马逊云科技的安全基础设施内，无需穿越公共互联网。此外，传输中心与互联网骨干网络高度对等，促进了流量在互联网之间的高效出入。

对于客户而言，这个复杂的全球基础设施转化为共享责任模型，亚马逊云科技确保底层基础设施的弹性，而客户则负责构建利用亚马逊云科技可用区和区域提供的故障隔离和冗余的应用程序和工作负载。

为了说明这一概念，Don提供了一个示例架构，包括负载均衡器后面的Web服务器，这些Web服务器位于跨越多个可用区的Auto Scaling组中。这些Web服务器又与Amazon Simple Storage Service (S3)和Amazon DynamoDB等服务交互，用于存储和数据检索。

在这种架构中，潜在的故障模式可能包括受损的实例或可用区，在这种情况下，Elastic Load Balancer会检测并从服务中移除不健康的实例，而Auto Scaling会启动额外的实例以维护应用程序可用性。然而，更隐蔽的情况，如部分流量失败或存储卷降级等灰色故障，可能需要人工干预并应用预定义的运行手册和业务指标来确定适当的行动方案。

Don和Michelle强调了理解亚马逊云科技服务的区域性和可用区性的重要性，以及建立明确的操作程序并定期进行游戏日来验证恢复机制。通过采用这些做法，客户可以有效利用亚马逊云科技基础设施中内置的弹性，并在发生事故或灾难恢复情况时做出明智决策。

当演示过渡到构建新亚马逊云科技区域的复杂过程时，Don和Michelle带领观众踏上了一段引人入胜的旅程，探索了这一进程的演变历程。在早期，一名“引导忍者”会亲自前往新区域的现场，携带包含初始证书和配置的U盘，以启动软件安装过程。

然而，这种方法虽然在当时是开创性的，但很快就被证明是不可持续的，因为亚马逊云科技继续以前所未有的速度创新并推出新服务。手动流程的本质，加上人为错误的固有风险和同时协调多个区域构建的后勤挑战，迫使亚马逊云科技从根本上改变了其方法。

转折点出现在圣保罗(巴西)区域推出后不久，当时这是亚马逊云科技的第8个区域。当公司宣布在新区域推出15项服务时，人们意识到“引导忍者”模式已无法跟上亚马逊云科技服务和功能快速发展的步伐。

为了应对这一挑战，亚马逊云科技开启了一场变革之旅，将区域构建的物理和软件工作流程并行化。通过利用现有的亚马逊云科技区域作为“引导区域”，公司可以在新区域的物理数据中心建设同时并行启动软件构建过程。这种巧妙的方法不仅消除了之前模式的瓶颈，还为更高效、可扩展的区域构建过程铺平了道路。

然而，这种转变并非没有挑战。正如Don敏锐地指出的那样，亚马逊云科技早期采用了更加单体的方法，各项服务独立构建和运行。然而，随着时间的推移，亚马逊云科技演变为大多数服务都建立在Amazon Elastic Compute Cloud (EC2)之上的模式，实际上运行在EC2提供的计算基础设施之上。

这种转变带来了新的复杂层面，因为EC2本身依赖于S3和DynamoDB等服务进行对象存储和键值存储。因此，出现了一种循环依赖，EC2需要S3和DynamoDB才能运行，而这些服务又建立在EC2之上，形成了一个错综复杂的相互依赖关系，必须小心解开。

为了解决这一挑战，亚马逊云科技采用了一种巧妙的解决方案:代理。通过引入可以对区域内认证服务进行身份验证并暂时将数据存储在引导区域的S3和DynamoDB实例中的代理，亚马逊云科技有效地打破了循环依赖，允许在新区域构建EC2和其他核心基础设施服务，同时依赖引导区域的资源作为临时缓冲。

这种被Don亲切地称为“mullet”的方法，即“前面构建区域，后面引导区域”，被证明是一个游戏规则改变者，使亚马逊云科技能够在继续快速创新的同时扩大其区域构建能力。

随着演示的深入，Don和Michelle揭示了支撑最基本的亚马逊云科技服务背后的复杂依赖关系。以EC2“运行实例”API调用为例，他们揭示了其中涉及的令人瞩目的复杂性，数百个内部服务被编排以完成单个请求。

这种复杂性还因亚马逊云科技服务的不断演进而加剧，新功能和依赖关系会定期引入。为了在区域构建期间管理这种错综复杂的依赖关系，亚马逊云科技采用了基于波次的方法，将服务根据其依赖关系分组为不同的波次。在每个波次中，服务会持续监控其依赖项的健康状况，只有在其先决条件满足后才会激活。

这种方法不仅简化了区域构建过程，而且在运营事件期间也发挥了宝贵作用，亚马逊云科技服务遵循“静态稳定性”原则。该原则规定服务应该努力在没有人工干预的情况下自行恢复上线，这在数据中心发生电源中断或其他中断事件时是一项关键能力。

为了编排这种复杂的依赖关系和服务激活过程，亚马逊云科技开发了一套专门的工具和机制。项目管理工具捕获高级依赖关系、构建持续时间和总体进度，使亚马逊云科技能够兑现向客户承诺的区域上线时间表。

广泛的内部文档和集中的程序解决了工具缺口，确保在区域构建过程中遇到的常见问题得到及时解决，无论是通过开发新工具还是实施临时解决方案。

在整个区域构建过程中，亚马逊云科技利用了多种机制来促进协作、透明度和持续改进。工单作为亚马逊云科技运营的一个无处不在的方面，是一个集中的存储库，用于跟踪和审计问题，实现自助式问题解决，并促进可发现性和可审计性。

运营准备评审在评估服务的准备情况方面发挥着关键作用，团队会详细记录故障隔离、故障模式、运营指标、警报和部署流水线。这些运营准备评审不仅在服务推出之前进行，而且还会定期进行，以确保运营程序和监控与不断发展的服务能力和客户需求保持一致。

另一方面，纠正错误评审有助于培养持续学习和改进的文化。一旦发生运营事故，团队就会记录时间线、影响、根本原因和经验教训，并在亚马逊云科技内部分享这些见解，以防止类似情况发生并促进最佳实践的采用。

值得注意的是，亚马逊云科技的纠正错误评审从不具有惩罚性质，这反映了公司的信念，即运营商错误通常是更深层次问题的症状，如工具不足或流程不明确。通过营造一种信任和学习的环境，亚马逊云科技使其团队能够识别和解决根本原因，不断完善其运营并提高服务的弹性。

我们正处在 Agentic AI 爆发前夜。 2025 亚马逊云科技中国峰会提出，企业要从 " 成本优化 " 转向 " 创新驱动 " ，通过完善的数据战略和 AI 云服务，把握全球化机遇。亚马逊将投入 1000 亿美元在 AI 算力、云基础设施等领域，通过领先的技术实力和帮助“中国企业出海“和”服务中国客户创新“的丰富经验，助力企业在 AI 时代突破。