Load Balancing in AWS: Part II

Let’s dive into AWS’s Network, Classic, and Gateway Load Balancers.

Network Load Balancers

A Network Load Balancer (NLB) works on the fourth layer of the Open Systems Interconnection (OSI) Model for transmission control protocol (TCP) and user datagram protocol (UDP) connections. Just like ALB, NLB has three components:

• A listener checks for connection requests from clients and forwards requests to target groups.

• A load balancer acts as a single point of contact for customers.

• Target groups forward requests to one or more registered targets using the protocol and port number we specify. We can also configure health checks per target group.

Features

An NLB offers the following features:

• Can handle millions of requests per second and offers very low latency.

• Supports cross-zone load balancing (turned off by default).

• Uses three types of targets for target groups:

  • Instance: When using instance target groups, the client IP address is preserved.
  • IP address: Client IP isn’t preserved. The application will see the private IP address of the load balancer nodes instead.
  • ALB: Client IP is preserved and provided to ALB.

• Supports static IP addresses for the load balancer. We can also assign one Elastic IP address per subnet enabled for the NLB. This is helpful in architectures where we want to open a firewall rule or allow access to certain IP addresses.

• Can have on-site servers and other resources outside VPC as IP targets.

• Supports dynamic port mapping, meaning it can forward traffic to multiple applications or tasks (containers) running on one EC2 instance.

• Supports access logs. We can configure NLB to send access logs to the S3 bucket in the same or a different AWS account.

• Supports connections from clients over inter-region VPC peering, AWS-managed virtual private networks (VPNs), and third-party VPN solutions.

• Supports Transport Layer Security (TLS) termination.

• Lacks a security group of its own. As long as the client can reach a server, they can also reach it via NLB. For example, to allow users to reach EC2 instances via NLBs, the EC2 security groups should allow clients (IP ranges) to reach EC2 instances. We don’t have to do this for ALB. We can simply allow the ALB security group as the source in the instance security groups. As long as clients can reach the ALB, they can also reach the EC2 instance.

Practical

In the following widget, we’ll:

• Create a key pair.
• Create a security group for EC2 instances.
• Add a rule to allow HTTP access from CIDR 0.0.0.0/0 over port 80. Unlike ALB, NLB doesn’t have a security group, so to access the web page, we must have access to the EC2 instance via its security group.
• Look up subnet and AMI IDs.
• Launch two EC2 instances with web pages in different subnets. The instance web page is accessible from the internet via the instance public IP.
• Create a target group.
• Register instances with the target group. Because the target group isn’t associated with a listener, it won’t perform health checks.
• Create an NLB.
• Add a listener to forward requests to the target group. Once the target group has a listener pointing to it, it starts performing health checks.
• Wait for the health checks to be successful.
• View our web page via the NLB.

Note: It can take up to five minutes for the EC2 instances to become healthy.