- Now let's talk about Load Balancing Algorithms
for the Elastic Load Balancer.
Under the hood, behind the scenes
of the Elastic Load Balancer, the way that this works
is that it creates what we call nodes, and of course,
this is not something that we really have to worry about,
it's just interesting technical knowledge
so that you can understand the behavior
of the Elastic Load Balancer.
So we have nodes, you'll notice here,
that the Elastic Load Balancing service
will place a node in every subnet
that we say we want to use.
And again, it's a good practice to use every available
availability zone in that particular region.
So we have these multiple nodes.
Each one of them will get its own IP address.
If you're using an internet-facing ELB,
these nodes will get public IP addresses.
If you're using internal Elastic Load Balancer,
then these nodes will get a private IP address.
Now, as requests come in from either the internet,
or they come in from a private service,
wherever they come in from,
once they reach the Load Balancer they are distributed
between these two nodes via DNS round robin.
So it's just going, essentially, back and forth
between these nodes.
Now, as your traffic grows and as you start to receive
more and more requests, the Elastic Load Balancer
will automatically scale the number of nodes
to handle that incoming traffic.
Now there are times when traffic is spiking faster
than the Elastic Load Balancer is scaling.
And some people seem to find that
the Elastic Load Balancer doesn't scale fast enough
for their particular traffic patterns, so in those cases,
cases where you do expect traffic to spike,
you can submit a ticket to Amazon's support
and ask them to quote unquote pre-warm
your Elastic Load Balancer and go ahead and initiate
that scaling event ahead of that wave of traffic,
and that will get you more nodes here under the hood.
So again, as traffic is coming in, it is being distributed
among these nodes via DNS round robin.
Between the node and the back-end instances,
we're going to use the least outstanding requests
as a way to determine which back-end node
should handle that particular request.
You can see here, again, we're leveraging multiple
availability zones.
As our traffic begins to scale,
we would see that we would start to add,
probably through the auto-scaling service
that we'll talk about here, coming up,
but we would start to add multiple EC2 instances,
maintaining a balance across
these multiple availability zones.
Now you'll notice here that we have multiple instances
across multiple availability zones, in this case,
we're using us-west-2, so in this example,
we have 2a and 2c, it's possible for a Load Balancer node,
over here in 2a, to send a request off to a back-end
instance in another availability zone,
and we call the Cross-Zone load balancing.
That is an option that is enabled by default,
we can turn that off if we want to,
but it's important to know that it can help maintain
an even balance of requests across our servers,
but it does incur an additional cost.
The data being transferred across availability zones
will cost us an additional bandwidth charge.
So again, requests coming in, initially,
are balanced between nodes of the Load Balancer
via DNS round robin, between the Load Balancer node
and the back-end service, those are handled
via least outstanding requests.