An In-Depth Guide to Implementing Path-Based Routing with Application Load Balancers

Application Load Balancers (ALBs) provide a robust way to intelligently distribute inbound HTTP/HTTPS traffic across multiple targets in Amazon Web Services (AWS).

One of the most powerful traffic distribution mechanisms offered by ALBs is path based routing. This technique can unlock new architectural possibilities for high-scale applications.

In this comprehensive guide, we will dive deep into the components, capabilities, use cases and best practices for path based routing with ALBs on AWS.

Overview of Load Balancing in AWS

Before jumping into path based routing specifics, let‘s establish some context by first reviewing load balancing within AWS.

Types of Load Balancers

AWS offers a few load balancing options suitable for different use cases:

1. Classic Load Balancer (CLB)

   Best suited for simple traffic distribution across EC2 instances using TCP/SSL protocols. Does not support advanced routing or container targets.

2. Network Load Balancer (NLB)

   Operates at connection level (Layer 4) to route traffic to targets within a VPC based on IP protocol data. Ultra-high performance makes NLB ideal for TCP/UDP traffic.

3. Application Load Balancer (ALB)

   Operates at request level (Layer 7) and evaluates contents of HTTP/HTTPS requests to intelligently route users. Best fit for modern web/mobile apps.

ALB delivers essential capabilities like path based routing that we will leverage in our architecture.

Components of an ALB

An ALB is made up of various high-level components working together:

• Listener – Checks for user requests using a specific protocol and port
• Rule – Applies criteria to listener traffic and routes requests to suitable target group
• Target Group – Group of targets like EC2 instances to receive matched requests
• Targets – Destinations to process routed requests like EC2, containers or IP addresses

Multiple listeners can funnel requests to different target groups based on rules defined for that listener.

Path Based Routing Fundamentals

Path based routing is a traffic distribution technique available exclusively with Application Load Balancers on AWS.

As the name suggests, path based routing works by evaluating the URL path in the incoming HTTP/HTTPS requests to determine where to route the traffic.

Path Based Routing Logic Flow

When a client sends requests to an ALB‘s listener, the high-level logic flow is as follows:

1. Check request protocol and port against ALB‘s listeners
2. Match listener, extract URL path
3. Evaluate path condition on rules to find first match
4. Route request to target group specified in rule action

So essentially, we configure rules that match certain URL path patterns, and then forward matching requests downstream to appropriate target groups for processing.

Some examples of common path based routing use cases:

• Route /api* requests to API servers and /app* requests to webservers
• Route /users* to user management target group and /products* to product catalog group
• Use path conditions for blue-green or A/B deployments

As you can see, we can intelligently segment traffic for better efficiency and resiliency.

Next let‘s go through a hands-on example to implement path routing.

Example: Routing Traffic Based on URL Path

We will use an Application Load Balancer configured with path based rule to route requests.

The key components include:

• ALB with a listener for HTTP traffic on port 80
• Two target groups:
  • Blue target for /blue* traffic
  • Green target for /green* traffic
• Separate EC2 instances registered with each target group

Here are the steps involved:

Step 1. Create target groups

First, create two target groups naming them blue-tg and green-tg within the same VPC.

Next, register EC2 instances with these groups:

blue-tg -> i-0123ab45cd (Blue) 
green-tg -> i-5678ef90ab (Green)

Target groups created.

Step 2. Configure ALB listener and default action

When creating the ALB, set it up with an HTTP listener on port 80.

Define the default action to route to any requests without
a matching rule path to the blue-tg target group.

This is the fallback logic when no path rules match.

Step 3. Define path based routing rules

Under the ALB, edit the rules for the HTTP listener.

Add two rules as follows with forward to action:

Rule 1

When path is /green* 
Then forward to green-tg

Rule 2

When path is /blue*
Then forward to blue-tg

Rule 1 will route any /green* requests hitting ALB listener to the green target group.

Rule 2 will forward /blue* requests to blue group.

This completes the path based routing configuration.

Step 4. Testing

With the ALB deployed, we can test the setup by accessing:

http://alb.url/green/index.html

and  

http://alb.url/blue/index.html

The first request should hit our "Green" EC2 instances and second one "Blue" instances verifying successful path based routing.

This demonstrates the fundamental mechanism involved in building path based rules for an ALB.

Prioritizing Rules

When there are multiple rules configured, you can explicitly specify their evaluation priority ordering.

Rules with lower numeric priority values are checked first.

For example:

Rule 1

Priority: 10
Path: /admin*
Target Group: admin-tg 

Rule 2

Priority: 20 
Path: /*
Target Group: main-tg

Here Rule 1 will be checked before Rule 2. So requests to /admin will match first and route to admin-tg target group.

Whereas requests without that prefix will next flow to Rule 2 as the fallback.

Combining Host and Path Conditions

Rules can also check both the host header as well as path pattern by combining two conditions.

For example, requests for app.mydomain.com only with /status path can be routed to a target group using both host and path checks.

This provides greater flexibility to match desired traffic.

Comparing Path Based Routing to Host Based Routing

In addition to path based routing, ALBs also offer another mechanism – host based routing.

Let‘s compare the two approaches.

Host Based Routing

With host based routing, rules are configured to match the Host header in the HTTP request and route to appropriate target groups.

For example:

When host header is acme.com 
Then forward to acme-tg

When host header is apex.com
Then forward to apex-tg 

This approach is very useful for consolidating multiple domains onto a single load balancer.

Key Differences

While host and path based routing have some overlap in capabilities, there are some distinct differences:

	Path Based	Host Based
Scope	Directory/Path	Host/Domain
Matches On	URL Path	Host Header
Use Cases	Microservices Routing	Multi-domain Routing

In most cases, path and host based routing complement each other for advanced traffic management rather than being mutually exclusive alternatives.

Architecting the Target Groups

A key benefit unlocked by path or host based routing is the ability to isolate different types of traffic to appropriate target groups.

This allows us to architect the backend in a modular fashion for efficiency and resiliency.

As a lead architect or full stack engineer, consider some of these strategies when designing your target groups.

Horizontal Scaling

For high traffic endpoints, add more targets like EC2 instances to scale horizontally. Some options are:

Auto Scaling Groups

Configure auto scaling groups so targets scale out automatically based on load.

Multi-AZ

Distribute targets across multiple availability zones for fault tolerance.

ELB Sandwich

Insert a Network Load Balancer(NLB) in front of each target group and scale the NLB targets horizontally.

Vertical Scaling

For increased computing capacity, leverage instances with additional CPU, RAM and optimized networking.

For example, targets could scale vertically across instance types like:

t2.micro -> t2.large -> m4.xlarge -> m5.2xlarge etc.

Separation of Concerns

Split out functionally distinct components into individual target groups:

• Keep frontend, backend, caching, and databases in separate groups
• Maintain isolated dev, test and production environments

This improves organization and containment.

Implementation Best Practices

Here are some key best practices to follow when working with path based routing:

• Use Friendly Rule Names – Use clear rule names describing the pattern, target and purpose rather than accepting default names. E.g. "Route /api to API Target Group". This improves understandability.

• Monitor Target Group Health – Actively monitor the health of underlying targets like EC2 instances. Unhealthy targets should be examined and replaced promptly.

• Implement Custom Error Pages – Create custom error handling pages for common codes like 500 & 503 to improve user experience during issues.

• Enable Access Logs – Stream logs from the ALB itself to analyze traffic patterns and debug routing issues.

• Consider Security Groups – Restrict access to load balancer using security groups where possible to enhance security posture.

Summary

In this detailed guide, we took a comprehensive look at implementing path based routing with Application Load Balancers.

Here are some key takeaways around the capabilities and best practices:

• Path based routing provides a powerful way to segment traffic to appropriate target groups
• Rules check the URL path to selectively route HTTP requests
• Priority levels can be set if needed for rule evaluation order
• Both path and host conditions can be combined for greater precision
• Auto scaling target groups horizontally and vertically helps achieve high resiliency
• Following standards and recommendations helps setup a robust system

I hope this gives you a firm understanding of the mechanisms and possibilities unlocked by path based routing on AWS. Feel free to post any other questions in comments!