- Now let's run through another demo of creating an elastic
load balancer.
Again, from the AWS console dashboard, I'm going to go
to EC2, that's where we find the elastic load balancer.
I'm gonna scroll down here to the bottom, you can see
Load Balancing, under Load Balancers, we have one that
was created from an earlier demo, an earlier exercise,
so I'm going to just leave that one as it is, and we're
going to hit Create Load Balancer.
From here we have two choices, we can create an application
load balancer, which actually does layer 7 load balancing
looking at the content, or we can choose a classic load
balancer which is just a lower layer at the port layer.
So we're going to choose classic load balancer,
just as an example, click Continue.
I'm gonna call this one again AWS Live Lessons.
I'm gonna choose the VPC, in this case I'm gonna go
with the one that we've created in an earlier demo.
Here, on second thought, I wanna go with one that actually
has some instances running in it.
We need at least one listener, again I can choose HTTP,
HTTPS or just Raw TCP.
For this demo I'm just gonna choose HTTP and add that
listener, in order for our elastic load balancer to have
a network footprint into our VPC, we have to choose
some subnets, and so it happens that this particular VPC
only has two and both of them are public, so I'm just
gonna go ahead and add both of those.
Next, we can assign security groups.
Whoops, I ended up inadvertently adding an extra listener
that we don't need so I'm gonna remove that one.
We're going to assign security groups, you can see here
we have a security group for our web servers, but typically,
it's a good practice to have a security group per function
or per tier, so our load balancer would typically get
it's own security group, so I'm gonna go ahead and say
Create a New Security Group, I'm gonna call this one
AWS Live Lessons ELB.
And I'm going to say I want to allow HTTP traffic from
anywhere going to configure a health check, and from here
the health check is how the load balancer knows that our
backend instances are indeed healthy and sending
the proper response.
So it's up to us to configure this appropriately.
So yes I'm going to assume that my server is listening
on port 80 and my ping path will be whatever
that application is set to, sometimes it could be just
slash, it might be status, you can configure your webserver
with a very specific health check path, so long as your
backend server returns an HTTP 200 response, then the ELB
will consider it healthy.
Anything other than a 200, any 300 responses, 400s and 500s
will be considered unhealthy.
In the case of using the elastic load balancer along with
auto scaling, if the ELB determines that your instance
is unhealthy because it's gotten too many non-200 responses
then the ELB will report an unhealthy status to
the autoscaling group, which could mean that your instance
will be terminated, sometimes you want that to happen,
other times you might not, so really take your time
to understand what the health check should be for your
particular application.
Here, we're going to give that health check five seconds
to deliver a response which actually is a really long time.
We're going to do it every 30 seconds, we can change that
to 60 if we wanted to, we're going to say that it's gonna
take three checks in a row returning non-200 responses
to set that particular instance to be unhealthy.
I'm gonna change this one to 2 and say that it takes 200
responses in a row in order for the machine to be considered
healthy.
Next we can add EC2 instances, you can see that we have
our choice of these two that are running within the same
VPC within the subnets that we've chosen.
I'm gonna go ahead and add these even though I know
we don't necessarily have these configured yet for HTTP
traffic but we could come back and do that later.
You can see here that cross zone load balancing is enabled
by default, and connection draining is also enabled
by default, connection draining says that here we have it
configured for 300 seconds, which is also a very long time,
it's five minutes, and connection draining just says that
if we are going to remove an instance, whether we do it
manually or we allow autoscaling to do it, if we're going
to remove an instance from the load balancer, before the
load balancer lets us do that, it's going to stop receiving
incoming connections and it's going to allow the outstanding
requests to finish, that's important because if we just
simply yank an instance out from behind the load balancer,
users could end up with a blank white page, they could end
up with a half a file downloaded and we don't want that,
so connection draining allows those in flight requests
to be finished.
Though I usually lower this to something more reasonable,
I generally think 300 seconds is a long time.
Especially for API, most requests should happen in a mere
fraction of that, so we could lower that to whatever
makes the most sense for our application.
We're going to add some tags, again I typically like to add,
this is my particular pattern, I have my own way
of organizing an infrastructure, but again, you should be
leveraging tags to organize it in whatever way makes the
most sense for your business, ultimately I think the most
important thing regardless of the names of the tags you use
and the values that you use, I think the most important
thing is that you find a pattern and stick to that pattern
so that you can predict what the tags will be
and be consistent about it, so here, again, AWS Live Lessons
ELB, and I'm going to add an environment variable.
And now we can review this, make sure that we have
everything set the way we think it should be, we're in
the right subnets, we have the right instances in place,
and I'm gonna go ahead and hit Create.
There we go, just like that, our load balancer is created,
and here it is, this is the one we've just created,
we can scroll down here and see that it is an internet
facing load balancer, here's our DNS name, so this is how
we would connect to that, we would point our end users
to this DNS entry.
More likely we would use this DNS entry as the destination
of a C name or within Amazon Route 53 DNS, we could create
what we would call an alias record out of this.
Here's our instances, you can see that these two instances
were registered with the load balancer, and you can see
they are out of service because they're still registering
with the load balancer, it sometimes takes it a minute
for the services to fully register with the load balancer,
and then it'll take even more time, perhaps another minute
for it to pass two consecutive health checks.
We can go over here and review our health check and make
changes to that if we want.
We can see the listeners that we've put in place, we can
edit that and add a HTTPS listener, and of course in order
to do that we would have to have an SSL certificate which
we don't have, but we could get one for free through the AWS
certificate manager if we wanted to.
So I'm going to cancel that and just leave it at HTTP
for now.
We can also see monitoring, this is out of the box
monitoring, so once we start getting traffic coming through
this load balancer, we can start to see, you know,
1 being the number of unhealthy host vs healthy host,
we can see latency, the number of requests that we're
getting, backend connection errors, you know, 500s versus
400s versus 200s and so on.
So again, once we have traffic we'll start to see some
graphs here.
So that's it, that's really easy to create an elastic
load balancer.