Cloud Notes: AWS ELB

Intro

There are 4 types of Elastic Load Balancers (ELBs) in AWS.

• Classic Load Balancer (CLB)
• Network Load Balancer (NLB)
• Application Load Balancer (ALB)
• Gateway Load Balancer (GWLB)

ELB Architecture

The various Elastic Load Balancers (ELBs) types have the following characteristics.

• When ELBs are deployed they are assigned to 2 or more subnets.
• ELBs are AZ resilient. AWS deploys, and automatically scales ELBs within each AZ Subnet to meet demand. However, ELBs appear as 1 logical unit to AWS users.
• ELBs support both IPv4-only and IPv4/6 dual-stack addressing.
• A DNS Alias Record is used to point to the ELBs Frontend IP address. This maps to all ELB instances deployed into Subnets for the logical ELB.
• The subnet visibility type (Public or Private) determines if the ELB is External (internet facing) or Internal.
• External ELBs have both Public and Private IP addresses.
• Internal ELBs have only Private IP addresses.
• External ELBs can connect to Backend Resources in both Public and Private Subnets.
• ELBs require a minimum of 8 free IP addresses Per-Subnet. For IPv4, a /28 is the minimum usable size. However, it is recommended to use at least a /27 to allow the ELBs to scale out.
• Listener configurations determine which traffic is handled and how it is routed by an ELB.

The following diagram show a typical Elastic Load Balancer architecture.

The following points describe the above diagram.

• The architecture has a 3-tier deployment consisting of a Frontend, Backend and Database Tiers.
• An External ELB is deployed for the Frontend Subnets in AZ-A and AZ-B.
• An Internal ELB is deployed for the Backend Subnets in AZ-A and AZ-B.
• The Backend Pool for the External ELB is in a Public Subnet.
• The Backend Pool for the Internal ELB is in a Private Subnet.
• Users connect to the application in the Frontend tier via the External ELBs Frontend IP address.
• The Frontend pool connects to the Backend tier via the Internal ELBs Frontend IP address.
• The Backend pool connects directly to the Database tier.

Classic Load Balancer (NLB)

Classic Load Balancers (CLBs) are AWS's V1 load balancing solution. CLBs have many limitations and should be avoided.

Network Load Balancer (NLB)

Network Load Balancers (NLBs) operate at layer 4 of the OSI model and can load balance UDP and TCP traffic.

Network Load Balancers have the following characteristics.

• Have no visibility of upper-layer protocols.
• Can load balance based on TCP, UDP and TLS protocols.
• Support millions of Packets Per Second (PPS) of throughput and have much lower latency than ALBs.
• Health Checks are only available via ICMP and basic TCP checks.
• Do support Static IP addresses assignments.
• Can pass TCP traffic through to backend instances without first terminating on the NLB.
• Can be used with Private Link to provide services to other VPCs.

Application Load Balancer (ALB)

Application Load Balancers (ALBs) operate at Layer 7 of the OSI model and are used with HTTP and HTTPs traffic.

Application Load Balancers have the following characteristics.

• Compatible with HTTP and HTTPS traffic only. No other L7 protocols are supported.
• Understands L7 information such as Content-Type, Cookies, Headers, etc.. and can make routing decisions based on this information.
• Frontend connections are always terminated on the ALB. A new connection is made from the ALB to the Backend Target. Unbroken session pass-through is not supported.
• ALBs that terminate HTTPS must have TLS certificates installed.
• Health checks can be evaluted on Layer 7 information.
• Listener rules determine how traffic is forwarded, and rules processed in priority order. There is a default catch-all rule.
• Listener rules match on conditions such as: host-header, http-request-method, path-patter, source-ip, etc..
• Listener rules have actions that specify what happens when traffic is matched.
• ALBs have a lower performance capability compared to NLBs.

Gateway Load Balancer (GWLB)

Gateway Load Balancers operate at Layer 3 of the OSI model and are used to help horizontally scale a fleet of 3rd party security appliances (firewalls, IDS/IPSs) that support the GENEVE protocol.

Gateway Load Balancers have the following characteristics.

• Allows for service chaining of a fleet of Security Appliances.
• Traffic is encapsulated to/from the source and destination preserving the original IP addressing along with associated metadata via the GENEVE protocol for inspection.
• GWLB Endpoints are provisioned into subnets of the traffic that requires inspection. Traffic is forwarded to the GWLB via these Enpoints.

The following diagram shows an ingress traffic flow for a Gateway Load Balancer deployment.

The following points summarize the above diagram.

1. A users request to a Web application traverses the Internet Gateway arriving at the Gateway Load Balancer Endpoint (GWLBE).
2. The GWLBE forwards the traffic to the Gatway Load Balancer (GWLB).
3. The GWLB encapsulates the traffic in GENEVE and forwards the traffic to a security appliance in the backend pool for inspection.
4. The security appliance inspects the traffic then encapsulates it in GENEVE before forwarding is back to the GWLB.
5. The GWLB decapsulates the traffic and forwards it to the GWLBE.
6. The GWLBE forwards the traffic to the Application Load Balancer (ALB).
7. The ALB forwards the traffic to an Application Server in the backend pool.

Health Checks

Health Checks are used to ensure that Backend Targets are able to serve traffic. Depending on the type of ELB in use, different types of Health Checks can be configured.

Cross-Zone Load Balancing

Originally, ELBs could only connect to backend resources in the AZ they were deployed into.

Cross-Zone Load Balancing allows an ELB to distribute connections equally to all Registered Targets across all Availability Zones.

The following table lists the default Cross-Zone Load Balancing state for each ELB type.

The following diagram show Cross-Zone Load Balancing in operation.

The following points summarize the above diagram.

• A user makes a request to the DNS name of the application which resolves to the Alias record for the ELB.
• The request is forwarded to one of the ELBs in either Public Subnet.
• The receiving ELB forwards the request to an instance in any AZ depending on the weighting policy and load of all registered instances.

Connection Draining

Connection draining allows for the graceful removal of Backend Targets from a CLB to minimise disruption to users. Connection draining does this by allowing existing connections to continue until complete, or for a set period of time (1 - 3600 Seconds), while dissallowing new connections.

Deregistration Delay

Deregistration delay is similar to connection draining, but it is supported on NLBs, ALBs and GWLBs. Deregistration delay allows existing connections to continue until complate, or the deregistration delay timer (0 - 3600 Seconds) is reached. Additionally, new connections are dissallowed.

X-Forwarded-For

X-Forwarded-For is the de-facto standard HTTP request header for identifying the originating IP address of a client connecting to a web server through a proxy server.

X-Forwarded-For has the following characteristics.

• For HTTP and HTTPS traffic only.
• Only supported on CLBs and ALBs.
• Is in the format X-Forwarded-For: <client-ip>
• The header is appended or added to by Proxies and/or Load Balancers.
• If traversing multiple Proxies, the client-ip is the left-most entry in the list. The right-most entry is the most recent Proxy. IE: X-Forwarded-For: <client-ip>, <proxy1-ip>, <proxy2-ip>
• Backend servers need to be configured to handle the X-Forwarded-For header.

Proxy Protocol

The Proxy Protocl is similar in operation to X-Forwarded-For except that is works with many TCP based protocols not just HTTP and HTTPS.

Proxy Protocol has the following characteristics.

• The load balancer prepends a Proxy Protocol header to the TCP data.
• There are 2 versions: v1 which is human readable and v2 which is binary encoded.
• v1 is supported on CLBs only.
• v2 is supported on NLBs only.
• ALBs do not support Proxy Protocol.

Security Policy

An ELB Security Policy determines which Ciphers and Protocols are used in an SSL connection to an ELB. Depending on the target client compatability, different Security Policies can be selected.

Security Policies have the following characteristics.

• Security Polices are selected in the Listener configuration.
• Newer policies are more secure, because they drop support for older and insecure Ciphers and Protocols.
• At the time of writing ELBSecurityPolicy-2016-08 is recommended.
• ELGSecurityPolicy-FS can be used if Forward Secrecy is required by the application.