Route requests with ACL rules

ACL rules let one Application Load Balancer (ALB) serve several applications. Each rule matches a request by its path, its host name, a query parameter, its HTTP method, or the client’s IP, and sends it to the backend group you choose. For example, requests for /api can go to your API servers and everything else to your website.

The load balancer checks the rules from the top of the list down, and the first rule that matches decides the backend group. A request that matches no rule goes to the first backend group on Backend Mapping, the one you added first. Backend groups keep the order in which you added them. Rules apply to HTTP and HTTPS requests alike, on external and internal load balancers.

Before you begin

• You have an ALB; the ACL tab is on ALBs only. See Create an Application Load Balancer.
• The ALB has a backend group for each application. See Manage backend groups and servers.
• The load balancer is powered on, and has left Creating, Deploying, or Deleting.
• Your role in the project has the update permission for Load Balancers.

Add a rule

1. In MyAccount, under Compute, click Load Balancers, click the load balancer, and open its ACL tab. The table lists each rule’s Name, Type, Value, and Backend. With no rules yet, it says No ACLs are available.
2. Click Add ACL. The rule’s form opens.
3. Enter a Name of up to 32 characters, using letters, digits, underscores, and hyphens. Each rule needs its own name.
4. Choose an ACL type, then the condition and the value. Each type is described under Choose the ACL type.
5. Under Backend Group, choose the group that takes the matching requests.
6. Click Submit to add the rule to the list, then click Save and Deploy.

Choose the ACL type

ACL type	Matches	You enter	Conditions
Path Based, the default	The request path, without the query string	One or more paths in Path, separated by spaces, such as /api /v2	exact match, prefix match, suffix match, or regex match, ignoring case, or the same four marked (Case Sensitive)
Host Based	The host name the client asked for, ignoring case	A host name in Host or URL, such as shop.example.com	exact match, prefix match, suffix match, or regex match
Query Parameters Match	One query parameter, ignoring case	The parameter’s Key and Value	exact match, prefix match, suffix match, or regex match
HTTP Request Method	The request’s method	One or more of HEAD, OPTIONS, GET, POST, PUT, DELETE, CONNECT, and TRACE; GET to start with	-
Source IP	The client’s IPv4 address, exactly	One address, such as 203.0.113.10	exact match

Under Path Based, each condition compares the request’s path with the paths you entered:

• exact match matches a path that is one of them.
• prefix match matches a path that starts with one of them.
• suffix match matches a path that ends with one of them.
• regex match matches a path that fits the pattern you entered.

The plain conditions ignore case, and the ones marked (Case Sensitive) match the case exactly. Host Based compares the host the client asked for in the same four ways, ignoring case. When the client sends a port with the host, such as shop.example.com:8080, the port is part of the host.

Choose by what tells your applications apart:

• Path Based for one domain with different sections, such as /api and /shop.
• Host Based for several domains or subdomains on one load balancer. For HTTPS, the load balancer holds one certificate. Use a wildcard or multi-domain certificate that covers every name. See Add an SSL certificate.
• Query Parameters Match to send requests with a given parameter, such as a version, to other servers.
• HTTP Request Method to split reads from writes, such as GET to one group and POST to another.
• Source IP to send one client, such as your office, to a test group. It takes one address at a time.

After you save, the Type column shows the condition the rule uses, such as path, method, or src, rather than the type’s name from the form.

Put the rules in order

The first rule that matches wins, so put the narrow rules above the broad ones. For example, put an exact match for /api/health above a prefix match for /api.

1. Drag a rule to its new place in the list. A reminder, Click on ‘Save Button’ to save the changes, appears.
2. Click Save and Deploy.

Add ACL is available again once you save the new order.

Change a rule

1. On the ACL tab, edit the rule’s row. The rule’s form opens, filled in.
2. Change the name, the type, the condition, the value, or the backend group.
3. Click Submit, then click Save and Deploy.

Remove a rule

1. On the ACL tab, delete the rule’s row, and confirm.
2. Click Save and Deploy.

Removing a backend group on Backend Mapping also removes the rules that send traffic to it.

Save and deploy the rules

1. On the ACL tab, click Save and Deploy.
2. Confirm the update in Update Backend.

The change takes about five to 10 minutes, and the load balancer reads Deploying meanwhile. Connections your clients already have open stay open while the new rules are applied.

Save before you leave the tab, or your changes are discarded.

Check that requests reach the right group

When the load balancer reads Running again, send a request that one of your rules matches, where <your-domain> is a name pointed at the load balancer:

curl -i http://<your-domain>/api/

On a load balancer that serves HTTPS only or has HTTP Redirect on, send the request over HTTPS instead:

curl -i https://<your-domain>/api/

The answer comes from the servers of the group that rule points at. A request that matches no rule is answered by the first backend group. To see which group answered, have each group’s servers return something different, such as a page that names the group.

If every request still reaches the first group, or a rule will not save, see Troubleshooting Load Balancer.