Elastic Load Balancing
Application Load Balancers

Listeners for Your Application Load Balancers

Before you start using your Application Load Balancer, you must add one or more listeners. A listener is a process that checks for connection requests, using the protocol and port that you configure. The rules that you define for a listener determine how the load balancer routes requests to its registered targets.

Listener Configuration

Listeners support the following protocols and ports:

  • Protocols: HTTP, HTTPS

  • Ports: 1-65535

You can use an HTTPS listener to offload the work of encryption and decryption to your load balancer so that your applications can focus on their business logic. If the listener protocol is HTTPS, you must deploy at least one SSL server certificate on the listener. For more information, see Create an HTTPS Listener for Your Application Load Balancer.

Application Load Balancers provide native support for WebSockets. You can use WebSockets with both HTTP and HTTPS listeners.

Application Load Balancers provide native support for HTTP/2 with HTTPS listeners. You can send up to 128 requests in parallel using one HTTP/2 connection. The load balancer converts these to individual HTTP/1.1 requests and distributes them across the healthy targets in the target group. Because HTTP/2 uses front-end connections more efficiently, you might notice fewer connections between clients and the load balancer. You can't use the server-push feature of HTTP/2.

For more information, see Request Routing in the Elastic Load Balancing User Guide.

Listener Rules

Each listener has a default rule, and you can optionally define additional rules. Each rule consists of a priority, one or more actions, and one or more conditions. You can add or edit rules at any time. For more information, see Edit a Rule.

Default Rules

When you create a listener, you define actions for the default rule. Default rules can't have conditions. If the conditions for none of a listener's rules are met, then the action for the default rule is performed.

The following is an example of a default rule as shown in the console:


                    The default rule for a listener.

Rule Priority

Each rule has a priority. Rules are evaluated in priority order, from the lowest value to the highest value. The default rule is evaluated last. You can change the priority of a nondefault rule at any time. You cannot change the priority of the default rule. For more information, see Reorder Rules.

Rule Actions

Each rule action has a type, an order, and the information required to perform the action. For more information, see Rule Action Types.

Rule Conditions

Each rule condition has a type and configuration information. When the conditions for a rule are met, then its actions are performed. For more information, see Rule Condition Types.

Rule Action Types

The following are the supported action types for a rule:

authenticate-cognito

[HTTPS listeners] Use Amazon Cognito to authenticate users. For more information, see Authenticate Users Using an Application Load Balancer.

authenticate-oidc

[HTTPS listeners] Use an identity provider that is compliant with OpenID Connect (OIDC) to authenticate users.

fixed-response

Return a custom HTTP response. For more information, see Fixed-Response Actions.

forward

Forward requests to the specified target group.

redirect

Redirect requests from one URL to another. For more information, see Redirect Actions.

The action with the lowest order value is performed first. Each rule must include exactly one of the following actions: forward, redirect, or fixed-response, and it must be the last action to be performed.

Fixed-Response Actions

You can use fixed-response actions to drop client requests and return a custom HTTP response. You can use this action to return a 2XX, 4XX, or 5XX response code and an optional message.

When a fixed-response action is taken, the action and the URL of the redirect target are recorded in the access logs. For more information, see Access Log Entries. The count of successful fixed-response actions is reported in the HTTP_Fixed_Response_Count metric. For more information, see Application Load Balancer Metrics.

Example Fixed Response Action for the AWS CLI

You can specify an action when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following action sends a fixed response with the specified status code and message body.

[ { "Type": "fixed-response", "FixedResponseConfig": { "StatusCode": "200", "ContentType": "text/plain", "MessageBody": "Hello world" } } ]

Forward Actions

You can use forward actions route requests to the specified target group.

Example Forward Action for the AWS CLI

You can specify an action when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following action forwards the request to the specified target group.

[ { "Type": "forward", "TargetGroupArn": "arn:aws:elasticloadbalancing:us-west-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a06" } ]

Redirect Actions

You can use redirect actions to redirect client requests from one URL to another. You can configure redirects as either temporary (HTTP 302) or permanent (HTTP 301) based on your needs.

A URI consists of the following components:

protocol://hostname:port/path?query

You must modify at least one of the following components to avoid a redirect loop: protocol, hostname, port, or path. Any components that you do not modify retain their original values.

protocol

The protocol (HTTP or HTTPS). You can redirect HTTP to HTTP, HTTP to HTTPS, and HTTPS to HTTPS. You cannot redirect HTTPS to HTTP.

hostname

The hostname. A hostname is case-insensitive, can be up to 128 characters in length, and consists of alpha-numeric characters, wildcards (* and ?), and hyphens (-).

port

The port (1 to 65535).

path

The absolute path, starting with the leading "/". A path is case-sensitive, can be up to 128 characters in length, and consists of alpha-numeric characters, wildcards (* and ?), & (using &), and the following special characters: _-.$/~"'@:+.

query

The query parameters.

You can reuse URI components of the original URL in the target URL using the following reserved keywords:

  • #{protocol} - Retains the protocol. Use in the protocol and query components

  • #{host} - Retains the domain. Use in the hostname, path, and query components

  • #{port} - Retains the port. Use in the port, path, and query components

  • #{path} - Retains the path. Use in the path and query components

  • #{query} - Retains the query parameters. Use in the query component

When a redirect action is taken, the action is recorded in the access logs. For more information, see Access Log Entries. The count of successful redirect actions is reported in the HTTP_Redirect_Count metric. For more information, see Application Load Balancer Metrics.

Example Redirect Actions Using the Console

The following rule sets up a permanent redirect to a URL that uses the HTTPS protocol and the specified port (40443), but retains the original hostname, path, and query parameters. This screen is equivalent to "https://#{host}:40443/#{path}?#{query}".


                        A rule that redirects the request to a URL that uses the HTTPS protocol and the specified port
                            (40443), but retains the original domain, path, and query parameters of the original URL.

The following rule sets up a permanent redirect to a URL that retains the original protocol, port, hostname, and query parameters, and uses the #{path} keyword to create a modified path. This screen is equivalent to "#{protocol}://#{host}:#{port}/new/#{path}?#{query}".


                        A rule that redirects the request to a URL that retains the original protocol, port, hostname, and 
                            query parameters, and uses the #{path} keyword to create a modified path.

Example Redirect Action for the AWS CLI

You can specify an action when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following action redirects an HTTP request to an HTTPS request on port 443, with the same host name, path, and query string as the HTTP request.

[ { "Type": "redirect", "RedirectConfig": { "Protocol": "HTTPS", "Port": "443", "Host": "#{host}", "Path": "/#{path}", "Query": "#{query}", "StatusCode": "HTTP_301" } } ]

Rule Condition Types

The following are the supported condition types for a rule:

host-header

Route based on the host name of each request. For more information, see Host Conditions.

http-header

Route based on the HTTP headers for each request. For more information, see HTTP Header Conditions.

http-request-method

Route based on the HTTP request method of each request. For more information, see HTTP Request Method Conditions.

path-pattern

Route based on path patterns in the request URLs. For more information, see Path Conditions.

query-string

Route based on key/value pairs or values in the query strings. For more information, see Query String Conditions.

source-ip

Route based on the source IP address of each request. For more information, see Source IP Address Conditions.

Each rule can include zero or one of the following conditions: host-header, http-request-method, path-pattern, and source-ip, and zero or more of the following conditions: http-header and query-string.

You can specify up to three match evaluations per condition. For example, for each http-header condition, you can specify up to three strings to be compared to the value of the HTTP header in the request. The condition is satisfied if one of the strings matches the value of the HTTP header. To require that all of the strings are a match, create one condition per match evaluation.

You can specify up to five match evaluations per rule. For example, you can create a rule with five conditions where each condition has one match evaluation.

You can include wildcard characters in the match evaluations for the http-header, host-header, path-pattern, and query-string conditions. There is a limit of five wildcard characters per rule.

For demos, see Advanced Request Routing.

HTTP Header Conditions

You can use HTTP header conditions to configure rules that route requests based on the HTTP headers for the request. You can specify the names of standard or custom HTTP header fields. The header name and the match evaluation are case-insensitive. The following wildcard characters are supported in the comparison strings: * (matches 0 or more characters) and ? (matches exactly 1 character). Wildcard characters are not supported in the header name.

Example HTTP Header Condition for the AWS CLI

You can specify conditions when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following condition is satisfied by requests with a User-Agent header that matches one of the specified strings.

[ { "Field": "http-header", "HttpHeaderConfig": { "HttpHeaderName": "User-Agent", "Values": ["*Chrome*", "*Safari*"] } } ]

HTTP Request Method Conditions

You can use HTTP request method conditions to configure rules that route requests based on the HTTP request method of the request. You can specify standard or custom HTTP methods. The match evaluation is case-sensitive. Wildcard characters are not supported; therefore, the method name must be an exact match.

We recommend that you route GET and HEAD requests in the same way, because the response to a HEAD request may be cached.

Example HTTP Method Condition for the AWS CLI

You can specify conditions when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following condition is satisfied by requests that use the specified method.

[ { "Field": "http-request-method", "HttpRequestMethodConfig": { "Values": ["CUSTOM-METHOD"] } } ]

Host Conditions

You can use host conditions to define rules that route requests based on the host name in the host header (also known as host-based routing). This enables you to support multiple domains using a single load balancer.

A hostname is case-insensitive, can be up to 128 characters in length, and can contain any of the following characters:

  • A–Z, a–z, 0–9

  • - .

  • * (matches 0 or more characters)

  • ? (matches exactly 1 character)

You must include at least one "." character. You can include only alphabetical characters after the final "." character.

Example hostnames

  • example.com

  • test.example.com

  • *.example.com

The rule *.example.com matches test.example.com but doesn't match example.com.

Example Host Header Condition for the AWS CLI

You can specify conditions when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following condition is satisfied by requests with a host header that matches the specified string.

[ { "Field": "host-header", "HostHeaderConfig": { "Values": ["*.example.com"] } } ]

Path Conditions

You can use path conditions to define rules that route requests based on the URL in the request (also known as path-based routing).

The path pattern is applied only to the path of the URL, not to its query parameters.

A path pattern is case-sensitive, can be up to 128 characters in length, and can contain any of the following characters.

  • A–Z, a–z, 0–9

  • _ - . $ / ~ " ' @ : +

  • & (using &)

  • * (matches 0 or more characters)

  • ? (matches exactly 1 character)

Example path patterns

  • /img/*

  • /js/*

The path pattern is used to route requests but does not alter them. For example, if a rule has a path pattern of /img/*, the rule would forward a request for /img/picture.jpg to the specified target group as a request for /img/picture.jpg.

Example Path Pattern Condition for the AWS CLI

You can specify conditions when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following condition is satisfied by requests with a URL that contains the specified string.

[ { "Field": "path-pattern", "PathPatternConfig": { "Values": ["/img/*"] } } ]

Query String Conditions

You can use query string conditions to configure rules that route requests based on key/value pairs or values in the query string. The match evaluation is case-insensitive. The following wildcard characters are supported: * (matches 0 or more characters) and ? (matches exactly 1 character).

Example Query String Condition for the AWS CLI

You can specify conditions when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following condition is satisfied by requests with a query string that includes either a key/value pair of "version=v1" or any key set to "example".

[ { "Field": "query-string", "QueryStringConfig": { "Values": [ { "Key": "version", "Value": "v1" }, { "Value": "example" } ] } } ]

Source IP Address Conditions

You can use source IP address conditions to configure rules that route requests based on the source IP address of the request. The IP address must be specified in CIDR format. You can use both IPv4 and IPv6 addresses. Wildcard characters are not supported.

If a client is behind a proxy, this is the IP address of the proxy not the IP address of the client.

This condition is not satisfied by the addresses in the X-Forwarded-For header. To search for addresses in the X-Forwarded-For header, use an http-header condition.

Example Source IP Condition for the AWS CLI

You can specify conditions when you create or modify a rule. For more information, see the create-rule and modify-rule commands. The following condition is satisfied by requests with a source IP address in one of the specified CIDR blocks.

[ { "Field": "source-ip", "SourceIpConfig": { "Values": ["192.0.2.0/24", "198.51.100.10/32"] } } ]