直到最近，亚马逊云科技全球路由服务的每个新客户端会话都会以一个请求开始。该请求的唯一目的是确定应使用哪个 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 账户中）相契合。
两个端点并行运行。我们新发布了客户端库的一个大版本。该版本采用 SigV4a 签名并指向新端点，同时开展了一项迁移活动：在内部渠道发布公告，并直接联系调用量较大的团队，提前充分沟通了弃用时间表。并行运行期持续了约三个月，我们通过服务指标跟踪了各个库版本的采用情况——观察随着各团队进行更新，SigV4 与 SigV4a 请求的比例变化。
此次部署遇到的问题主要与流程相关，而非算法问题。
首先，部分客户的环境中存在企业防火墙或网络控制措施。这些措施将旧域名列入了白名单，但未将新域名列入。在更新这些白名单之前，发往新端点的请求会被静默丢弃。
其次，并非所有团队都在使用我们提供的 SDK 客户端。有些团队实现了自定义签名逻辑，需要直接联系。这时仅更新库依赖关系是不够的。
第三，SDK 版本管理成为了一项实际限制。部分客户端仍然在使用旧版 SDK，若不先进行许多无关的重构以升级到新版，则无法支持 SigV4a。
当旧端点的流量降至可忽略不计的水平，且剩余调用方已确认迁移计划后，我们将其连同 DiscoverRegion 端点一同退役。整个迁移过程历时约六个月：构建并部署 SigV4a 端点耗时约三个月，随后又花了三个月进行并行运行以及完成调用方迁移。技术变更本身微乎其微，但协调成本却不容小觑。
迁移完成后，我们确认，发现过程的往返延迟已不复存在。我们并未测量 ECDSA 签名与 HMAC 的 CPU 开销——在现代硬件上，前者耗时不足一毫秒，与网络往返延迟相比根本不值一提。
在哪些情况下 SigV4 仍然是最佳选择
SigV4a 并非一个通用的改进方案。它解决的是一个特定的问题——在签名时不知道目标区域的动态路由。如果你的系统中不存在这个问题，那么 SigV4 将是一个更简单的解决方案。
首先需要确认的一个硬性限制是：并非所有 AWS 服务和 API 类型都支持 SigV4a。例如，S3 虽然支持 SigV4a，但仅限于多区域访问点，而不支持标准区域端点。支持 IAM 身份验证的 API Gateway REST API 支持 SigV4a；而 HTTP API 则不支持。在评估 SigV4a 是否能从架构层面解决你的问题之前，请先确认你所使用的具体服务和端点类型是否接受 SigV4a 签名。
SigV4a 的支持范围可能比你预想的要窄。当缺少支持时，它会返回 403 错误，而且其中不会提供任何有用的诊断信息。
何时使用 SigV4 ：
你正在使用的 AWS 服务或 API 类型不支持 SigV4a。
你的服务部署在单个区域中，或者客户端始终针对已知的稳定区域。
受监管要求或数据驻留要求限制，请求必须限定在单个特定区域内——在这种情况下，SigV4 的区域范围限定是一项功能，而非限制。
你的客户端工具不提供可靠的 SigV4a 支持。
何时考虑 SigV4a ：
你正在使用的服务明确支持此功能。
客户端进行预检发现步骤，纯粹是为了满足区域范围内的身份验证要求。
你正在跨区域构建基于延迟的路由或 Active-Passive 故障转移方案。
简化客户端实现（移除区域缓存状态）是一个有意义的目标。
是什么让这件事值得去做
在构建该服务时，采用发现步骤是正确的决策——当时，SigV4 是唯一的选择，而且多年来一直运行良好。当区域性故障迫使我们认真对待全球故障转移时，迁移工作才开始变得值得一做，而发现步骤恰恰成了阻碍这一进程的障碍。
核心问题在于耦合：SigV4 的区域范围模型迫使客户端做出本应由基础设施负责的路由决策。SigV4a 消除了这一限制。如果你的客户端正在执行一个预检步骤，而该步骤的唯一目的是确定应为哪个区域进行签名，那么这就是信号。该步骤的存在源于身份验证模型，而非因为它本身能带来什么附加价值。
原文链接：https://www.infoq.com/articles/aws-multi-region-signing/
