- The most commonly used elastic load balancer
deployment mode is the ALB or application load balancer.
Now, this load balancer
is a little different than the others
in that it only operates at Layer 7
of the seven-layer OSI model,
which is the application layer.
It is designed to accept inbound traffic.
It can be internet-facing or internal only,
and you can attach one or more TLS certificates to it
so that it can accept HTTPS for different domains
on the same load balancer.
It also allows for a little bit of intelligence.
You can figure out how to route requests
based on the properties of the request itself
using path-based routing
and then deliver those requests to different locations.
It also supports redirects.
So if you wanna create a redirect engine
with 301 or 302 redirects, you can do that.
And it's one of the few services
that is supported by the AWS WAF
or Web Application Firewall service
that allows you to filter or block requests
if they don't meet certain criteria.
There are a number of good use cases
where the application load balancer
is the appropriate one to choose.
If you have stateless web applications
where you have a number of backend resources
that are performing identical work in a stateless fashion,
it is worth considering the ALB.
Even if you have stateful application servers,
the ALB does support stickiness if you want to configure it.
And really, any web-based application
that is using HTTP or HTTPS requests
could be a good candidate for this load balancer.
So let's take a look at an example of where a feature
called TLS Certificate Smart Selection
can be really important.
In this example, I have two target groups
that are attached to the same load balancer.
One of them is running ECS task containers
and the other is an auto-scaled group of EC2 instances
and they perform two different tasks.
I have two certificates attached to my load balancer,
both of them provisioned through the ACM
or AWS Certificate Manager Service,
for two different domains,
*.brightkey.cloud and *.brightkeycloud.com.
Now, our end user issues a request using HTTPS
and then www.brightkeycloud.com
and that through path-based routing can be delivered
to the auto-scaling group of EC2 instances
and say this is our main website and dynamic pages.
And the ALB automatically picks the correct certificate
based on the domain and the request.
And when it is time to log into the website,
the client issues a request
to https://login.brightkey.cloud.
And through path-based routing, that is delivered
to the ECS containers instead for authentication
and that also uses the correct certificate
so that there's no browser warning
because of a mismatched domain.
The ALB supports up to 25 TLS certs.
So we've talked a little bit
about how we can route our requests
based on their properties.
That's called path-based routing. How do we do it?
Through listener rules.
Each listener that you create on your load balancer
has an ordered list of rules that you can create and manage.
And these listener rules are going to have a condition type
associated with each rule.
And this would be the property of the request
that you use to determine where you're going to route it.
And there's a number of options here:
the host-header, the http-header, the request-method,
the path-pattern, the query-string,
and this last one is important,
you can even filter based on the source-ip.
Now, once you've done that, you gotta figure out
what you're gonna actually do with the request
and you have a number of options here too.
You can authenticate the request
against another AWS service called Cognito.
You can authenticate the request
against any open ID-compatible identity provider.
You can return a static response that could be text or HTML.
It just has to be a static string.
You can issue a 301 or 302
to redirect to some other location.
You can forward the request to a target group,
and this is how most of the actual work is gonna get done.
But that's not all.
You can actually forward to more than one target group
and you can configure weights between them,
which makes for a really elegant way
of performing a blue-green deployment.
If you are upgrading
from one version of an application to another,
you can gradually change those weights to shift the traffic
from one target group to the other.