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.
If you must ensure that the targets decrypt HTTPS traffic instead of the load balancer, you can create a Network Load Balancer with a TCP listener on port 443. With a TCP listener, the load balancer passes encrypted traffic through to the targets without decrypting it.
Listeners rules
Every listener has a default action, also known as the default rule. The default rule cannot be deleted and is always performed last. Additional rules can be created and consist of a priority, one or more actions, and one or more conditions. You can add or edit rules at any time.
Default Listeners 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:
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.
Rule Actions
Each rule action has a type, a priority, and the information required to perform the action
Rule Conditions
Each rule condition has a type and configuration information. When the conditions for a rule are met, then its actions are performed.
Rule Actions Types
The following are the supported action types for a listener rule:
Fixed Response Action:
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.The count of successful fixed-response actions is reported in the HTTP_Fixed_Response_Count metric.
Forward Action
You can use forward actions to route requests to one or more target groups. If you specify multiple target groups for a forward action, you must specify a weight for each target group. Each target group weight is a value from 0 to 999. Requests that match a listener rule with weighted target groups are distributed to these target groups based on their weights. For example, if you specify two target groups, each with a weight of 10, each target group receives half the requests. If you specify two target groups, one with a weight of 10 and the other with a weight of 20, the target group with a weight of 20 receives twice as many requests as the other target group.
By default, configuring a rule to distribute traffic between weighted target groups does not guarantee that sticky sessions are honored. To ensure that sticky sessions are honored, enable target group stickiness for the rule. When the load balancer first routes a request to a weighted target group, it generates a cookie named AWSALBTG that encodes information about the selected target group, encrypts the cookie, and includes the cookie in the response to the client. The client should include the cookie that it receives in subsequent requests to the load balancer. When the load balancer receives a request that matches a rule with target group stickiness enabled and contains the cookie, the request is routed to the target group specified in the cookie.
With CORS (cross-origin resource sharing) requests, some browsers require SameSite=None; Secure to enable stickiness. In this case, Elastic Load Balancing generates a second cookie, AWSALBTGCORS, which includes the same information as the original stickiness cookie plus this SameSite attribute. Clients receive both cookies.
What is Session Stickyness in Load Balancer ?
By default, an Application Load Balancer routes each request independently to a registered target based on the chosen load-balancing algorithm. However, you can use the sticky session feature (also known as session affinity) to enable the load balancer to bind a user’s session to a specific target. This ensures that all requests from the user during the session are sent to the same target. This feature is useful for servers that maintain state information in order to provide a continuous experience to clients. To use sticky sessions, the client must support cookies.
Application Load Balancers support both duration-based cookies and application-based cookies. Sticky sessions are enabled at the target group level. You can use a combination of duration-based stickiness, application-based stickiness, and no stickiness across your target groups.
Types of Session Stickiness in Load Balancer in AWS
Click Here for Duration Based Stickness
Click Here to Application Base Stickness
Forward Action with Stickiness Enabled
If you have a forward action with multiple target groups and one or more of the target groups has Session Stickiness enabled, you must enable target group stickiness.