Hello and welcome to this lecture, which is going to focus on what the AWS Elastic Load Balancer service is and does. 

Now the main function of an Elastic Load Balancer, commonly referred to as an ELB, is to help manage and control the flow of inbound requests destined to a group of targets by distributing these requests evenly across the targeted resource group. These targets could be a fleet of EC2 instances, Lambda functions, a range of IP addresses, or even Containers. The targets defined within the ELB could be situated across different Availability Zones for additional resiliency or all placed within a single Availability Zone. Let's look at this from a typical scenario. 

Let's suppose you have just created a new application, which is currently residing on a single EC2 instance within your environment, and this is being accessed by a number of users. At this stage, your architecture can be logically summarized as shown. If you are familiar with architectural design and best practices, then you would realize that using a single instance approach isn't ideal although it would certainly work and provide a service to your users. However, this infrastructure layout brings some challenges. For example, the single instance where your application is located can fail, perhaps from a hardware or software fault. And if that happens, your application will be down and unavailable to your users. Also, if you experience a sudden spike in traffic, your instance may not be able to handle the additional load based on its performance limitations. As a result, to strengthen your infrastructure and help remediate these challenges, the unpredictable traffic spikes and high availability, et cetera, you should introduce an Elastic Load Balancer, an additional instance that's running your application into the design as shown. 

As you can see, in this design, the AWS Elastic Load Balancer will act as the point for receiving incoming traffic from users and evenly distribute the traffic across a greater number of instances. By default, the ELB is highly available as this is a managed service provided by AWS. And so, they ensure its resilience so we don't have to. Although it might seem that ELB is a single point of failure, the ELB is in fact comprised of multiple instances managed by AWS. Also in this scenario, we now have three instances running our application. Now let me revisit the challenges we discussed previously. If any of these three instances fail, the ELB will automatically detect the failure based on defined metrics and divert any traffic to the remaining two healthy instances. Also if you experience a surge in traffic, then the additional instances running your application would help with the additional load. One of the many advantages of using ELB is the fact that it is managed by AWS, and it is, by definition, elastic. This means that it will automatically scale to meet your incoming traffic as the incoming traffic scales both up and down. 

If you are system administrator or DevOps engineer running your own load balancer by yourself, then you would need to worry about scaling your load balancer and enforcing high availability. With an AWS ELB, you can create your load balancer and enable dynamic scaling with just a few clicks. Depending on your traffic distribution requirements, there are three ELBs available within AWS to choose from. 

Firstly, the Application Load Balancer. This provides a flexible feature set for your web applications running the HTTP or HTTPS protocols. The Application Load Balancer operates at the request level, and it also provides advanced routing, TLS termination, and visibility features targeted at application architectures, allowing you to route traffic to different ports on the same EC2 instance. 

Next, there is a Network Load Balancer. This is used for ultra-high performance for your application while at the same time managing very low latencies. It operates at connection level, routing traffic to targets within your VPC, and it's also capable of handling millions of requests per second. 

Finally, the Classic Load Balancer. This is primarily used for applications that were built in the existing EC2 Classic environment and operates at both the connection and request level. We'll now talk a little bit about the components of an AWS ELB and some of the principles behind them. 

Listeners. For every load balancer, regardless of the type used, you must configure at least one listener. The listener defines how your inbound connections are routed to your target groups based on ports and protocols set as conditions. The configurations of the listener itself differs slightly depending on which ELB you have selected. I will dive into the configuration of these as I discuss each ELB in further detail in upcoming lectures. 

Target groups. A target group is simply a group of resources that you want your ELB to route requests to, for example a fleet of EC2 instances. You can configure your ELB with a number of different target groups, each associated with a different listener configuration and associated rules. This enables you to route traffic to different resources based upon the type of request. Rules. 

Rules are associated to each listener that you have configured within your ELB, and they help to define how an incoming request gets routed to which target group. As you can see, your ELB can contain one or more listener. And each listener can contain one or more rules, and each rule can contain more than one condition, and all conditions in the rule equal a single action. An example rule could look as follows where the if statement resembles the conditions and the then statement acts as the action if all the conditions are met. So, depending on which listener request was responded to by the ELB, a rule based upon a priority listing would be associated containing these conditions and actions. If the request came from within the 10.0.1.0/24 network range, which is the first condition, and was trying to carry a HTTP PUT request, the second condition, then the request would be sent to the target group entitled Group1, which is the action. 

Health checks. The ELB associates a health check that is performed against the resources defined within the target group. These health checks allow the ELB to contact each target using a specific protocol to receive a response. If no response is received within a set of thresholds, then the ELB will mark the target as unhealthy and stop sending traffic to that target. 

Internal or Internet-facing ELBs. There are two different schemes that can be used for your load balancers, either internal or Internet-facing. Internet-facing, as the name implies, the nodes of the ELBs that are defined as Internet-facing are accessible via the Internet and so have a public DNS name that can be resolved with public IP address. This would be in addition to an internal IP address as well. This allows the ELB to serve incoming requests from the Internet before distributing and routing the traffic to your target groups, which in this instance could be a fleet of web servers receiving HTTP or HTTPS requests. When your Internet-facing ELB communicates with its target group, it will only use the internal IP address, meaning that your target group does not need public IP addresses. An internal ELB only has an internal IP address. This means that it can only serve requests that originate from within your VPC itself. For example, you might have an internal load balancer sitting between your web servers in the public subnet and your application servers in the private subnet. 

ELB nodes. During the creation process of your ELBs, you're required to define which Availability Zone you'd like your ELB to operate within. For each Available Zone selected, an ELB node will be placed within that Availability Zone. As a result, you need to ensure that you have an ELB node associated to any Availability Zones for which you want to route traffic to. Without the Availability Zone associated, the ELB will not be able to route traffic to any targets within that Availability Zone even if they are defined within the target group. This is because the nodes are used by the ELB to distribute traffic to your target groups. 

Cross-Zone load balancing. Depending on which ELB option you select, you may have the option of enabling and implementing Cross-Zone load balancing within your environment. Let's presume you have two Availability Zones activated for your ELB with each associated load balancer receiving equal amount of traffic. One Availability Zone has six targets, and the other has four as shown. When Cross-Zone load balancing is disabled, each ELB and its associated AZ would distribute its traffic with the targets within that Availability Zone only. As we can see from the image, this results in an uneven distribution of traffic for each target across the Availability Zones. With Cross-Zone load balancing enabled, regardless of how many targets are in an associated Availability Zone, the ELBs would distribute all incoming traffic evenly between all targets, ensuring each target across the Availability Zones have an even distribution. 

That now brings me to the end of this lecture. In the lecture, I shall be discussing server certificates and how they are used with load balancers to help terminate encrypted requests.