Article: Removing a Hidden Round Trip from a Multi-Region AWS API

从多区域AWS API中移除隐藏的往返过程 - InfoQ

InfoQ 首页 文章 从多区域AWS API中移除隐藏的往返过程

云技术

框架之下：为什么代理上下文是一个基础设施问题（8月27日网络研讨会）

从多区域AWS API中移除隐藏的往返过程

2026年7月13日 11分钟阅读

作者：

• Suresh Gururajan

审阅者：

• Renato Losio

#### 关注我们

YouTube

232K 粉丝

LinkedIn

26K 粉丝

Instagram

新

RSS

19K 读者

X

57.1k 粉丝

Facebook

21K 赞

Bluesky

收听本文 -

0:00

音频准备就绪

您的浏览器不支持音频元素。

正常

1.25x

1.5x

点赞

新下拉阅读列表

• 阅读列表

核心要点

• SigV4通过加密方式对AWS API请求进行签名以防止篡改，但每个签名仅绑定到单一区域，迫使客户端在构建请求前就确定目标区域。

• SigV4a通过使签名在一组区域中有效来扩展这一功能，让基础设施（而非客户端）处理路由决策。

• 从SigV4迁移到SigV4a只需进行小幅代码修改，但协调依赖调用方并非易事，而发布问题几乎总是流程问题而非算法问题。

• 最明确的信号是，如果客户端正在运行一个预检步骤，其唯一目的是学习应签名的区域——该步骤的存在源于认证模型，而非因为它增加了价值。

• 定期检查当前云解决方案与现有工具和服务的匹配度，不是为了发现错误，而是因为某些解决方案的约束条件可能已不再适用。

直到最近，每个新客户端会话到我们的AWS全局路由服务时，都会先发起一个仅用于确定应认证哪个AWS区域的请求。我们多年保留这个变通方案，直到最终移除它——推动这一改变的并非延迟问题，而是一系列区域故障。

我们构建的约束

本文与我团队在AWS内部运行的用户设置服务相关，该服务被其他AWS团队内部使用，这些团队需要快速、低延迟地访问每个用户的设置。我们的服务存储每个用户的运行时状态——这些设置需要在用户所在任何位置都能快速加载。服务架构为：在两个区域部署API Gateway（APIGW）REST API，通过Route 53延迟路由进行连接，并让基础设施决定流量路由。

当集成AWS身份和访问管理（IAM）认证时，我们遇到了约束。由于我们按身份存储设置，因此需要在APIGW中使用IAM认证。当时唯一的选择是使用AWS签名版本4（SigV4）。

#### 相关赞助商

• 为什么API不能信任客户端——以及如何弥合这一差距

#### 相关赞助商

测试。保护。重复。Guardsquare将移动应用测试与保护相结合，实现最大安全性且无性能折损。请求报价。

用于IAM保护API网关请求的SigV4认证方案，将每个签名请求绑定到特定服务和区域。区域在签名过程中嵌入到凭证作用域中，这意味着为us-west-2（俄勒冈）签名的请求，若到达eu-west-1（爱尔兰）将被判定为加密无效。签名检查会在请求处理前失败。

该区域绑定约束导致了一个权衡：我们希望基础设施（DNS服务Route 53）来决定由哪个区域提供服务，但客户端必须在构造有效请求之前就承诺选择一个区域。因此，我们围绕这一约束构建了服务。

为解决这一问题，我们实现了一个预检区域发现步骤作为变通方案。客户端首先会调用一个轻量级的DiscoverRegion端点——由于其唯一任务是返回区域名称，因此无需认证——获取"最近"的区域，缓存该结果，然后使用SigV4对所有后续请求进行签名。初始请求总共需要发送两次请求才能完成一次操作。

这成为了我们的生产架构，并在多年里运行良好。然而，us-east-1（北弗吉尼亚）发生的一系列事件（包括网络问题12/2021、Lambda问题06/2023和DynamoDB问题10/2025）直接影响了我们的服务。由于我们依赖API Gateway、Lambda和DynamoDB，即使服务在架构上是全球化的，也无法将流量转移到受影响区域。已经完成区域发现并为us-east-1签名的客户端被加密绑定到该区域——将us-east-1的SigV4签名重定向到us-west-2时会失效。唯一的恢复方式是重新运行发现流程。

这些事件促使我们在2025年第四季度重新设计设置服务以实现区域弹性，而发现步骤及其所需的客户端区域绑定成为了障碍。到那时，非对称签名版本4（SigV4a）已经可用一段时间（2021年第三季度发布），但我们此前没有理由使用它。

跟踪分析显示的内容

一旦我们将请求流程纳入全球架构重设计的考量，就注意到了延迟影响。在90百分位（p90）指标上，当用户与发现端点位于同一区域时，新客户端会话的DiscoverEndpoint延迟为75-100ms。在平均情况下（例如用户位于us-west-2而发现端点位于us-east-1——距离不算太近也不算太远），DiscoverEndpoint的p90延迟增加到约315ms。在最坏情况下（例如us-west-2用户访问ap-south-1（孟买）），p90延迟达到1秒。

虽然这可能归因于客户端往返、低效的区域路由和网络连接速度等因素，但这是我们宁愿避免的额外请求往返，因此需要降低延迟。

当架构稳定且没有明显替代方案时，这种延迟开销是可以接受的妥协。但经历了故障后，一旦我们了解到SigV4a可以完全消除发现步骤，每次新会话都要承受100ms的延迟就不再是可接受的，尤其是在重新设计全球服务时。

虽然延迟数字是显而易见的部分，但当我们开始围绕它们进行设计时，其他成本才变得清晰：

客户端状态。一旦客户端绑定到某个区域，它会在整个会话期间保持该选择。如果在发现调用后该区域出现降级，客户端的签名请求将开始失败——重试逻辑现在需要检测到这种情况，使缓存区域失效并重新运行发现流程，然后再重试原始调用。这条失败路径比看起来要复杂得多。

操作耦合。为实现全局故障转移设计，我们需要在不同区域之间干净地切换流量。这要求更新发现端点的响应，并确保客户端能在合理的时间窗口内获取新的选择。在稳态操作期间，发现层只是一个次要细节，现在却直接成为故障转移设计的关键路径。

客户端库复杂性。由于该服务需要暴露给多个内部调用者，我们开发了一个封装发现和签名功能的客户端库。该库必须管理区域缓存生命周期、重试逻辑和凭证作用域。这不是一个简单的抽象层。

流程本身如下：客户端调用GET /discover（未认证），获取类似us-west-2的区域名称，然后对该区域签名并发送实际的POST /settings请求。需要两次往返进行认证。发现步骤通常不会出现在大多数架构图中——它隐藏在客户端库内部，但始终会增加延迟。

图1：SigV4流程——客户端首先调用DiscoverRegion端点，缓存返回的区域，然后对该区域进行签名并发送请求。（图片由作者创作）

SigV4a的变更

AWS签名版本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：为一个区域签名——必须与目标区域（请求，区域="us-west-2"）匹配 // SigV4a：为一个区域集签名——基础设施会解析目标区域（请求，区域集=["us-west-2", "eu-west-1"]）

区域集只是一个列表——它可以仅包含两个相邻区域用于主备故障转移，也可以限定在一个地理范围（例如：所有欧盟区域）以满足数据驻留要求。它还支持通配符，例如 X-Amz-Region-Set=us-west-*，请求可以发送到 us-west-1（旧金山）或 us-west-2（俄勒冈）。SDK 调用的其余结构保持一致。如果签名逻辑封装在客户端库中（我们的库就是如此），差异仅局限于一个位置。

更困难的部分是部署，而非代码本身。由于多个内部团队依赖我们的客户端库，我们无法直接切换：我们并行启用了新的 SigV4a 兼容端点，与现有的 SigV4 端点共存。创建新端点本身并非 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的场景包括：

• 您使用的服务明确支持SigV4a。
• 客户端执行预检发现步骤纯粹是为了满足区域限定认证的需求。
• 您正在构建基于延迟的路由或跨区域的主动-被动故障转移方案。
• 客户端简洁性（消除区域缓存状态）是重要目标。

促使我们行动的关键因素

在构建服务时，我们选择添加发现步骤是正确的决定——当时SigV4是唯一选项，且多年来运行良好。当区域故障推动我们认真对待全局故障转移时，迁移变得值得实施，而发现步骤恰好是阻碍我们前进的因素。

核心问题在于耦合：SigV4的区域限定模型迫使客户端做出本应由基础设施决定的路由决策。SigV4a消除了这一限制。如果您的客户端正在运行一个唯一目的是确定签名区域的预检步骤，这就是信号。该步骤的存在源于认证模型，而非其本身具有价值。

作者信息主容器

关于作者

章节标题

每个作者信息主容器

#### Suresh Gururajan

显示更多

显示更少

#### 本内容属于云技术主题

##### 相关主题：

• 开发
• 架构与设计
• DevOps
• 认证
• AWS
• 弹性
• 身份管理
• 亚马逊
• 多区域
• 安全
• 低延迟
• 架构
• 云计算
• 云技术
• 可用性
• 相关编辑
• InfoQ Slack热门内容

InfoQ新闻通讯

每周二发送上周InfoQ内容摘要。加入超过25万名高级开发者的社区。查看示例

我们保护您的隐私。