THE AWS CERTIFIED ADVANCED NETWORKING – SPECIALTY EXAM OBJECTIVES COVERED IN THIS CHAPTER MAY INCLUDE, BUT ARE NOT LIMITED TO, THE FOLLOWING:
Objective 1.3: Design solutions that integrate load balancing to meet high availability, scalability, and security requirements.
In Chapter 1, “Edge Networking,” you learned that the Elastic Load Balancer (ELB) is the AWS family of managed services that distributes request loads across many servers. The ELB family automatically balances and distributes traffic across EC2, Lambda, and micro services. In this chapter, we will take a deeper look into the details of the load balancers to give you an understanding of the features, use cases, security, and integrations to prepare you for the exam. The ELB services include the application load balancer, the network load balancer, and the gateway load balancer. The classic load balancer was introduced in 2009 and was retired in 2022; it’s no longer used and has been removed from the AWS console.
You may come across references to version 1 and version 2 of the ELB offerings. Version 1 refers to the classic load balancer that has been deprecated and is no longer available. Everything is now version 2. The advantages of using a version 2 load balancer include a much faster product, lower cost, target groups, rules, and the most recent features in the ELB family.
The primary function of a load balancer is to act as a front end to services, receive connections from customers, and then distribute the connections to backend groups of compute services such as virtual machines or microservices such as Docker containers. This shares the processing workload over more than one server, and if a server in the group should fail, the application can continue to function using the remaining servers.
With this architecture, the backend servers and applications are abstracted from the users. This allows you to add, remove, modify, and reconfigure the backend servers without affecting the user experience.
ELBs allow for a decoupling of services between application tiers and allow for each layer to scale independently of the other layers.
Load scaling can be automated with the CloudWatch integrations to monitor the load on the servers and add or remove servers based on load or to replace a failed server using autoscaling groups.
ELBs support cross-zone load balancing where servers can be placed in two or more availability zones and requests can be allocated between AZs.
When configuring a load balancer, listeners are created to accept the customer traffic on a user-specified port and protocol. Then, on the backend, the ELB will communicate with the target servers using configured ports and protocols.
The public load balancer backend communications can use either public or private addresses on the target servers. However, there is no requirement that the backend servers be publicly addressed and they can sit in the private address space if that meets your design and security requirements.
ELBs need at least eight IP addresses in the subnet they are assigned. This means that a /28 is the smallest subnet that can be used. However, it is strongly recommended to use a /27 or larger subnet for scalability.