- The NLB or Network Load Balancer
is a very different piece of infrastructure than the
ALB or Application Load Balancer.
The first big difference is that it operates
at layer four of the seven layer OSI model.
This is going to include TCP
and UDP,
rather than HTTP
and HTTPS.
It's designed to handle inbound traffic
that is then delivered to applications,
and it can also be internet facing
or internal only.
It only allows one TLS cert if you want to
create an SSL listener
at layer four,
as opposed to the 25 certs that you can apply to an ALB.
And as I mentioned you can only create
TCP and UDP listeners,
but you can also create combo listeners if you like.
And while both of the ALB
and the NLB
can be deployed into a VPC,
and you choose your subnet or subnets,
the ALB supports security groups.
The NLB does not,
as it performs a straight pass through of your traffic.
There are some good use cases for the NLB.
Anytime you have a non-web application,
if you just need a TCP socket,
that might be perfectly appropriate for the NLB.
If you have combo listeners.
So if you've deployed, for example,
your own custom DNS solution
running on port 53
for both TCP and UDP,
the NLB can support that.
It is also designed for anything that requires
very low latency and very high throughput.
Because it operates at layer four,
there's no extra overhead as it
processes or proxies requests.
And so that low latency might be worthwhile
even for web-based applications,
if you don't want to treat any of those requests
as requests at the load balancer tier.
The load balancer has different listener protocols
that you can configure.
And when you do that,
it's going to limit the back end type that you can choose.
So if you go with TCP,
you can only choose EC2 instances or IP addresses
for the back-end.
Same thing with TLS listeners.
But if you go with either a UDP or a combo listener,
your only option is an EC2 instance.
Now, out of all of these choices,
one of them
allows you to implement
true end-to-end encryption.
Where the traffic is encrypted on the client,
and remains encrypted all the way through to the back end,
where it can then be decrypted.
And so that would be your choice if you wanted to
implement that true end-to-end encryption.