Introducing URL and host header rewrite with AWS Application Load Balancers

Today we’re announcing the general availability of rewriting URLs and host headers natively on Amazon Web Services (AWS) Application Load Balancers (ALB). You can use this new feature to implement regex matches based on request parameters and rewrite both host headers and URLs before routing to your targets.

Operating at Layer 7 (application layer) of the OSI model, ALBs distribute incoming traffic across multiple targets—such as Amazon Elastic Compute Cloud (Amazon EC2) instances, containers, AWS Lambda functions, and IP addresses—across your AWS Availability Zones (AZs). The service continuously monitors target health to make sure that traffic flows only to operational resources while automatically scaling to accommodate changing traffic patterns. Until now, implementing URL or host header modifications has necessitated either custom application logic or deploying and maintaining third-party proxy solutions.

Today’s announcement eliminates that complexity by integrating more routing capabilities directly into the ALB service. Organizations can now implement advanced request routing scenarios through their existing AWS managed infrastructure without more components. You can consolidate these functions into the ALB itself to benefit from the streamlined architecture, reduced maintenance overhead, lower costs, and decreased latency, while creating a more direct request path for your applications.

How it Works

Regex matching on conditions and URL path and host header rewrites natively on ALBs can be configured on new and existing ALBs through the AWS Management Console, AWS SDK, or AWS API. As shown in Figure 1, third-party proxies can now be fully replaced by the new native functionality of ALBs, which supports both rewriting and removing path segments from incoming requests before routing them to the appropriate target group.

Figure 1: URL rewrite on ALB with target groups

Similarly, Kubernetes users, particularly those using the ALB Ingress Controller, needed path rewriting to properly route traffic to containerized services. They had to implement proxies, such as NGINX Ingress Controller, which added unnecessary complexity to Amazon Elastic Kubernetes Service (Amazon EKS) deployments. The new ALB feature (as shown in Figure 2) now enables users to fully use ALBs while streamlining their microservices architectures.

 Figure 2: URL rewrite on ALB with EKS target groups

To demonstrate this with an example, we consider the following scenario: An international company maintains an application supporting multiple languages. The architecture is currently split into:

• • French and English backends: already migrated and deployed on Amazon EKS and running with the latest API version 2 (V2).
  • All other language backends: Currently operating on EC2 instances using the legacy API version 1 (V1).

The company is progressively migrating all languages traffic to run on Amazon EKS. It supports the latest API version (V2) and needs to handle URL versioning transparently without modifying any frontend application code.

1. Rules streamlining: setting up conditions with regex matching 

Starting today, the Conditions rules have expanded to include two match pattern types:

For the use case mentioned previously, before regex support, routing language-specific traffic necessitate creating separate conditions for each language variant. For example, in our use case:

• • One rule was needed for English (en).
  • One rule was needed for French (fr).
  • A third rule was needed for all other language routes.

With regex support, given that both French and English domains are routed to the same EKS cluster running the latest API version (V2), a single rule can handle both domains. This dramatically reduces configuration complexity and provides routing clarity.

To create (or modify the rule for existing ALBs) through the console (as shown in Figure 3), follow these steps:

• • Navigate to your ALB listener rules.
  • Choose the rule you want to modify or create a new one.
  • For host header conditions, choose Regex matching. Regex matching can also be used for path conditions and HTTP header conditions.
  • Enter your regex pattern in the value field. For our use case: ^(en|fr)\.example\.com

Figure 3: Regex configuration example at the conditions level

A test can be performed using the Regex tester to verify the correct syntax (as shown in Figure 4):

Figure 4: Regex syntax tester to confirm validity of Regex expressions on conditions

Although routing is powerful, our migration scenario necessitates more than just directing traffic. We need to implement URL transformation to avoid modifying the application code.

2. URL transformation: introducing transforms

Transforms enable you to modify incoming requests before they reach your backend targets. This functionality is positioned between your conditions and actions in the request processing flow.

A common use case is the manipulation of path prefixes, which includes stripping, modifying, or adding them. In our version migration scenario, when we migrate other languages (such as Spanish) to Amazon EKS and need to modify the path to the new API (version 2), we can use the path transforms capability. To modify the path through the console (as shown in Figure 5) follow these steps:

• • Add a Transform URL path under the Transforms section in your rule.
  • Use regex to identify the pattern to transform (for example (^(en|fr|sp)\.example\.com\/v)1).
  • Define the replacement value (for example apply the regex syntax “$12” to replace number 1 with number 2).

Figure 5: Configuring transforms with URL path

Similar to testing with Regex in conditions, the console includes a convenient testing tool that helps you validate your transforms (as shown in Figure 6).

Figure 6: Testing transforms where we see number 1 replaced by 2 in the path

We have demonstrated how regex matching can be applied to path routing conditions and how the transforms capability enables path manipulation without necessitating code changes. Regex matching can be used with conditions independently of transforms, and transforms can be applied to standard value matching conditions.

This combination enables gradual migration strategies without forcing immediate, costly code changes throughout the entire application stack.

Conclusion

In this post, we explored how to use this new feature, demonstrating its practical implementation and showcasing several real-world scenarios where it can significantly improve your application architecture.

This combination of regex matching and request transforms provides control over traffic flows through your ALB to your backend services, all without needing more infrastructure or code changes.

This feature is now available in AWS commercial Regions, AWS GovCloud (US) Regions and AWS China Regions. To learn more about ALB capabilities, consult the Application Load Balancer documentation. If you have questions about this post, then you can start a new thread on AWS re:Post or contact AWS Support.

About the authors