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)
The Classic Load Balancer is considered a legacy product
and should be avoided.
The various Elastic Load Balancers (ELBs) types have the
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
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
ALBs that terminate HTTPS must have TLS certificates
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
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
The following points summarize the above diagram.
A users request to a Web application traverses the Internet Gateway
arriving at the Gateway Load Balancer Endpoint (GWLBE).
The GWLBE forwards the traffic to the Gatway Load Balancer (GWLB).
The GWLB encapsulates the traffic in GENEVE and
forwards the traffic to a security appliance in the backend pool for inspection.
The security appliance inspects the traffic then encapsulates it in
GENEVE before forwarding is back to the GWLB.
The GWLB decapsulates the traffic and forwards it to the GWLBE.
The GWLBE forwards the traffic to the Application Load Balancer (ALB).
The ALB forwards the traffic to an Application Server in the
The return egress traffic follows the process in reverse.
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.
|Enabled By Default
|Classic Load Balancer
| True - via Console.
False - via API or CLI.
|Network Load Balancer
|Application Load Balancer
| True - Cannot be disabled on ALB, but can be disbaled at the Target Group level.
|Gateway Load Balancer
Ensure that Cross-Zone Load Balancing is enabled if troubleshooting
an uneven load problem.
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
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.
Connection Draining is only supported on Classic Load Balancers and
is configured on the CLB.
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.
Deregistration delay is configured on the Target Group not the
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.
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.
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
ELGSecurityPolicy-FS can be used if Forward Secrecy
is required by the application.