Native URL and Host Header Rewrite with AWS Application Load Balancer (ALB)
- Written by:
- Hiten Vadaliya
- AWS
- No Comments
As applications grow, change becomes unavoidable. APIs evolve, services move to containers, and legacy systems are gradually modernized. The real challenge is not updating the backend itself, but doing it without breaking existing URLs or frontend integrations.
For a long time, teams solved this problem by using reverse proxies like NGINX or by adding rewrite logic directly into application code. While these approaches work, they also introduce extra infrastructure, more configuration, and higher operational overhead.
AWS has now introduced a cleaner and simpler solution:
Native URL and host header rewrite support in Application Load Balancers (ALB).
This feature allows you to rewrite request paths and host headers directly at the load balancer layer, with optional regex support, without changing application code or deploying additional proxy services.
In this blog, we explain what this feature is, why it matters, and how it can simplify real-world architectures.
What Changed in AWS Application Load Balancer?
AWS Application Load Balancer operates at Layer 7 (the application layer) and routes HTTP and HTTPS traffic to backend targets such as EC2 instances, containers, or serverless services.
Traditionally, ALB could route traffic based on:
- URL paths
- Host headers
- HTTP headers
- Query parameters
However, it could not modify the request itself.
With the latest update, ALB can now:
- Match requests using regular expressions
- Rewrite URL paths
- Rewrite host headers
- Apply these changes before forwarding traffic to backend services
This makes ALB a much more capable and flexible request processing component.
Why This Feature Matters in Real Architectures
Before native rewrite support was available, teams usually had two choices.
1. Application-Level Rewrites
Rewriting URLs directly inside application code.
- Hard to maintain
- Risky during migrations
- Requires code changes across multiple services
2. Reverse Proxy (NGINX, Envoy, and others)
Placing a proxy in front of the application.
- Additional infrastructure
- More configuration to manage
- Extra monitoring and maintenance
- An extra network hop for every request
Both approaches add complexity.
With native ALB rewrite:
- No extra servers are require
- No additional proxies are needed
- No application code changes are necessary
- Everything is managed by AWS
This results in:
- Simpler architecture
- Lower cost
- Reduced latency
Faster and safer migrations
How ALB Rewrite Works
ALB now processes incoming requests in three clear steps.
1. Conditions: Which requests should match?
Conditions determine whether a rule applies to a request. Matching can be done using:
- Path
- Host header
- Headers
- Query strings
Regex matching is now supported for these conditions.
2. Transforms: How should the request be modified?
Transforms allow ALB to modify the request before it reaches the backend. You can:
- Rewrite the URL path
- Rewrite the host header
All of this happens inside the ALB, without the backend being aware of it.
3. Actions: Where should the request go?
Finally, ALB forwards the modified request to the appropriate target group.
Regex Matching: Fewer Rules, Cleaner Design
Regex support significantly reduces the number of listener rules required.
Example: Language-Based Domains
Without regex support:
- One rule for
en.example.com - One rule for
fr.example.com - One rule for
es.example.com
With regex support, a single rule can be used: ^(en|fr|es)\.example\.com$
One rule replaces many.
Regex matching can be applied to:
- Host headers
- URL paths
- HTTP headers
This improves readability, reduces duplication, and lowers the chance of configuration errors.
URL Rewrite: Change Backend Paths Without Breaking URLs
URL rewrite is one of the most powerful and commonly used features.
Example Scenario
A client sends a request to: https://example.com/app1/orders/123
ALB rewrites the request internally to: /site1/orders/123
The backend application receives: /site1/orders/123
The client URL remains unchanged.
Regex-Based URL Rewrite Example
Regex makes it possible to perform dynamic rewrites while preserving subpaths.
Match: ^/app1/?(.*)$
Replace: /site1/$1
/app1/app1//app1/test/app1/api/v1/users
All of these are handled natively by ALB.
Host Header Rewrite: When Backends Expect a Different Domain
Some applications rely on the Host header for correct behavior, such as:
- Virtual hosts in Apache or NGINX
- Legacy services tied to specific domains
- Multi-tenant applications
- ALB can rewrite the Host header before forwarding the request.
Example
Client sends: Host: api.example.com
ALB forwards: Host: service.internal.local
Combining Regex, URL Rewrite, and Host Rewrite
The real power of this feature comes from combining multiple capabilities:
- Regex-based conditions to match requests
- URL rewrite to adjust paths
- Host header rewrite to control backend behavior
This enables advanced scenarios such as:
- API version migrations
- Gradual microservice rollouts
- Multi-language platforms
- Legacy system modernization
All without touching application code.
Ideal Use Cases
Native ALB rewrite is especially useful for:
- Migrating APIs from v1 to v2
- Moving services from EC2 to containers or EKS
- Consolidating multiple services behind a single domain
- Removing NGINX instances used only for rewrites
- Simplifying Kubernetes ingress configurations
For many teams, ALB alone is now sufficient.
Key Benefits Summary
- Fully AWS-managed solution
- No additional infrastructure
- Regex-based routing and rewriting
- Lower operational overhead
- Reduced latency
- Cleaner and more maintainable architectures
- Safe and gradual migrations
Final Thoughts
Native URL and host header rewrite in AWS Application Load Balancers is a meaningful improvement for modern cloud architectures.
It eliminates the need for extra proxies, simplifies migration strategies, and gives teams precise control over request routing, all while staying within AWS-managed infrastructure.
If you are still using reverse proxies solely for path or host rewrites, this feature is well worth adopting.