Network - Load Balancer (NLB, ALB, CLB)
A Load Balancer distributes incoming traffic across targets, such as VM or container.
A load balancer also monitors the health of its registered targets and ensures that it routes traffic only to healthy targets.
A load balancer is generally implemented within a reverse proxy (gateway).
- a load balancer to accept incoming traffic by specifying one or more listeners, which are configured with a protocol and port number for connections from clients to the load balancer.
- a target group with a protocol and port number for connections from the load balancer to the targets, and with health check settings to be used when checking the health status of the targets.
Types of load balancers:
- Application Load Balancers,
- Network Load Balancers,
- and Classic Load Balancers.
A Network Load Balancer makes routing and load balancing decisions at the transport layer (TCP/TLS).
A Network Load Balancer (NLB) enables a front end service (such as website) to communicate with a single DNS name while the backend service would be free to elastically scale in-and-out based on demand or if failures occur and new containers/machines need to be provisioned.
An Application Load Balancer makes routing and load balancing decisions at the application layer (HTTP, HTTPS, …).
As it's an intermediate server that sits between the client and the origin server, it can also be a HTTP reverse proxy (when load balancing http request)
A Classic Load Balancer makes routing and load balancing decisions either at:
When a website is served by multiple web servers which sit behind a load balancer, the load balancer decides which actual (physical) web-server should each request go to.
For example, if there are 3 web servers A, B and C behind the load balancer, it is possible that www.mywebsite.com/index.jsp will be server from:
- server A
- server B
- or server C
With a default load balancer configuration, the incoming (HTTP or TCP) request are being served generally randomly from the instances under its purview. Therefore each instance would have to retrieve, manipulate, and store session data for each request in a global state (generally a database).
With sticky session, it is possible to instruct the load balancer to route repeated requests to the same instance whenever possible.
If the load balancer is instructed to use sticky sessions, all request will be directed to the same physical web server within the same session, even though other servers are present. Thus, the session object will be the same throughout the entire interaction with this website.