AWS Elastic Load Balancing

Elastic Load Balancing automatically distributes your incoming traffic across multiple targets, such as EC2 instances, containers, and IP addresses, in one or more Availability Zones, increasing the availability and fault tolerance of your applications.

Elastic Load Balancing monitors the health of its registered targets, and routes traffic only to the healthy targets.

You can also offload the work of encryption and decryption to your load balancer so that your compute resources can focus on their main work.

How it works

You configure your load balancer to accept incoming traffic by specifying one or more listeners.

Before a client sends a request to your load balancer, it resolves the load balancer's domain name using a Domain Name System (DNS) server. The Amazon DNS servers return one or more IP addresses to the client. These are the IP addresses of the load balancer nodes for your load balancer. The client determines which IP address to use to send requests to the load balancer.

The load balancer node that receives the request selects a healthy registered target and sends the request to the target using its private IP address.

When you enable an Availability Zone for your load balancer, Elastic Load Balancing creates a load balancer node in the Availability Zone. If you register targets in an Availability Zone but do not enable the Availability Zone, these registered targets do not receive traffic. After you disable an Availability Zone, the targets in that Availability Zone remain registered with the load balancer, but the load balancer does not route traffic to them.

As traffic to your application changes over time, Elastic Load Balancing scales your load balancer and updates the DNS entry. The DNS entry specifies the time-to-live (TTL) of 60 seconds.

Internal VS Internet-facing Load Balancer

When you create a load balancer, you must choose whether to make it an internal load balancer or an internet-facing load balancer.

The nodes of an internet-facing load balancer have public IP addresses. The DNS name of an internet-facing load balancer is publicly resolvable to the public IP addresses of the nodes. Therefore, internet-facing load balancers can route requests from clients over the internet.

The nodes of an internal load balancer have only private IP addresses. The DNS name of an internal load balancer is publicly resolvable to the private IP addresses of the nodes. Therefore, internal load balancers can only route requests from clients with access to the VPC for the load balancer.

Both internet-facing and internal load balancers route requests to your targets using private IP addresses.

If your application has multiple tiers, you can design an architecture that uses both internal and internet-facing load balancers. For example, for a web application, you can register the web servers with an internet-facing load balancer, and also register the backend application interface with an internal load balancer. As a result, the web servers receive requests from the internet-facing load balancer and send requests for the application servers to the internal load balancer. The application servers receive requests from the internal load balancer.

Listeners

A listener is a process that checks for connection requests. It is configured with a protocol and port number for connections from clients to the load balancer. Likewise, it is configured with a protocol and port number for connections from the load balancer to the targets.

If the conditions for none of a listener's rules are met, then the default action for the default rule is performed.

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 Action

The rules that you define for your listener determine how the load balancer routes requests to the targets in one or more target groups.

Each rule action has a type, an order, and the information required to perform the action.

Actions include:

• authenticate-cognito: Use Amazon Cognito to authenticate users.
• authenticate-oidc: Use an identity provider that is compliant with OpenID Connect (OIDC) to authenticate users.
• fixed-response: Return a custom HTTP response.
• forward: 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 (in percentage).
  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 (and another cookie named AWSALBTGCORS for those browsers require ameSite=None; Secure to enable stickness) that encodes information about the selected target group, encrypts the cookie(s), and includes the cookie in the response to the client. The client should include the cookie(s) 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.
• redirect: Redirect client requests from one URL to another. You can configure redirection as either temporary (HTTP 302) or permanent (HTTP 301).

Rule Condition

Each rule condition has a type and configuration information. When the conditions for a rule are met, then its actions are performed.

Conditions include host-header, http-header (can be multiple for each rule), http-request-method, path-pattern, query-string (can be multiple for each rule), source-ip

You can specify up to three match evaluations per condition. You can specify up to five match evaluations per rule.

Cross-zone load balancing

When cross-zone load balancing is enabled, each load balancer node distributes traffic across the registered targets in all enabled Availability Zones. When cross-zone load balancing is disabled, each load balancer node distributes traffic only across the registered targets in its Availability Zone.

Example

A load balancer contains two enabled Availability Zones, with two targets in Availability Zone A and eight targets in Availability Zone B. Clients send requests, and Amazon Route 53 responds to each request with the IP address of one of the load balancer nodes. This distributes traffic such that each load balancer node receives 50% of the traffic from the clients. Then each load balancer node distributes its share of the traffic across the registered targets in its scope.

• If cross-zone load balancing is enabled, each of the 10 targets receives 10% of the traffic.
• If cross-zone load balancing is disabled: each of the two targets in Availability Zone A receives (50%/2 = 25%) of the traffic. Each of the eight targets in Availability Zone B receives (50%/8 = 6.25%) of the traffic.

Slow Start Mode

By default, a target starts to receive its full share of requests as soon as it is registered with a target group and passes an initial health check. Using slow start mode gives targets time to warm up before the load balancer sends them a full share of requests. A target enter slow start mode when they are considered healthy by the target group. A target in slow start mode exits slow start mode when the configured slow start duration period elapses or the target becomes unhealthy. The load balancer linearly increases the number of requests that it can send to a target in slow start mode. After a healthy target exits slow start mode, the load balancer can send it a full share of requests.

Types

Elastic Load Balancing provides four types of load balancers. There is a key difference in how the load balancer types are configured. With Application Load Balancers, Network Load Balancers, and Gateway Load Balancers, instances are registered as targets with a target group, and you route traffic to the target group. With Classic Load Balancers, instances are registered directly with the load balancer.

Application Load Balancer

An Application Load Balancer serves as the single point of contact for clients. It can route requests to ports on one or more registered targets, such as EC2 instances, in your virtual private cloud (VPC).

An Application Load Balancer functions at the application layer, the seventh layer of the Open Systems Interconnection (OSI) model. It routes and loads balances at the application layer (HTTP/HTTPS), and supports path-based routing.

The default routing algorithm is round robin.

With Application Load Balancers, cross-zone load balancing is always enabled. An Application Load Balancer requires that you enable at least two or more Availability Zones. This configuration helps ensure that the load balancer can continue to route traffic.

Target types include instance ID, ip, and lambda

Because the load balancer is in a virtual private cloud (VPC), traffic between the load balancer and the targets is authenticated at the packet level, so it is not at risk of man-in-the-middle attacks or spoofing even if the SSL certificates on the targets are not valid.

Network Load Balancer

Network Load Balancers can handle traffic bursts, retain the source IP of the client, and use a fixed IP for the life of the load balancer. It can handle millions of requests per second.

A Network Load Balancer functions at the fourth layer of the Open Systems Interconnection (OSI) model. It can handle millions of requests per second. After the load balancer receives a connection request, it selects a target from the target group for the default rule. It attempts to open a TCP connection to the selected target on the port specified in the listener configuration.

It routes and loads balances at the transport layer (TCP/UDP Layer-4), based on address information extracted from the TCP packet header, not from packet content.

• For TCP traffic, the load balancer selects a target using a flow hash algorithm based on the protocol, source IP address, source port, destination IP address, destination port, and TCP sequence number. The TCP connections from a client have different source ports and sequence numbers, and can be routed to different targets. Each individual TCP connection is routed to a single target for the life of the connection.
• For UDP traffic, the load balancer selects a target using a flow hash algorithm based on the protocol, source IP address, source port, destination IP address, and destination port. UDP flows from a client have the same source and destination, so it is consistently routed to a single target throughout its lifetime. Different UDP flows have different source IP addresses and ports, so they can be routed to different targets.

Elastic Load Balancing creates a network interface for each Availability Zone you enable. Each load balancer node in the Availability Zone uses this network interface to get a static IP address. When you create an Internet-facing load balancer, you can optionally associate one Elastic IP address per subnet.

Cross-zone load balancing is disabled for Network Load Balancer by default. After you create the load balancer, you can enable or disable cross-zone load balancing at any time.

You register targets by instance ID or IP address, but not by lambda.

All network traffic sent to a configured listener is classified as intended traffic. Network traffic that does not match a configured listener is classified as unintended traffic. ICMP requests other than Type 3 are also considered unintended traffic. Network Load Balancers drop unintended traffic without forwarding it to any targets.

Gateway Load Balancer

Gateway Load Balancer distributes traffic to a fleet of appliance instances, providing scale, availability, and simplicity for third-party virtual appliances, such as firewalls, intrusion detection and prevention systems, and other appliances.

It works with virtual appliances that support the GENEVE protocol.

Cross-zone load balancing is disabled for Gateway Load Balancer by default. After you create the load balancer, you can enable or disable cross-zone load balancing at any time.

Classic Load Balancer

Routes and load balances either at the transport layer (TCP/SSL), or at the application layer (HTTP/HTTPS). A Classic Load Balancer supports either EC2-Classic or a VPC.

Rule conditions of the listeners of a Classic Load Balancer does not support path, host, HTTP header conditions.

Rule actions of the listeners of a Classic Load Balancer does not support fixed HTTP response, redirection and authenticated by OpenID.

Classic Load Balancer cannot register targets by IP addresses or Lambda.

Classic Load Balancer does not support target group and AWS ECS.

Classic Load Balancer does not support for static IP addresses for the load balancer.

When you create a Classic Load Balancer, the default for cross-zone load balancing depends on how you create the load balancer. With the API or CLI, cross-zone load balancing is disabled by default. With the AWS Management Console, the option to enable cross-zone load balancing is selected by default.

When you create a Classic Load Balancer in EC2-Classic, it must be an internet-facing load balancer.

Target & Target Group

Each target group is used to route requests to one or more registered targets. When you create each listener rule, you specify a target group and conditions. When a rule condition is met, traffic is forwarded to the corresponding target group

When you create a target group, you specify its target type by which the targets are specified. After you create a target group, you cannot change its target type.

You define health check settings for your load balancer on a per target group basis.

You can register each target with one or more target groups. If demand on your application increases, you can register additional targets with one or more target groups in order to handle the demand. If demand on your application decreases, or you need to service your targets, you can deregister targets from your target groups.