Elastic Load Balancing

ACG Notes:

·       4 types of load balancers:

·       Application – Layer 7

·       Network – Layer 4

·       Classic – legacy

·       Gateway Load Balancer


·       You cannot convert one load balancer type into another type – you can migrate to one.

·       You cannot use ALB as layer 4 load balancer.

·       A security group can be configured on the front end of an ALB.

·       ALBs need new APIs and cannot use CLB APIs.

·       There is some overlap in the ALB and CLB

·       X-forwarded for

·       Sticky sessions

·       Strict layer 4

·       Load HTTP/HTTPS

·       Network load balancers have ultra-low latency and extreme performance.

·       The x-forward- for header is used if you need to identify the IPv4 of an end user.

·       If an application stops, the ELB forwards a 504 error (app failed – web server or DB)


Load Balancers and Health Checks – LAB


1.       Launch two EC2 instances in two AZs (use bootstrap script to start an apache web server).

2.       Create a LB – place in a VPC

a.       Configure Listener

b.       Configure Health Check response

                                                               i.      Interval between health checks

                                                             ii.      Unhealthy threshold – the number of health checks that occur before it declares the target unhealthy.

                                                           iii.      It takes 3 health checks before it is declared healthy again

·       ELBs are not free.

·       You are never given an IP address for an ELB – you get a DNS fqdn.

·       Instances monitored by ELB are reported as in-service or out-of-service.

·       Health checks check the instance by talking to it.

·       Load balancers have their own DNS name.  You are never given an IP address for the application or classic LB (may be for the GWLB?)

·       Network Load Balancers can have an IP address.



Advanced Load Balancing Theory


·       Sticky sessions enable your users to stick to the same EC2 instance.  Can be useful if you are storing information locally about that instance.

·       Cross Zone load balancing enables you to load balance across multiple AZs.

·       Path patterns allow you to direct traffic to different EC2 instances based on the URL contained in the request.   Ex. Myurl.com goes to server1, myurl.com/image goes to another AZ.




·       You can associate multiple certs with the same domain to a secure listener.

·       Cross zone load balancing is enabled by default.

·       You can use SSL certs with different protocols and key sizes.

·       SNI is automatically enabled when you associate more than one TLS cert with the same secure listener.

·       IPv6 is support with ALB

·       Rules determine how a particular HTTP request should be routed.

·       Rules can use multiple conditions and actions.  Conditions can match on multiple values including:

·       Host header

·       Path

·       HTTP headers

·       Methods

·       Query parameters

·       Source IP CIDR



·       You can integrate your ALB with a WAF to protect web applications from attacks by configuring rules based on IP addr, HTTP headers, or custom URL.


·       ALB and Amazon Cognito Use cases – authenticate with Cognito if:

·       You use social network identity providers

·       Use your own user directories

·       Federate for multiple identity providers

·       Activity manage user profiles.


Use ALB – OIDC native if you develop a custom IdP solution and want to authenticate with a single identity provider


·       ALB redirects

·       HTTP -ΰ HTTP

·       HTTP ΰ HTTPS

·       HTTPS ΰ HTTPS


·       Message bodies supported

·       Text/plain

·       Text/css

·       Text/html

·       App/javascript

·       App/json

·       No charge for cross-zone load balancing.


Network Load Balancers


·       Supports TCP, UDP, TCP+UDP

·       Millions of requests per second – low latency.

·       Supports TLS termination

·       Zonal isolation

·       Supports long running sessions.

·       NLB can process TCP and UDP traffic on the same port by configuring a TCP+UDP listener. 

·       NLB supports DNS regional and zonal failover.

·       NLB can support only one public internet facing IP address

·       NLB can be setup as internet-facing or as an internal load balancer.

·       BLBs can support only one IP internally. 

·       UDP flow based on a 5 tuple hash – source IP, destination IP, protocol, source port, destination port – it ensures packets are sent to the same targe.

·       Connection is up as long as packets are flowing.

·       Idle timeout for TCP – 350sec, UDP 120 Sec.

·       NLB target limits – 200 per AZ unless you have cross zone load balancing enabled and then you have 200 per NLB

·       NLB preserves the source IP with TLS termination

·       No server back-end authentication is allowed with NLB.



Gateway Load Balancer



·       Gateway Load balancer makes it easy to deploy, scale, and manage your third-party virtual appliances.  It gives you one gateway for distributing traffic across multiple virtual appliances, while scaling them up, down or based on demand.



·       NGFW

·       IDS/IPS

·       DDoS prevention

·       Visibility, performance, analytics tools

·       ADC, SD-WAN, IoT, etc



It is both a “gateway” AND a “load Balancer


L3 Gateway: Next hop in the route table and no packet rewrite.

L4 Load Balancer – scaling, stickiness (both directions), health checks, flow rerouting, encapsulate original traffic.

Elastic, Transparent, and Fault Tolerant.



 – Use existing third-party appliance skills

-          Leverage existing tools and practices

-          Simplify appliance deployments

-          Deploy appliances at elastic scale

-          Improve availability of appliances

-          Share appliances across VPCs and across accounts.




·       Gateway Load Balancer is a transparent bump-in-the-wire device and listens to all types of IP traffic (including TCP, UDP, ICMP, GRE, ESP and others). Hence only IP listener is created on a Gateway Load Balancer.


·       You cannot add or remove availability zones for a Gateway Load Balancer after you create it.


·        By default, cross-zone load balancing is disabled. You can enable cross-zone loading balancing only after creating your Gateway Load Balancer.


·       Gateway Load Balancer currently supports 300 targets per Availability Zone. For example, if you created Gateway Load Balancer in 3 Availability-Zones, you can have up to 900 targets registered. If cross-zone load balancing is on, then the maximum number of targets reduces from 300 per Availability Zone to 300 per Gateway Load Balancer.


·       Gateway Load Balancer Endpoints are a new type of VPC endpoint that uses PrivateLink technology. Gateway Load Balancer Endpoints allow users to consolidate appliances (such as firewalls) in a separate VPC, allow separation of costs/budgets with service provider and service consumer model, allow separation of admin roles and IAM permissions, allow overlapping IP CIDRs in service consumer VPC, and simplify traffic forwarding with Gateway Load Balancer Endpoint ID instead of managing IP addresses in route tables.


·       Using a Gateway Load Balancer Endpoint, appliances can reside in different AWS accounts and VPCs


·       Gateway Load Balancer Endpoints are a new type of VPC endpoint that uses PrivateLink technology. As network traffic flows from a source (an Internet Gateway, a VPC, etc.) to the Gateway Load Balancer, and back, a Gateway Load Balancer Endpoint ensures private connectivity between the two. All traffic flows over the AWS network and data are never exposed to the internet, increasing both security and performance.


Security Use Cases:


North – South Inspection  -N-S Inspection with IGW


GWLBE = Gateway load balancer endpoint – next-hop in the route table.

N-S Inspection with the Transit Gateway

(Transit Gateways are to facilitate communication between VPCs) –

InterVPC traffic




Appliance must support GENEVE protocol on the appliance, and encode/decode GENEVE options (TLV), and respond to health checks from GWLB.


ELB portfolio


1.       ALB – layer 7

2.       NLB – Layer 4

3.       GLB – Layer 3










Classic Load Balancer


·       The classic load balancer supports Amazon EC2 instances with any operating system currently supported by the Amazon EC2 service.


·       Classic load balances support applications using HTTP, HTTPS (Secure HTTP), SSL (secure TCP) and TCP protocols

You can perform load balancing over ports (1-65535, 25, 80, 443, 465, 587, 1024-65535)


·       Classic load balancer supports IPv6 traffic – IPV6 is not supported in VPC (?) – You can use an application load balancer for native IPv6 support.

·       Cloud trail gives a history of Classic Load Balancer API calls made on my account for security analysis and operational troubleshooting.

·       Classic load balancers support SSL termination – you must install a certificate on each load balancer.

·       You are NOT charged for regional data transfer between AZs when you enable cross-zone load balancing for the Classic load balancer.