从多区域 AWS API 中移除隐藏的往返请求

直到最近，亚马逊云科技全球路由服务的每个新客户端会话都会以一个请求开始。该请求的唯一目的是确定应使用哪个 AWS 区域进行身份验证。我们采用这一临时解决方案多年，直到最近才将其移除。推动我们这样做的原因并非出于延迟方面的考虑，而是源于一系列区域性服务中断事件。我们构建服务时的限制条件本文将要介绍的是由我和我的团队在亚马逊云科技内部运行的一项用户设置服务。该服务供其他需要快速、低延迟访问用户设置的亚马逊云科技团队在内部使用。我们的服务存储着在应用程序启动时会被调用的用户状态，可以将其看成是无论用户身处何地都需要快速加载的设置。该服务的架构如下：在两个区域内部署 API Gateway（APIGW）REST API，配置基于延迟的 Route 53 路由，并让基础设施自动决定流量的着陆点。在集成 AWS Identity and Access Management (IAM) 时，我们遇到了一个限制。由于我们是按身份存储设置，所以需要在 APIGW 中使用 IAM 身份验证。当时，唯一的选择是使用 AWS Signature Version 4 （SigV4）。SigV4 是用于受 IAM 保护的 API Gateway 请求的身份验证方案。它将每个已签名的请求与特定的服务和区域绑定。在签名过程中，区域信息会被嵌入到凭证作用域中。也就是说，如果针对 us-west-2（俄勒冈）签名的请求到达 eu-west-1（爱尔兰），则该请求在加密层面上将被视为无效。在请求被处理之前，签名验证就会失败。这种区域绑定限制导致了一种权衡：我们希望让基础设施（DNS 服务 Route 53）来决定由哪个区域提供服务，但客户端必须先确定一个区域，才能构建出有效的请求。因此，我们围绕这一限制构建了我们的服务。作为临时解决方案，我们实现了一个云区域上线前的探测步骤。首先，客户端会调用一个轻量级的 DiscoverRegion 端点。由于其唯一作用是返回区域名称，所以不需要身份验证。这样可以确定哪个区域“最近”，将该结果缓存起来，然后使用 SigV4 对该区域内的所有后续调用进行签名。总体而言，初始请求时需要发送两个请求才能完成一项操作。这成为了我们的生产架构，并且多年来运行良好。然而，us-east-1（北弗吉尼亚）地区发生的一系列事件，包括网络问题（2021 年 12 月）、Lambda 故障（2023 年 6 月）和 DynamoDB 故障（2025 年 10 月），直接影响了我们的服务。由于我们依赖 API Gateway、Lambda 和 DynamoDB，尽管该服务在架构上是全球性的，但我们无法将流量从受影响的区域转移出去。那些已完成区域发现并为 us-east-1 签署请求的客户端，在加密层面上与该区域绑定了。如果将请求重定向到 us-west-2，针对 us-east-1 的 SigV4 签名将失效。唯一的恢复途径是重新执行发现流程。这些事件促使我们在 2025 年第四季度对设置服务进行了重构，实现了区域级弹性，而“发现”步骤以及其所需的客户端区域固定机制却成了障碍。当时，非对称签名第 4 版（SigV4a）已经推出有一段时间了（于 2021 年第三季度发布）；只是在此之前，我们根本没有理由采用它。我们从跟踪记录中发现了什么在将请求流程纳入整体重构范围进行分析后，我们注意到了延迟带来的影响。在第 90 百分位（p90），当用户与被发现的端点位于同一区域时，新客户端会话的 DiscoverEndpoint 延迟为 75–100 毫秒。在一般情况下（例如用户位于 us-west-2，而被发现的端点位于 us-east-1，相距不算太远但也不算太近），DiscoverEndpoint 的 p90 延迟会增加到约 315 毫秒。在最坏的情况下，例如 us-west-2 的用户访问 ap-south-1（孟买），p90 延迟则高达 1 秒。虽然这可以归因于多种因素，例如客户端往返时间、区域路由效率低下、网络连接速度慢等，但我们仍然希望避免这类请求往返，并以此来降低延迟。当架构稳定，而且除了构建新的全球服务之外没有其他明显的替代方案时，这种延迟开销还算是一个可以接受的折中方案。然而，在服务中断事件发生后，我们得知 SigV4a 可以完全省去发现步骤。因此，在重新设计的全球服务中，我们就不愿意继续保留每个新会话 100 毫秒的延迟了。延迟数据显而易见，但成本不限于此，只有当我们开始围绕这些成本进行设计时，它们才变得清晰。客户端状态。一旦客户端将某个区域设为固定区域，它就会在整个会话期间保持该选择。如果该区域在发现调用后出现性能下降，客户端的签名请求就会开始失败——此时重试逻辑必须检测到这一情况，使缓存的区域失效，并在重试原始调用之前重新执行发现操作。这一失败路径比看起来要复杂得多。运行态耦合。为实现全局故障转移而进行的设计，意味着我们需要在区域之间干净利落地切换流量。这就要求更新发现端点的响应，并确保客户端能在合理的时限内获取到新的选择结果。在稳态运行期间，发现层原本只是一个次要的细节，如今却直接成了故障转移设计的关键路径。客户端库的复杂性。由于要将该服务对外开放给多个内部调用方，所以我们发布了一个封装了服务发现和签名功能的客户端库。该库需要管理区域缓存的生命周期、重试逻辑以及凭证作用域。这绝非简单的抽象。具体流程如下：客户端调用 GET /discover（无需身份验证），返回一个区域名称（如 us-west-2），随后对该区域的 POST /settings 请求进行签名并发送。身份验证需要两次往返。发现步骤通常不会出现在大多数架构图中——它位于客户端库内部，但总会增加延迟。图 1：SigV4 流程——客户端首先调用 DiscoverRegion 端点，缓存返回的区域，然后对绑定到该单一区域的请求进行签名并发送（图片由作者制作）SigV4a 改变了什么AWS Signature Version 4A（SigV4a）改变了签名范围。SigV4a 签名对一组区域有效，而非仅对单一区域有效。之所以能够实现这一点，是因为 SigV4a 使用的是 ECDSA-P256（一种非对称椭圆曲线签名算法），而非 HMAC-SHA256：使用这种非对称模型，服务不用确切地知道生成该签名的区域就可以进行验证签名，只要该签名对允许的区域集有效即可。因此，客户端在对请求进行签名时，不再需要事先知道目标区域。它可以针对声明的区域集进行一次签名，然后发送至全局入口点。全局基础设施（例如 Route 53 或 Global Accelerator）会解析出实际的端点。无论最终由哪个区域的部署来处理该请求，该请求在加密层面上始终是有效的。图 2：SigV4a 流程——客户端针对一组区域进行一次签名，并将签名发送至全局入口点，该入口点会将其路由至最近的正常运行区域（图片由作者制作）切换完成后，客户端针对区域集 {us-west-2，eu-west-1} 给一个 POST /settings 请求签名，并将其发送至全局入口点（https://global.settings.service——这是一个基于延迟的路由端点，而非 https://region.settings.service）。Route 53 负责解析目标。客户端永远不会知道是哪个区域处理了该请求，也不需要知道。此外，全局入口点也可以是一个 CloudFront 目标，这样就可以将请求引入亚马逊的骨干网，并在其网络内部进行高效地路由。重试逻辑也变得更简单了——如果请求失败，只需要重试即可。由于签名在两个区域都有效，所以基础设施可以在客户端不知情的情况下将重试请求路由到其他地方。此次迁移实际涉及的内容我们之前架构中的区域发现步骤并非疏忽所致。在构建该服务时，SigV4 是唯一可用的选项，而当时采用的变通方案是正确的决定。此次迁移并非在纠正错误，而是利用了初始设计时尚不存在的一项功能。签名机制的变更本身微乎其微。在库的层面上，主要区别在于：不再需要在签名时锁定单个区域字符串，而是声明一个区域集合：// SigV4: 为一个区域签名 —— 必须匹配目标区域sign (request, region= "us-west-2")// SigV4a: 为区域集签名 —— 基础设施解析目标区域sign (request, regionSet= ["us-west-2", "eu-west-1"])复制代码区域集只是一个列表——它可以小到仅包含两个相邻的区域，用于 Active-Passive 故障转移；也可以限定为单个地理区域（例如：所有欧盟的区域），以满足数据驻留的要求。它还支持通配符，例如 X-Amz-Region-Set=us-west-*，此时请求可以在 us-west-1（旧金山）或 us-west-2（俄勒冈）中发起。除此之外，SDK 调用的结构完全相同。如果你的签名逻辑封装在客户端库中（我们的就是如此），那么差异仅集中在一个地方。困难之处在于部署，而非代码本身。由于有多个内部团队依赖我们的客户端库，所以我们无法一蹴而就：保持现有的 SigV4 端点不变，我们并行部署了一个与 SigV4a 兼容的新端点。虽然 SigV4a 本身并不严格要求创建新端点，但此举使得迁移过程更易于理解：新设计将区域发现和手动路由整合为单个全局入口点，为未来的工作（如 IPv6）提供了更简洁的 DNS 架构，同时也与更广泛的安全驱动型基础设施变更（新的 API 网关部署在不同的 AWS 账户中）相契合。两个端点并行运行。我们新发布了客户端库的一个大版本。该版本采用 Si