I now want to quickly highlight some of the main points from each of the previous lectures. I started off by looking at what ELBs were and within this lecture, I explained that the main function of an ELB is to elastically manage and control the flow of inbound requests destined to a group of targets distributing requests evenly. These targets could be a fleet of EC2 instances, AWS Lambda functions, a range of IP addresses or even Containers. ELBs help you maintain your solution by minimizing outages from hardware of software faults. ALBs are also used to help handle unpredictable traffic spikes, and by default, the AWS ELB is highly available. ELBs will automatically detect failed hosts on defined metrics and divert any traffic to the remaining healthy instances. ELBs will automatically scale to meet your incoming traffic, and there are three different types available within AWS, the Application Load Balancer, the Network Load Balancer, and the Classic Load Balancer. ELB listeners define how your inbound connections are rooted to your target groups based on ports and protocols set as conditions. And target groups allow you to group resources that you want your ELB to route requests to. Rules are associated to each listener to help define how an incoming request gets routed to which target group. 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 threshold, then the ELB will mark the target as unhealthy and stop sending traffic to that target. There are two different schemes of ELBs, firstly Internet-Facing, and the ELB nodes are accessible via internet and have a public DNS name that can be resolved to its public IP address, in addition to an internal IP address as well. The internal ELB only has an internal IP address, and this means that it can only serve requests that originate from within the VPC itself. ELB nodes are placed within the AZ where you want to perform load balancing, and nodes are used by ELBs to distribute traffic to your target groups. Cross-zone load balancing will distribute all incoming traffic evenly between all targets in all configured AZs ensuring each target across the AZs have an even distribution. 

Next I looked at server certificates for encrypted requests and how ELBs manage these connections and during this lecture I covered the following points. When using HTTPS as a listener, it requires additional configuration relating to server certificates. HTTPS is an encrypted version of the HTTP protocol and this allows encrypted communication between clients initiating the request and your ALB. To receive encrypted traffic over HTTPS your ELB needs a server certificate and an associated security policy. The server certificate used is an X.509 certificate, and certificates are provisioned by a certificate authority which could be the AWS Certificate Manager or ACM. Certificates are used to terminate encrypted connections where the request is then decrypted and forwarded to a target group. Using the ACM simplifies the configuration process of implementing a new certificate for your ELB and this is the preferred option. It is also possible to use a third party certificate by using IAM and your certificate manager, and this option is required in regions not supported by ACM. 

Next I looked at the individual load balancers, and during these three lectures, we learned that the application load balancer operates at layer seven of the OSI model, and you should use the ALB if you need to provide a flexible feature set, including advanced routine and visibility features aimed purely for application architectures. The ALB has cross-zone load balancing always enabled, and the listeners supported by the ALB includes HTTP and HTTPS. The network load balancer operates at layer four of the OSI model, enabling you to balance requests purely based upon the TCP and UDP protocols and the listeners supported by the NLB included TCP, UDP and TLS. The NLB is a great choice if you need ultra high performance for your application, and cross-zone load balancing on the NLB can be enabled or disabled. The classic load balancer supports TCP, SSL, TLS, HTTP and HTTPS protocols. The classic load balancer does not offer as wide a range of features as the other load balancers. It is best practice to use the ALB over the Classic Load Balancer unless you have an existing application running in the EC2-Classic network. The classic ELB has support for EC2-Classic, TCP and SSL listeners and sticky sessions. Cross-zone load balancing can either be enabled or disabled for the classic load balancer. I also performed a number of demonstrations. We showed you have to configure each of these load balances. 

The course then had a slight change of focus as I moved onto Auto Scaling and temporarily away from Elastic Load Balancing. I began by explaining what EC2 Auto Scaling was and here I covered the following. Auto Scaling is a mechanism that automatically allows you to increase or decrease your EC2 resources to meet the demand based off of custom defined metrics and thresholds. Using metrics, you can automatically add and remove instances as and when load both increases and decreases. By scaling your resources back helps you to optimize the cost of your EC2 fleet. Advantages of Auto Scaling include automation, with the provisioning and removal of instances, greater customer satisfaction, through reliable and stable infrastructure, and cost reduction thanks to scaling-in policies. 

This then led me onto the next lecture where I discussed the different components of Auto Scaling. The main components are covered with the Launch Configuration and Launch Template in addition to the Auto Scaling group. The Launch Configuration or Launch Template define how an Auto Scaling group builds new EC2 instances, and the Launch Template provides additional features over the launch configuration including versioning and simplifies your auto scaling configuration. The Auto Scaling Group defines the desired capacity and other limitations of the group using scaling policies and which Availability Zones the Group should scale resources in. I then performed a demonstration in this lecture on how to create the launch configuration and template in addition to auto scaling groups so you could see how they were constructed. 

In the final lecture I touched on some points relating to how both ELBs and EC2 Auto Scaling can be used in conjunction with each other and here I explained that both ELB and Auto Scaling goes hand in hand to provide optimal efficiency from both a performance and cost perspective. However one without the other can cause an operation burden. When you want to associate an ALB or NLB to an auto scaling group, you actually associate the auto scaling group with the target group. When you attach a classic load balancer, the EC2 fleet will be registered directly with the load balancer. That now brings me to the end of this lecture and to the end of this course. You should now have a full understanding of AWS Elastic Load Balancing and EC2 Auto Scaling to help you build elastic, reliable, efficient and cost optimized EC2 solutions within your VPC. 

If you'd like some hands on experience on some of the topics I've discussed in this course, then we do offer a number of labs, so please do take a look. We have the Working the Application Load Balancer lab, Working with Amazon EC2 Auto Scaling Groups and Network Load Balancer, and How to Create Your First Auto Scaling Group.

If you have any feedback on this course, positive or negative, it would be greatly appreciated if you could contact support@cloudacademy.com. 

Thank you for your time and good luck with your continued learning of cloud computing. Thank you.