New – Advanced Request Routing for AWS Application Load Balancers
- March 28, 2019
AWS Application Load Balancers have been around since the summer of 2016! They support content-based routing, work well for serverless & container-based applications, and are highly scalable. Many AWS customers are using the existing host and path-based routing to power their HTTP and HTTPS applications, while also taking advantage of other ALB features such as port forwarding (great for container-based applications), health checks, service discovery, redirects, fixed responses, and built-in authentication.
Advanced Request Routing
The host-based routing feature allows you to write rules that use the
Host header to route traffic to the desired target group. Today we are extending and generalizing this feature, giving you the ability to write rules (and route traffic) based on standard and custom HTTP headers and methods, the query string, and the source IP address. We are also making the rules and conditions more powerful; rules can have multiple conditions (AND’ed together), and each condition can specify a match on multiple values (OR’ed).
You can use this new feature to simplify your application architecture, eliminate the need for a proxy fleet for routing, and to block unwanted traffic at the load balancer. Here are some use cases:
Using Advanced Request Routing
You can use this feature with your existing Application Load Balancers by simply editing your existing rules. I will start with a simple rule that returns a fixed, plain-text response (the examples in this post are for testing and illustrative purposes; I am sure that yours will be more practical and more interesting):
I can use
curl to test it:
I click Insert Rule to set up some advanced request routing:
Then I click Add condition and examine the options that are available to me:
I select Http header, and create a condition that looks for a cookie named
user with value
jeff. Then I create an action that returns a fixed response:
I click Save, wait a few seconds for the change to take effect, and then issue a pair of requests:
I can also create a rule that matches one or more CIDR blocks of IP addresses:
I can match on the query string (this is very useful for A/B testing):
I can also use a wildcard if all I care about is the presence of a particular field name:
I can match a standard or custom HTTP method. Here, I will invent one called READ:
I have a lot of flexibility (not new, but definitely worth reviewing) when it comes to the actions:
Forward to routes the request to a target group (a set of EC2 instances, a Lambda function, or a list of IP addresses).
Redirect to generates a 301 (permanent) or 302 (found) response, and can also be used to switch between HTTP and HTTPS.
Return fixed response generates a static response with any desired response code, as I showed you earlier.
Authenticate uses Amazon Cognito or an OIDC provider to authenticate the request (applicable to HTTPS listeners only).
Things to Know
Here are a couple of other things that you should know about this cool and powerful new feature:
Metrics – You can look at the Rule Evaluations and HTTP fixed response count CloudWatch metrics to learn more about activity related to your rules (learn more):
Rule Matching – The rules are powered by string matching, so test well and double-check that your rules are functioning as intended. The matched_rule_priority and actions_executed fields in the ALB access logs can be helpful when debugging and testing (learn more).
Limits – Each ALB can have up to 100 rules, not including the defaults. Each rule can reference up to 5 values and can use up to 5 wildcards. The number of conditions is limited only by the number of unique values that are referenced.
Advanced request routing is available now in all AWS regions at no extra charge (you pay the usual prices for the Application Load Balancer).