[新产品/新功能] AWS Application Load Balancers 现已支持 URL 和主机标头重写

**发布时间:** 2025-10-15 **厂商:** AWS **类型:** BLOG **原始链接:** https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-url-and-host-header-rewrite-with-aws-application-load-balancers/ --- <!-- AI_TASK_START: AI标题翻译 --> [新产品/新功能] AWS Application Load Balancers 现已支持 URL 和主机标头重写 <!-- AI_TASK_END: AI标题翻译 --> <!-- AI_TASK_START: AI竞争分析 --> # 产品功能分析 ## 新功能/新产品概述 AWS为其**应用负载均衡器 (Application Load Balancer, ALB)** 引入了原生的URL和主机头重写功能。这是一个在**OSI模型**的**第7层（应用层）**运行的新特性，允许用户根据请求参数（如路径、主机头、HTTP头）使用**正则表达式 (Regex)** 进行匹配，并在将流量路由到后端目标之前修改URL路径和主机头。 此功能的目标是取代之前需要通过自定义应用逻辑或部署第三方代理（如NGINX）才能实现的复杂路由和请求修改操作。通过将这些高级路由能力直接集成到ALB这一托管服务中，AWS旨在为用户提供一个更简化、高效且成本更低的应用交付架构。目标用户群包括需要进行服务迁移、API版本管理、或在**Amazon EKS**等容器环境中实现复杂入口路由的开发人员和架构师。 ## 关键客户价值 - **简化架构并降低运维开销** - 用户不再需要部署和维护独立的代理服务器集群（如NGINX Ingress Controller）来实现URL重写，从而减少了基础设施的复杂性和故障点。 - 所有路由逻辑统一在ALB中进行管理，这是一个完全托管的服务，AWS负责其扩展、可用性和安全补丁，显著降低了运维负担。 - **降低成本与延迟** - 通过移除代理层，减少了所需的计算资源（如**EC2**实例或容器），直接降低了基础设施成本。 - 请求路径更短，流量从ALB直接到达后端目标，消除了经过代理服务器的额外网络跳跃，从而降低了请求处理的端到端延迟。 - **支持无缝的应用现代化与迁移** - URL转换功能允许后端服务在不修改任何前端或客户端代码的情况下进行重构或迁移。例如，在将应用从旧版API（v1）迁移到新版（v2）时，ALB可以自动将`/v1/`路径重写为`/v2/`，对用户透明。 - 这为从单体应用逐步迁移到基于**容器**或**Lambda**的微服务架构提供了极大的便利，实现了平滑过渡。 - **增强云原生环境的集成（尤其针对Kubernetes）** - 此功能直接解决了**Amazon EKS**用户在使用原生**AWS Load Balancer Controller**时的一个关键痛点：缺乏内置的路径重写能力。 - 现在，用户可以完全依赖ALB进行高级流量管理，而无需在**Kubernetes**集群中部署和配置额外的Ingress控制器，从而构建更精简、更原生的云上架构。 ## 关键技术洞察 - **将高级路由逻辑下沉至托管负载均衡器** - 此次更新的核心是将传统上由应用代理（如NGINX, Envoy）或API网关处理的**正则表达式**匹配和请求修改能力，原生集成到了**ALB**的数据平面中。这标志着负载均衡器正在从单纯的流量分发工具向更智能的应用流量管理平台演进。 - **基于规则引擎的声明式配置** - 该功能通过在ALB侦听器规则中扩展“条件(Conditions)”并引入新的“转换(Transforms)”步骤来实现。这种声明式配置方式与基础设施即代码（IaC）理念高度契合，便于通过**AWS CloudFormation**、**Terraform**或**AWS SDK**进行自动化管理和版本控制。 - **内置正则表达式验证工具** - AWS管理控制台为正则表达式的配置提供了内置的实时测试工具。这一设计极大地提升了用户体验，允许开发者在保存规则前验证其**正则表达式**的正确性，有效降低了因配置错误导致生产问题的风险。 ## 其他信息 - **全球可用性** - 该功能已在所有AWS商业区域、AWS GovCloud (US)区域以及AWS中国区域正式可用，确保全球范围内的客户可以立即在其架构中采用此新特性。 <!-- AI_TASK_END: AI竞争分析 --> <!-- AI_TASK_START: AI全文翻译 --> # AWS Application Load Balancer 现已支持 URL 和主机标头重写功能 **原始链接:** [https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-url-and-host-header-rewrite-with-aws-application-load-balancers/](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-url-and-host-header-rewrite-with-aws-application-load-balancers/) **发布时间:** 2025-10-15 **厂商:** AWS **类型:** BLOG --- 今天，我们宣布 Amazon Web Services (AWS) 的 [应用型负载均衡器 (Application Load Balancers, ALB)](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/introduction.html) 现已正式原生支持重写 URL 和主机标头。您可以使用这项新功能，根据请求参数实现正则表达式 (regex) 匹配，并在将请求路由到目标之前重写主机标头和 URL。 ALB 工作在 [OSI 模型](https://en.wikipedia.org/wiki/OSI_model) 的第 7 层 (应用层)，负责将传入流量分发到多个目标，例如 Amazon Elastic Compute Cloud (Amazon [EC2](https://aws.amazon.com/ec2/)) [实例 (instances)](https://aws.amazon.com/ec2/)、[容器 (containers)](https://aws.amazon.com/containers/)、[AWS Lambda](https://aws.amazon.com/pm/lambda/) 函数以及跨 AWS [可用区 (Availability Zones, AZs)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-regions-availability-zones.html) 的 IP 地址。该服务会持续监控目标健康状况，确保流量仅流向正常运行的资源，同时自动扩展以适应不断变化的流量模式。在此之前，要实现 URL 或主机标头的修改，要么需要自定义应用程序逻辑，要么需要部署和维护第三方代理解决方案。 今天的发布通过将更多路由功能直接集成到 ALB 服务中，消除了这种复杂性。企业现在可以通过其现有的 AWS 托管基础设施实现高级请求路由场景，而无需增加额外组件。您可以将这些功能整合到 ALB 本身，从而受益于简化的架构、减少的维护开销、更低的成本和更短的延迟，同时为您的应用程序创建更直接的请求路径。 ## **工作原理** 现在，您可以通过 [AWS 管理控制台 (AWS Management Console)](https://aws.amazon.com/console/)、[AWS SDK](https://builder.aws.com/build/tools) 或 [AWS API](https://docs.aws.amazon.com/elasticloadbalancing/latest/APIReference/Welcome.html) 在[新的](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-application-load-balancer.html) 和[现有的](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/edit-load-balancer-attributes.html) ALB 上配置基于条件的正则表达式匹配以及 URL 路径和主机标头的原生重写功能。如图 1 所示，第三方代理现在可以被 ALB 新的原生功能完全取代，该功能支持在将传入请求路由到适当的目标组之前重写和删除路径段。  *图 1: 在 ALB 上使用目标组进行 URL 重写* 同样，Kubernetes 用户，特别是使用 ALB Ingress Controller 的用户，需要路径重写功能来正确地将流量路由到容器化服务。他们过去必须实施像 NGINX Ingress Controller 这样的代理，这给 [Amazon Elastic Kubernetes Service (Amazon EKS)](https://aws.amazon.com/eks/) 部署增加了不必要的复杂性。新的 ALB 功能 (如图 2 所示) 现在使用户能够充分利用 ALB，同时简化他们的微服务架构。  *图 2: 在 ALB 上使用 EKS 目标组进行 URL 重写* 为了通过一个例子来演示这一点，我们考虑以下场景：一家跨国公司维护一个支持多种语言的应用程序。其架构目前分为： - *法语和英语后端*：已经迁移并部署在 Amazon EKS 上，运行最新的 API 版本 2 (V2)。 - *所有其他语言的后端*：目前在 EC2 实例上运行，使用旧版的 API 版本 1 (V1)。 该公司正在逐步将所有语言的流量迁移到 Amazon EKS 上运行。它支持最新的 API 版本 (V2)，并且需要透明地处理 URL 版本控制，而无需修改任何前端应用程序代码。 ### **1. 规则简化：使用正则表达式匹配设置条件** 从今天起，条件规则已扩展为包括两种匹配模式类型： | 模式类型 | 描述 | 最适用于 | |---|---|---| | 值匹配 (现有) | 使用全局语法进行基本模式匹配 | 具有精确或通配符匹配的路由规则 | | 正则表达式匹配 (新增) | 使用正则表达式实现更复杂的模式识别 | 复杂的路由模式和条件逻辑 | 对于前面提到的用例，在支持正则表达式之前，路由特定语言的流量需要为每种语言变体创建单独的条件。例如，在我们的用例中： - 需要一条规则用于英语 (en)。 - 需要一条规则用于法语 (fr)。 - 需要第三条规则用于所有其他语言的路由。 有了正则表达式支持，鉴于法语和英语域名都路由到运行最新 API 版本 (V2) 的同一个 EKS 集群，一条规则就可以处理这两个域名。这极大地降低了配置复杂性，并提高了路由的清晰度。 要通过控制台创建 (或修改现有 ALB 的规则) (如图 3 所示)，请按照以下步骤操作： - 导航到您的 ALB 侦听器规则。 - 选择您要修改的规则或创建一个新规则。 - 对于主机标头条件，选择“正则表达式匹配”。正则表达式匹配也可用于路径条件和 HTTP 标头条件。 - 在值字段中输入您的正则表达式模式。对于我们的用例：`^(en|fr)\\.example\\.com`  *图 3: 在条件级别配置正则表达式的示例* 可以使用正则表达式测试器进行测试，以验证语法的正确性 (如图 4 所示)：  *图 4: 用于确认条件中正则表达式有效性的语法测试器* 尽管路由功能很强大，但我们的迁移场景需要的不仅仅是引导流量。我们需要实现 URL 转换以避免修改应用程序代码。 ### **2. URL 转换：引入转换功能** 转换 (Transforms) 功能使您能够在传入请求到达后端目标之前对其进行修改。此功能位于请求处理流程中的条件和操作之间。 一个常见的用例是操作路径前缀，包括剥离、修改或添加它们。在我们的版本迁移场景中，当我们将其他语言 (如西班牙语) 迁移到 Amazon EKS 并需要将路径修改为新的 API (版本 2) 时，我们可以使用路径转换功能。要通过控制台修改路径 (如图 5 所示)，请按照以下步骤操作： - 在规则的“转换”部分下添加一个“转换 URL 路径”。 - 使用正则表达式来识别要转换的模式 (例如 `(^(en|fr|sp)\\.example\\.com\/v)1`)。 - 定义替换值 (例如，应用正则表达式语法“$12”将数字 1 替换为数字 2)。  *图 5: 使用 URL 路径配置转换* 与在条件中测试正则表达式类似，控制台包含一个方便的测试工具，可帮助您验证转换 (如图 6 所示)。  *图 6: 测试转换，其中我们看到路径中的数字 1 被替换为 2* 我们已经演示了如何将正则表达式匹配应用于路径路由条件，以及转换功能如何在无需更改代码的情况下实现路径操作。正则表达式匹配可以独立于转换与条件一起使用，转换也可以应用于标准的值匹配条件。 这种组合使得渐进式迁移策略成为可能，而无需在整个应用程序堆栈中强制进行即时、昂贵的代码更改。 ## **结论** 在这篇文章中，我们探讨了如何使用这项新功能，演示了它的实际实现，并展示了几个可以显著改善您的应用程序架构的真实场景。 正则表达式匹配和请求转换的结合，使您能够精确控制通过 ALB 流向后端服务的流量，而所有这些都无需增加额外的基础设施或更改代码。 该功能现已在 [AWS 商业区域 (AWS commercial Regions)](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)、[AWS GovCloud (美国) 区域 (AWS GovCloud (US) Regions)](https://aws.amazon.com/govcloud-us/) 和 [AWS 中国区域 (AWS China Regions)](https://www.amazonaws.cn/en/about-aws/china/) 上线。要了解有关 ALB 功能的更多信息，请查阅[应用型负载均衡器文档](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/)。如果您对本文有任何疑问，可以在 [AWS re:Post](https://repost.aws/) 上发起一个新的讨论串或联系 [AWS Support](https://aws.amazon.com/contact-us/)。 ## ## 关于作者  ### Mohamad Naji Mohamad Naji 是 Amazon Web Services 的一名资深解决方案架构师。他常驻蒙特利尔，在 IT 行业拥有超过 15 年的经验，主要服务于金融服务行业的客户。他专注于帮助客户为高度可扩展和弹性的 AWS 环境构建和开发架构。工作之余，他热爱各种体育运动，并且是一位热衷的旅行者。  ### Mahmoud Elhusseiny Mahmoud Elhusseiny 是 AWS 的一名资深解决方案架构师，服务于中东、北非和土耳其的客户。他丰富的经验横跨多个技术和行业领域，使他成为众多企业、以数字为中心的企业和独立软件供应商值得信赖的顾问，帮助他们无缝地导航和加速其云上之旅，并帮助他们创新解决方案，以增强最终用户体验并提高业务效率。 <!-- AI_TASK_END: AI全文翻译 -->