TCP# 58: Mastering Routing Strategies with AWS Application Load Balancers (ALBs)
Architect-grade traffic control for cloud-native apps
You can also read my newsletters from the Substack mobile app and be notified when a new issue is available.
I offer many free resources. If you haven't already done so, check out my store at Gumroad.
Most engineers consider AWS Application Load Balancers as “load balancers.”
They’re programmable HTTP routers capable of shaping traffic across multi-region, multi-service, and multi-tenant applications.
In this issue, we’ll explore 7 advanced ALB routing strategies every cloud and platform engineer should know and how to combine them for safer deployments, better user experiences, and infrastructure simplification.
Let’s go deep.
1. Host-based routing: Scale microservices by domain
What it is:
Routes traffic to different target groups based on the Host header in the HTTP request (i.e., the domain/subdomain).
When to use it:
Multi-tenant SaaS platforms (
client1.yoursaas.com,client2.yoursaas.com)Modular service domains (
api.yoursite.com,admin.yoursite.com,cdn.yoursite.com)Seamless transitions between v1 and v2 APIs hosted on subdomains
Architecture Tips:
Create listener rules on ALB for each domain pattern
Use AWS Certificate Manager to provision TLS for each domain and attach to the ALB via SNI
Set up Route 53 or Cloudflare to route DNS traffic to the correct ALB listener
Edge Cases & Gotchas:
Wildcard domains (
*.domain.com) require careful matching — no support for multiple wildcardsTLS requires ACM certificates for each wildcard or SAN name
Set up domain validation automation with DNS for seamless cert rotation
2. Path-Based Routing: Divide backend services by URL path
What it is:
Routes based on the request URI path, enabling clean separation of microservices under a single domain.
When to use it:
Microservice split by path (e.g.,
/users,/billing,/auth)Monolith-to-microservices migration
Public vs private route segmentation on the same domain
Architecture Tips:
Define listener rules like
/api/v1/* → target group A,/auth/* → target group BNormalize paths across services for consistency. Decide early on whether to enforce or strip trailing slashes.
Make sure your backend apps don’t choke on forwarded paths (use
X-Forwarded-*headers for context)
Edge Cases & Gotchas:
Be careful with overlapping paths (
/apivs/api/v1). ALB stops at first matching ruleSet listener priority to enforce path matching order
Use redirects (
/ → /app) to clean up entry points or default routes
3. Header-based routing: Routes by user type, feature flags, or device type
What it is:
Routes requests are based on custom HTTP headers sent by the client, which are handy for internal environments and progressive delivery.
When to use it:
Canary deployments (e.g., only route traffic with
X-Beta-User: true)Admin/debug-only service access
Serving different backends for mobile vs desktop clients
Architecture Tips:
Use conditionally attached headers from front end, API Gateway, or WAF
Maintain a consistent contract for internal headers — don't use generic names
Route to distinct target groups for each version/environment
Edge Cases & Gotchas:
Headers can be spoofed — add WAF rules or token-based auth to protect sensitive routing
ALB routing is not regex-based — use exact string match only
Combine with weighted routing for granular canary rollout
4. Query String Parameter Routing: Experimental routing for precision control
What it is:
Routes are based on exact matches of query string key-value pairs in the URL.
When to use it:
Early-stage testing environments (
/?env=dev)Regional traffic routing (
/?region=eu)Toggling between experimental models or services on the same path
Architecture Tips:
Only for internal or development use cases
Combine with header-based routing for better control
Use target group stickiness if needed to preserve session integrity
Edge Cases & Gotchas:
URL encoding issues can break routing logic (
%20vs+)High TTL on client-side caching can interfere with routing response
Not suitable for production-facing user features — too easy to spoof or break
5. Source IP Routing: Secure routing by geography or corporate IP
What it is:
Routes based on the source IP address of the client request are valid for internal apps, hybrid environments, and regulatory boundaries.
When to use it:
Internal tools exposed only to office networks
Country-specific compliance routing
Regional data residency enforcement (e.g., only route EU traffic to eu-west-1)
Architecture Tips:
Use
X-Forwarded-Forheader, ALBs are behind AWS infrastructureCombine with WAF IP sets for dynamic access control
For complex IP range management, automate updates via Lambda or Systems Manager
Edge Cases & Gotchas:
Proxies and mobile carriers often mask IPs. Don’t assume accuracy
Spoofed
X-Forwarded-Forheaders are common. Verify via known upstream sourcesMust maintain IP allowlists. This is not geo-DNS
6. Weighted Target Groups: The safest way to deploy in prod
What it is:
Split traffic between multiple target groups with different weights, letting you gradually roll out new services or app versions.
When to use it:
Blue/green deployments
Canary testing new code, infra, or container images
A/B testing business logic with observability layers
Architecture Tips:
Use weighted listener rules with individual health checks
Automate rollout progression (e.g., 5% → 25% → 50%) using CodeDeploy or custom scripts
Route failed requests to an isolated monitoring group for analysis
Edge Cases & Gotchas:
Health check misconfigurations can silently reroute traffic
Session stickiness complicates weight distribution
Pair with monitoring/alerting (e.g., CloudWatch, Datadog) to detect regressions early
7. Redirects & Fixed Responses: Handle some traffic with no backend at all
What it is:
Use the ALB itself to serve static responses or HTTP redirects, reducing the need for backend servers or logic.
When to use it:
HTTP → HTTPS redirection
Static maintenance pages during deploys
Legal/compliance redirects (
/gdpr→ privacy portal)
Architecture Tips:
Use fixed-response rules for error pages, outage messages, or temporary rejections.
Use redirect rules for vanity URLs (
/blog→blog.yoursite.com)Works best in front of CloudFront for global delivery
Edge Cases & Gotchas:
Only supports basic HTML, not templated or dynamic
Clients may cache redirects aggressively, set cache-control headers properly
Doesn’t replace a true content management system; use for infra-level UX
Pro Tips for Mastering ALB Routing
Use CloudWatch Metrics (
TargetResponseTime,UnhealthyHostCount) to monitor routing impactTurn on ALB Access Logs. Most teams forget this, but it’s gold for debugging
Use priority ordering in listener rules. The most specific should come first
Automate your ALB configuration using AWS CDK or Terraform for repeatability
Combine with Route 53 routing (e.g., geolocation, latency) for multi-layer control
Final Thoughts
With smart ALB rules, you can:
Deploy without fear using weighted rollouts
Serves global traffic with lower latency and fewer bottlenecks
Simplify your architecture by pushing complexity to the edge
Most teams leave these tools untouched.
But if you’re reading this, you now know how to build modern, observable, and resilient systems without adding extra services.
SPONSOR US
The Cloud Playbook is now offering sponsorship slots in each issue. If you want to feature your product or service in my newsletter, explore my sponsor page
That’s it for today!
Did you enjoy this newsletter issue?
Share with your friends, colleagues, and your favorite social media platform.
Until next week — Amrut
Get in touch
You can find me on LinkedIn or X.
If you wish to request a topic you would like to read, you can contact me directly via LinkedIn or X.