How Can We Help?

AWS Load Balancers

You are here:
< All Topics

NOTE: health checks for EC2 instances are crucial when using  load balancers, because you do not want to send traffic to an EC2 instance or other service if it is not working properly.


You set up your security group for the load balancer, your endpoints eg EC2 instances should only accept traffic from the load balancer security group and not from the external internet. This is an enhanced security mechanism.




Types of Load Balancer in AWS



ELB Elastic Load Balancer

CLB Classic Load Balancer (deprecated)

ALB Application Load Balancer

NLB Network Load Balancer

GWLB Gateway Load Balancer





ELB Elastic Load Balancer


is a managed load balancer,

aws guarantees it will work, takes care of upgrades and availability

costs more than setting up your own load balancer, but is more convenient and less overhead for you

is integrated with many aws services




CLB Classic Load Balancer



is deprecated, don’t use for new installs


operates on tcp layer 4 and http/https layer 7


health checks are based on above


fixed hostname


ALB Application Load Balancer


works at layer 7 http


balances to multiple http servers machines ie target groups


also can be multiple applications on SAME machine eg via containers


supports websocket as well


and redirects from http to https


can route acc to target url path eg and


also based on hostname eg and


also query string or headers in the url


good for micro services and container-based apps eg docker and amazon ecs


also have port mapping feature


comparison with old classic lb: you would need additional clbs to do the same with one alb if you want different routing




NLB Network Load Balancers


operates at layer 4


forwards TCP/UDP traffic to instances


high volume traffic, millions of requests per sec

low latency 100ms vs 400ms for ALB


NLB has one static ip per AZ, supports Elastic IP


Useful for having 2 incoming points for traffic to your network


use case:


when you need extreme performance or tcp udp traffic


Note: NLB is NOT in the free-tier pricing!



GWLB  Gateway Load Balancer 


esp used for firewalls, intrusion detection, prevention system (IDS/IDPS), deep packet inspection systems etc


can also be used to manage a fleet of 3rd party network virtual appliances running on aws


operates at layer 3 network layer ip packets


has 2 functions:


1. transparent network gateway – a single point of entry/exit for traffic


2. load balancer to distribute traffic to your virtual appliances


exam tip:
GENEVE protocol port 6081 is the gateway load balancer


EC2s must be private addresses for GWLB



Sticky Sessions or Session Affinity


this means the same client is always connected to the same instance behind a load balancer to complete a transaction


this works for CLBs and ALBs


uses a cookie with an expiry date.


this is to ensure a user does not lose his session data


but – it can cause an imbalance within the balanced load cluster





application-based cookie

– custom cookie, is generated by the target, can include any attribute


– application cookie – generated by load balancer, cookie name is AWSALBAPP


but some names are reserved: AWSALB, AWSALBAPP AWSALBTG


duration-based cookie


– generated by load balancer
cookie name is AWSALB for ALB and AWSELB for CLB





Cross-Zone Load Balancing


a point to note about cross-zone load balancing…


if this feature is  ON, then it will ensure each INSTANCE gets the equal amount of share of traffic as all other instances.


but if this feature is OFF , then it will vary between the instances depending on how many instances in each AZ, if this is unequal eg one AZ has fewer EC2s than others, then it will be unequally divided among the actual EC2s although equally shared out at the AZ 1lb level.


Be aware:


CZ-LB is enabled by default for ALB – and cannot be disable –  but for NLB it is disabled by default – but you pay extra if you want to enable it. 


but for CLB: it is disabled, but you can enable, and it is free to enable




SSL/TLS and AWS Load Balancers


encrypts via “in-flight” in-transit encryption


SSL: secure sockets layer

TLS: transport layer security, the newer ssl version


public SSL certificates are issued by certificate authorities (CAs)


eg Globalsign, Digicert, GoDaddy etc


have an expiry date, must be renewed


Load Balancer uses an X.509 SSL certificates, can be managed via ACM – the AWS certificate manager


you can create your own certificate


clients can also use SNI server name indication – client must declare which hostname it wants in the SSL handshake. Server then finds the correct SSL certificate or else returns the default one.




SNI Server Name Indication for SSL


solves problem of loading multiple SSL certificates onto one webserver to serve multiple websites.


only works with alb and nlb and cloudfront, not with clb



Elastic load balancer elb only supports


CLB – only 1 SSL certificate


must use multiple clbs for more than one certificate


ALB and NLB 


supports multiple SSL certificates and uses sni to make it work



Connection Draining and load balancers


CLB call it connection draining
ALB and NLB: call it deregistration delay


it allows some time for instances to complete in-flight SSL requests while instance is unhealthy or de-registering


it stops lb sending requests to the instance during this period


you can set a period of between 1 and 3600 secs, default is 300 secs, or disable, by setting to 0.


set a low value if requests are short


if there tend to be longer requests, eg for uploads, downloads etc… then set a higher value.


Table of Contents