Hey guys, in this lesson I'm going to cover ALB and NLB deployments in a bit
more detail. So let's start. Looking at an Application Load Balancer, with ALBs
and NLBs, we always have target groups. And that's where we can register our instances. The target
groups define the target type. So for example, is it an instance? Is it a Lambda function? Is it
an IP address? And the target protocol and port. The target protocol and port is the protocol and
port on which the application is running on the instance itself. So if it's a web server, it's
going to be HTTP 80 or HTTPS port 443 by default. Next, we have the VPC that the instances are in, and health checks. So the health checks define
which port and protocol is going to be used by the load balancer to check whether the
instances are available and healthy and ready to receive connections. And only if they
are, will it forward any connections to them. And then we've got the registered targets
themselves. So we can register the targets manually, or we can attach the target group
to an Auto Scaling Group and they'll be registered dynamically as they're launched and
removed when they're terminated by the ASG. We then have our load balancer. On the
load balancer, there is a listener. Here we get to define the protocol and port
that the load balancer listens on. And this can be different from the
target group protocol and port. We have routing rules for an
Application Load Balancer, and we can assign certificates for encryption as
well. We can also define the network mapping. So which availability zones and subnets are
our instances going to be registered into. Now when we do that, when we actually
define those availability zones and subnets, the load balancer deploys its nodes into each
availability zone that it's mapped to. So these are the actual deployments of the load balancer
itself. They're added to each of these AZs. Now we can actually send traffic through
to our instances in the Target group. Let's have a look at the supported
configurations for ALB versus NLB. For ALB, the target type can be instance, IP
address, or Lambda function. The protocol must be HTTP and HTTPS. Also, the health check protocol
must be HTTP or HTTPS as well. You cannot use TCP, even if you specify the correct port number
like TCP 80. You won't actually be able to see the target group when you create
the load balancer through the console, and you won't be able to attach it by any means. You can also define rules for advanced request
routing with the ALB, but not with the NLB. Now, the NLB has targets which
can be instances, IP addresses, or Application Load Balancers. The reason
ALB is in there is because you can put a Network Load Balancer in front of an ALB
that might help you with connections. The Network Load Balancer provides very low
latency, so it's great for large numbers of connections with very minimal latency. And then
you can have your Application Load Balancers behind the NLB. The target group
protocol must be TCP or UDP for an NLB, and any health check protocol is supported. You can also define the elastic IPs per subnet; that's something that's specific to the
NLB. So now you can have a static public IP address assigned to those nodes that
are running in each availability zone. Now, we have advanced request routing with
the ALB. Let's have a look at how that works. Here we have instances across multiple
AZs and organized into different Target groups. The target groups are used to then route
requests through to those specific instances, which may be running different
components of an application. Then we have our load balancer,
which has a listener. ALBs, as you know, listen on HTTP protocol
or HTTPS. With path-based routing, we can actually specify rules, and
the rules will look at the URL. So remember that a load balancer, an Application
Load Balancer, is a Layer 7 load balancer, and so it can look at information in the HTTP
header at Layer 7, and that includes in this case the path. So we can route requests to
different Target groups based on the path. Here we got example.com/specials or /orders,
and they're going to different Target groups, different components of our application. That's
path-based routing. With host-based routing, we have a different host
header: members.example.com, and the request is going to forward
through to Target group three. So we can combine these as well; we can have
host-based routing and path-based routing. And there are several other
different mechanisms we can use for advanced request routing with
the ALB. So with host-based routing, we're routing based on the host field in the
HTTP header, essentially the subdomain. In this example, targets for the ALB can be EC2
instances, IP addresses, or Lambda functions. Next, we have the Network Load Balancer. And
here we have two target groups. In an NLB, we can assign elastic IPs in each subnet that
the load balancer is connected to. The NLBs will listen on TCP, TLS, UDP, or TCP_UDP. The NLB
does not support the advanced request routing that the ALB does, but you can create multiple
listeners and listen on different ports. So in this case, a separate listener on
a unique port is added, and then requests for that specific application running
on that port number can be forwarded to a different Target group. You could
do that on ALB as well; you can have multiple listeners with different ports. And
they always do have to be different ports; you can only have one listener per load
balancer for an individual port number. Here, requests are routed based on the IP protocol
data. So what is the port number that we're connecting to? Targets can be EC2 instances, IP
addresses, or ALBs as we mentioned before. Targets can also be outside of a VPC, so for example,
they could be in an on-premises data center. Now, here's a question: What is the source
IP address that the application is going to see? So connections come into the load
balancer, and we want to understand what is the source IP address of the client. It
comes up in exam questions sometimes. Also, it's important to understand if you need to
log that information; potentially, you need to do some kind of screening as well. It could be
for licenses, it could be for security purposes. So let's say that the client's IP address on the
Internet is A. And here we have the load balancer; the load balancer has nodes, and
those nodes have IP addresses. So let's say that the node that it's being
forwarded through is B. The CLB and the ALB use the private IP address of
their ENIs as the source address. So in this case, the application
is going to see IP equals B. Okay, so it's going to see. So the application
running here is going to see that the client is actually the load balancer itself.
It doesn't see the address of the client. With an NLB, again, we've got the IP addresses: A for the client IP addresses, B for
the nodes of the load balancer. Now, if the instance is specified by instance
ID when you add it to the Target group, then the IP address is going to be A. So the
application is going to see the IP address of the client. So that could be useful for logging
purposes or other security purposes as well. Now, if in the same circumstance, however,
the only difference being that we've specified the instance by IP address
instead of instance ID, in that case, the IP address seen by the application
is B. Okay, the load balancer nodes. Now, what I've just shown you with the NLBs is
applicable when you're using TCP and TLS. If you're using UDP or TCP_UDP, then the IP address
is going to be a little bit confusing, I know, and it really depends on the different ports and
protocols. But there is a great link, which I'll share with you, that you can follow to the AWS
website where you can read a lot more about this, and hopefully, it will make sense once you've
been through that as well as watching this video. When using an NLB with a VPC
endpoint or Global Accelerator, the source IP addresses are the
private IPs of the NLB nodes. Lastly, the X-Forwarded-For can be used with the
ALB to capture client IPs. X-Forwarded-For is a type of header. What it means is if we enable that
header in our application, then we will actually be able to capture those client IP addresses.
So they are actually there somewhere in the IP protocol information that's being sent through,
but we need to enable this specific header.
