AWS — Difference between Application load balancer (ALB) and Network load balancer (NLB)

Comparisons: ALB vs NLB in AWS — Application load balancer vs Network load balancer. 



ALB — Layer 7 (HTTP/HTTPS traffic), Flexible. 
NLB — Layer 4 (TLS/TCP/UDP traffic), Static IPs. 

 Both Application Load Balancer and Network Load Balancer are designed from the ground up for the modern paradigm of dynamic port configurations as commonly seen in containerized deployments. Picking which load balancer is right for you will depend on the specific needs of your application, such as whether or not network traffic is HTTP, whether you need end-to-end SSL/TLS encryption, and whether or not you want host and path-based traffic routing. If you are deploying docker containers and using a load balancer to send network traffic to them EC2 Container Service provides tight integration with ALB and NLB so you can keep your load balancers in sync as you start, update, and stop containers across your fleet. 

Application Load Balancer (ALB) 
 This is the distribution of requests based on multiple variables, from the network layer to the application layer. It is context-aware and can direct requests based on any single variable as easily as it can a combination of variables. Applications are load balanced based on their peculiar behaviour and not solely on server (operating system or virtualization layer) information. This is a feature filled Layer-7 load balancer, HTTP, and HTTPS listeners only. Provides the ability to route HTTP and HTTPS traffic based upon rules, host-based or path based. Like an NLB, each Target can be on different ports. Even supports HTTP/2. Configurable range of health check status codes (CLB only supports 200 OK for HTTP health checks). Protocols: HTTP, HTTPS Protocol versions: HTTP/1.1, HTTP/2, gRPC Target Types: Instance, IP, Lambda With ALB, it is a requirement that you enable at least two or more Availability Zones. 

  Network Load Balancer (NLB) This is the distribution of traffic based on network variables, such as IP address and destination ports. It is Layer 4 (TCP) and below and is not designed to take into consideration anything at the application layer such as content type, cookie data, custom headers, user location, or the application behavior. It is context-less, caring only about the network-layer information contained within the packets it is directing this way and that. This is a TCP Load Balancer only that does some NAT magic at the VPC level. It uses EIPs, so it has a static endpoint unlike ALB and CLBs (by default). Each Target can be on different ports. Protocols: TLS, TCP, UDP, TCP_UDP Protocol versions: TLS, TCP, UDP, TCP_UDP Target Types: Instance, IP, ALB With NLB, Elastic Load Balancing creates a network interface for each Availability Zone that you enable. 

  Key Differences: ALB vs NLB 
• OSI Layer: Application Load Balancer (as the name implies) works at the Application Layer (Layer 7 of the OSI model, Request level). Network Load Balancer works at the Transport layer (Layer 4 of the OSI model, Connection level). 
• Routing: NLB just forward requests whereas ALB examines the contents of the HTTP request header to determine where to route the request. So, an ALB support advanced request (content-based) routing. • Static IP: ALB doesn’t provide support for static IP address whereas NLB provides support for zonal static IP addresses (in each AZ). • PrivateLink (Endpoint services): NLB provides support for PrivateLink with VPC Endpoints Service integration whereas ALB doesn’t support PrivateLink. Only NLB can be used directly as PrivateLink. Elastic Load Balancing now supports forwarding traffic directly from NLB to ALB. With this feature, you can now use AWS PrivateLink and expose static IP addresses for applications built on ALB. 
• AWS Load Balancer Controller for Kubernetes: controller provisions ALB when you create a Kubernetes Ingress and NLB when you create a Kubernetes service of type LoadBalancer. 
• Application availability: NLB cannot assure the availability of the application. This is because it bases its decisions solely on network and TCP-layer variables and has no awareness of the application at all. Generally, NLB determines availability based on the ability of a server to respond to ICMP ping or to correctly complete the three-way TCP handshake. ALB goes much deeper and is capable of determining availability based on not only a successful HTTP GET of a particular page but also the verification that the content is as was expected based on the input parameters. 
• When considering the deployment of multiple applications on the same host sharing IP addresses (virtual hosts), NLB will not differentiate between Application-A and Application-B when checking availability (indeed it cannot unless ports are different) but ALB will differentiate between two applications by examining the application layer data available to it. This difference means that NLB may end up sending requests to an application that has crashed or is offline, but ALB will never make that same mistake. 

  Use Cases 
Choose ALB if: 
• Application Load Balancer is best suited for load balancing of HTTP and HTTPS traffic and provides advanced request routing targeted at the delivery of modern application architectures, including microservices and containers. 
• Applications need advanced routing (host-based, URL-based, query string based). 
• Run multiple services (microservices) behind a single load balancer. 

Choose NLB if: 
• Network Load Balancer is best suited for load balancing of TCP traffic where extreme performance is required. It is capable of handling millions of requests per second while maintaining ultra-low latencies, and it is optimized to handle sudden and volatile traffic patterns. 
• You want to share/expose your services (e.g. SaaS services) to other consumers in different VPCs using PrivateLink VPC Endpoint. 
• You need a static IP address that can be used by applications as the front-end IP of the load balancer. Read AWS Elastic Load Balancer (ELB) Overview

Comments

Post a Comment

Popular posts from this blog

System Design Interview Guide (2023) | Preparation Strategies and Practical Tips

Image
System Design Interview Preparation: Mastering the Art of System Design Grokking the System Design Interview The fact is, designing a scalable system is a challenging task, especially when your are asked to do it in an interview. In this guide I will share my learnings about system design interviews and what process I followed to clear FAANG system design interviews. Let me start with listing the two most important aspects of learning system design: Develop a solid understanding of system design basics like  Load Balancing ,  Caching ,  Partitioning ,  Replication ,  CAP Theorem ,  SQL vs. NoSQL , etc. Researching  common system design interview questions  and practicing your answers. One thing you should keep in mind, just understanding the basic system design concepts isn’t enough. In a system design interview, the interviewer wants to see that you can apply your knowledge to real-world scenarios. So, my advice to you is to learn system design b...
Read more

Memory Requests And Limits In Kubernetes

Image
  In Kubernetes, what should I use as memory requests and limits? And what happens when you don’t set them? Let’s dive into it. In Kubernetes, you have two ways to specify how much CPU a pod can use: “Requests” are usually used to determine the average consumption. “Limits” set the max number of resources allowed. The Kubernetes scheduler uses requests to determine where the pod should be allocated in the cluster. Since the scheduler doesn’t know the consumption (the pod hasn’t started yet), it needs a hint. The kubelet uses limits to stop the process when it uses more memory than is allowed. It’s worth noting that the process could spike in memory usage before it’s terminated. The kubelet is also in charge of monitoring the total memory utilization of the node. If memory is running low, the kubelet evicts low-priority pods. But how does it decide what’s low priority? When Kubernetes creates a Pod, it assigns one of these QoS classes to the Pod: Guaranteed Burstable BestEffort Pods...
Read more

Cost of the Cloud Computing Resources in 2023

Cost of the Cloud Computing Resources in 2023  Cost savings is one of the main reasons that companies decide to migrate to a cloud environment. Cloud Computing can offer organizations potential financial advantages in a few ways; however, it's important to understand the full implications of cloud pricing, and how it can affect companies. How Do Providers Determine Cloud Costs? The main factors cloud service providers consider when they decide how much to charge customers are networking, computing and storage. Networking costs: The vendor decides how much it must spend to maintain the network. Consequently, the provider estimates the costs for the hardware, network setup, labor and maintenance. Storage costs: The vendor calculates how much it will cost to operate a company's storage hardware or what it will cost to buy new hardware to meet the storage needs of the enterprise. Computing costs: The provider calculates the costs for CPUs -- client organizations will have their own...
Read more