In the Open Systems Interconnection (OSI) model, layer 4 is the transport layer and primarily uses the UDP, TCP, or the SSL/TLS networking protocols. The layer 4 load balancers are in the network load balancer category and are known for their high connection rates, low latency, and overall high-performance characteristics. While you may occasionally see references to a layer 3 load balancer, the load balancing decisions are based on the layer 3 network addressing and layer 4 port number, so keep in mind that when you see either layer 3 or layer 4, we are talking about network load balancers.
The NLB views incoming traffic at the packet level, which means it has no insight into the actual data in the payload for content-based forwarding decisions but, rather, the networking information that includes the source and destination IP addressing and the application port number. A typical NLB configuration would look for a destination port number, for example, port 80, which is for HTTP web traffic. When it sees that the packet is destined for a web server at that destination IP address, it will look at its defined target groups of servers and forward the packet to a server in that group. Multiple groups can be configured for different ports. For example, we could have a second target group for HTTPS port 443 traffic. However, the NLB has no visibility into, or understanding of, HTTP or HTTPS data at application layer 7.
The network load balancer is part of the version 2 AWS ELB product.
When your traffic is burstable, is highly unpredictable, or requires low latency with high performance, a network load balancer is a good solution. NLBs are known for raw performance and scalability that can support millions of connections per second with predictable delays in a secure environment.
The network load balancer supports SSL/TLS encryption offloading on port 443. Traditionally, each server was expected to have a digital SSL/TLS certificate installed for in-flight encryption; then incoming traffic would first connect to the load balancer and then be forwarded to the pools of servers on the backend to terminate the SSL/TLS connection to perform the encrypt/decrypt functions. This architecture was not optimal as it required the server to use processing power for encryption that would be better served to web operations. Also, a digital certificate needed to be installed on each server with no centralized certificate location.
By using the network load balancer, the digital certificate can be installed on the load balancers Internet-facing virtual IP (VIP). Incoming encrypted traffic will terminate SSL/TLS on the VIP to offload the process from the backend servers. This allows a central point of administration, a single certificate to be installed, and centralized logging and monitoring of your in-flight encryption operations. This is called SSL offload as the operations are offloaded from the real servers in the backend pool to the load balancer.
Remember that the original security protocol was called Secure Sockets Layer (SSL). SSL has been deprecated and replaced with Transport Layer Security (TLS); however, the terminology for SSL lives on and is often used when TLS would be more accurate. So, if you see SSL, think TLS, as that is the modern version of encrypting traffic in-flight across a network.
NLBs support millions of requests per second at very low latency. Since listeners support static IP addressing, they can be whitelisted on the corporate firewall rules to allow connections into the AWS cloud via the load balancer. If you need to work with protocols that are not either HTTP or HTTPS, then a network load balancer is the solution to implement. The NLB supports a private link that enables you to connect to AWS services in other accounts.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
