Adrian Cantrill’s SAA-C02 course, 50 minutes: Elastic Load Balancer Architecture (part 1)
This lesson focused on the high level logical and physical architecture of Elastic Load Balancer.
Load balancers are explained herein as accepting connections from customers, and then distributing those connections across any registered backend compute. It means the user is abstracted away from the physical infrastructure. It means the amount of infrastructure can change, so increase or decrease in number without affecting customers. Because the physical structure is abstracted, it means that infrastructure can fail and be repaired, all of which is hidden from customers.
Application load balancers support many different kinds of compute services. When you provision a load balancer, you have to decide on a few important configuration items. First, you need to pick whether you want to use IPv4 or only dual stack. Dual stack means using IPv4 and the newer v6. You also need to pick the Availability Zones which the load balancer will use. Specifically, you’re picking one subnet in two or more Availability Zones. This leads in to the architecture or Elastic Load Balancers, how they actually work. Based on the subnets that you pick, inside Availability Zones, the product places into these subnets, one or more load balancer nodes. So what you see as a single product is actually made up of multiple nodes, and these nodes live within the subnets that you pick. So when you are provisioning a load balancer, you need to select which Availability Zones it goes into, and the way this is done is by picking one and one only subnet in each of those Availability Zones.
When a load balancer gets created it gets created with a single DNS record, an A record, and this record actually points at all of the Elastic Load Balancer nodes that get created with the product. So any connections that are made using the DNS name of the Load Balancer are actually made to the nodes of that Load Balancer. The DNS name resolves to all of the individual nodes. It means that any incoming requests are distributed equally across all of the nodes of the Load Balancer and these nodes are located in multiple Availability Zones and they scale within that Availability Zone, so they’re highly available.
If one node fails it is replaced, if the incoming load to the Load Balancer increases then additional nodes are provisioned inside each of the subnets that the Load Balancer is configured to use.
Another importan decision is to decide if the Load Balancer should be internet-facing or whether it should be internal. This decision controls the IP addressing for the Load Balancer nodes. If internet facing is chosen, then the nodes of that Load Balancer are given public addresses and private addresses. If you pick internal, then the nodes only have private IP addresses. Other than this, they’re the same architecturally, they have the same nodes and the same Load Balancer features. The only difference between internet-facing and internal-facing is whether the nodes are allocated public IP addresses.
The connections from our customers that arrive at the Load Balancer nodes, the configuration of how that’s handled is done using a listener configuration. As the name suggests, this configuration controls what the Load Balancer is listening to, so what protocols and ports will be accepted at the listener or front side of the Load Balancer. If you want the Load-Balancer to be accessible from the public internet, it has to be internet facing.
In order to function, Load Balancers need 8 or more free IP addresses in the subnets that they’re deployed into. Now, strictly speaking, this means a /28 subnet, which provides a total of 16 IP addresses, but minus the five reserved by AWS, but this leaves 11 free per subnet. But AWS suggests that you use a /27 or larger subnet to deploy an Elastic Load Balancer in order that it can scale. Strictly speaking, both a /28 and a /27 subnet are correct in their own ways to represent the minimum subnet size for a Load Balancer. AWS do suggest in their documentation that you need a /27, but they also say you need a minimum of eight free IP addresses. A /28, which leaves 11 free, won’t give you the room to deploy a Load Balancer and backend instances. In most cases, /27 is the correct value for the minimum for a Load Balancer.
Internal Load Balancers are architecturally just like internet-facing Load Balancers, except they only have private IP’s allocated to their nodes and so internal Load Balancers are generally used to separate different tiers of applications.
CloudMastermind 