The application load balancer, or layer 7 load balancer, is a version 2 ELB that supports HTTP, HTTPS, and WebSocket protocols. It is important to remember that the ALB does not listen for other protocols such as VOIP, gaming, SSH, FTP, or any others. If you want to work with these protocols, you will need to deploy the network load balancer. However, since it operates at layer 7 of the OSI model, it can inspect content such as cookies, customer headers, and location- and application-specific values. This information can be used to back content-switching decisions.
ALBs support listener-based rules that make them highly customizable. You can have multiple domains connecting to the same application load balancer to simplify your deployments. Host-based rules are created to direct incoming traffic to multiple target groups for processing. Autoscaling groups can then be defined for scalability. A single application load balancer can support many applications for consolidation.
Support for Server Name Indication (SNI) is included and automatically enabled on the listener; it determines the domain of the request to match it with the correct TLS certificate for that domain. Each domain can host a TLS certificate on the same load balancer. If there is only one domain on the listener, then SNI is disabled as it is not required.
Since ALBs inspect the total stack and can read layer 7 information, there can be a large amount of processing involved for every packet that passes through it. This makes them slower than a network load balancer since the NLB uses significantly fewer processing cycles per packet. However, one of the benefits of working at the application layer is that the load balancer can evaluate the health of the application and make intelligent decisions at the application layer.
Rules are defined that process incoming connections to the listener or VIP. Rules can be stacked and processed in priority order with a default rule at the end. Rules have conditions for processing, such as information contained in the host-header, http-header, https-request-method, path-pattern, query-strings, and networking values such as the source IP address. Based on meeting the conditions in a rule, actions are then defined that tell the ALB what to do with the traffic such as where to forward it, where to redirect the connection to somewhere else, where to reply with a fixed-response, how to authenticate it, and other actions that you create.
With the ability to look into the HTTP protocol data, you can customize your web hosting to, for example, inspect for data coming from mobile phones and direct those connections to a web target group that is formatted for low-content mobile devices and then direct all other connection requests to the content-rich hosts in another target group.
The AWS gateway load balancer (GWLB) is used to integrate virtual appliances from third-party vendors in a VPC, as shown in Figure 4.1. These appliances can be a wide range of offerings and include firewalls, analytics systems, network visibility, and intrusion detection prevention systems. The key feature is that the GWLB has a single point of ingress and egress for all traffic, performs the load balancing function, scales the virtual appliances, does not modify the packet for transparent flows, and can work with overlapping CIDR address blocks.
FIGURE 4.1 Gateway load balancing
By inserting logic and advanced functions directly into the network flow path, many new advanced features can be implemented. The gateway load balancer is used to insert new functions, features, and services into the network flow path. Since it is an AWS managed service, it manages the complexity, uptime, capacity, and ongoing maintenance of the underlying infrastructure. Services offerings for analytics, security, and Internet of Things, to name a few examples, can leverage the GWLB for better integration with your AWS deployment.
The gateway load balancer is a layer 3 product that uses the GENEVE protocol to encapsulate traffic, which allows the packets to be in the original state when delivered to the appliances that must also support the GENEVE protocol. We will go into GENEVE later in this chapter.
The gateway load balancer is strictly a packet in/out device that does not have any layer 7 application awareness to perform any SSL/TLS encryption/decryption operations. It does not maintain state information. All these features are the responsibility of the target appliances.
The architecture, as shown in Figure 4.1, uses a gateway load balancer endpoint (GWLBE) that connects the GWLB to another VPC. The GWLBE is a VC endpoint. The GWLB can be connected to any number of GWLBEs. The GWLB has a front end that attaches to the GWLBE and to the outside world. The backend is the load balancer section that connects to the virtual appliances with encapsulated packets to preserve the original format with no modifications made by the GWLB. Session stickiness, health checking, and failover are performed on the backend.
Packets that are sent from the source to the destination do not contain the GWLB’s listener IP address, and the GWLB is transparent to the flow. Route table modifications direct the traffic into and out of the GWLB.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
