At the time of writing, there are 3 types of Elastic Load Balancer: CLB (Classic Load Balancer), ALB (Application Load Balancer) and NLB (Network Load Balancer). AWS releases CLB first, then ALB, thats why CLB sometimes is referred as ELB-V1, and ALB is referred as ELB-V2. Then NLB comes as the latest release.
From my point of view, the reason to have 3 types of ELB is that AWS was initially trying to do both TCP (L4) and HTTP (L7) load balancing in CLB/ELB-V1. But for some technical limits, it could not do it well – both L4 and L7 comes with limited functions. Then AWS decided to split it into two types: http/https only and tcp only (as Jobs said less is more!). That’s why it ends up having 3 types ELB.
Here is my guess: CLB will be end of life sooner or later as there are increasing demands of http/2. ALB and NLB will be the two types of ELB eventually. ALB will be the product for http/https (L7) load balancing. It works sort of like Nginx or HAProxy. NLB is focus on tcp (L4) load balancing, technically it should be something like LVS.
One good use case of ALB is to consolidate CLB, here is a real example that I have done.
| Feature | Application Load Balancer | Network Load Balancer | Classic Load Balancer |
| Protocols | HTTP, HTTPS | TCP, TLS | TCP, SSL/TLS, HTTP, HTTPS |
| Platforms | VPC | VPC | EC2-Classic, VPC |
| Health checks | ✔ | ✔ | ✔ |
| CloudWatch metrics | ✔ | ✔ | ✔ |
| Logging | ✔ | ✔ | ✔ |
| Zonal fail-over | ✔ | ✔ | ✔ |
| Connection draining (deregistration delay) | ✔ | ✔ | ✔ |
| Load Balancing to multiple ports on the same instance | ✔ | ✔ | |
| WebSockets | ✔ | ✔ | |
| IP addresses as targets | ✔ | ✔ | |
| Lambda functions as targets | ✔ | ||
| Load balancer deletion protection | ✔ | ✔ | |
| Path-Based Routing | ✔ | ||
| Host-Based Routing | ✔ | ||
| Native HTTP/2 | ✔ | ||
| Configurable idle connection timeout | ✔ | ✔ | |
| Cross-zone load balancing | ✔ | ✔ | ✔ |
| SSL offloading | ✔ | ✔ | ✔ |
| Server Name Indication (SNI) | ✔ | ||
| Sticky sessions | ✔ | ✔ | |
| Back-end server encryption | ✔ | ✔ | ✔ |
| Static IP | ✔ | ||
| Elastic IP address | ✔ | ||
| Preserve Source IP address | ✔ | ||
| Resource-based IAM permissions | ✔ | ✔ | ✔ |
| Tag-based IAM permissions | ✔ | ✔ | |
| Slow start | ✔ | ||
| User authentication | ✔ | ||
| Redirects | ✔ | ||
| Fixed response | ✔ |
References:
https://aws.amazon.com/elasticloadbalancing/details/#details
https://aws.amazon.com/documentation/elastic-load-balancing/
NLB does support cross-zone load balancing now 🙂
yes, thanks for pointing it out!
Are there any notable disadvantages when comparing a NLB to a CLB? Or migrating from CLB to NLB is a no-brainer? Thanks!
Are there any notable disadvantages to migrating from CLB to, say, NLB? Or is it a no-brainer? Thx!
It really depends on your requirements. For example, what protocols do you use? Do you need path-based or host-based routing? Use the matrix as your guidance to make a decision.
AWS just announced TLS termination for NLB: https://aws.amazon.com/blogs/aws/new-tls-termination-for-network-load-balancers/
Thanks for sharing! Yes, I have read it last week. Besides TLS termination, it is also capable of keeping the source IP address.
Do you know of effective ways to mitigate DDoS type attacks when using NLB for TCP traffic? The end-point is a private EC2 handling TCP traffic only and the idea is to stop attacks from reaching the instance in the private subnet.
Check out AWS DDoS protection solutions – AWS Shield. The standard version is enabled by default at no additional charge. If you need protection from sophisticated DDos attack, then you need to purchase advanced version.