To prevent a new target from being overwhelmed with connection requests when it is first brought online, there is a slow start feature that allows the server to gradually process new requests after the new target passes its health checking and comes online. This gives the server time to “warm up.” The ELB will increase connection requests in a linear manner until the time window is met and the server is fully online.
The GENEVE protocol is used with the gateway load balancer to preserve the original packet by providing a protocol that supports transparent routing. To make sure that the original packet remains intact, the GENEVE protocol encapsulates the original packet in a new header that the GWLB and appliances both support. This preserves the headers that the appliances need to process and allows for the separation of customer traffic, which may also have overlapping CIDR addresses. GENEVE is similar to VxLAN and Generic Routing Encapsulation (GRE) at layer 3 but does not have the fixed field size limitations of these protocols. This makes it more flexible for load balancing implementations.
The GENEVE protocol is an industry standard defined in RFC 8926.
FIGURE 4.12 Health check configuration
The ELB can actively support encryption operations to take the workload off the target servers and consolidate security operations in a smaller footprint. Alternatively, the load balancer can be configured to pass through the encrypted in-flight data to the backend servers for processing.
In this section, you will learn about how the load balancers process encrypted in-flight traffic.
The ALB can also process user authentication requests and take that workload off the target servers.
In traditional web hosting environments where SSL/TLS encryption is deployed, the web servers terminate the SSL/TLS connections. This architecture is not optimal as it consumes processing power on the web servers to perform the encryption and decryption operations for in-flight packets. Digital certificates needed to be installed on each server, which created operational overhead as the certificates needed to be installed, managed, and periodically rotated across many servers. Also, security operations were spread across all of the servers, where it would be optimal to have them in a central device or, at least, a small number of devices.
With TLS offload, the load balancer takes responsibility for the encrypting and decrypting of in-flight traffic as it sits in the direct path of the traffic flow and is the listener interface that accepts all traffic from the outside. With the offload on the load balancer, the traffic can then be sent to the backend servers for processing without the need for those servers to perform any encryption functions, as shown in Figure 4.13.
When using the load balancer for offload, the digital certificate is bound to the load balancer’s outside-facing VIP listener. Incoming encrypted traffic will terminate TLS on the VIP to offload the encryption process from the backend servers. As was previously mentioned in this chapter, this allows for a central point of administration, a single certificate to be installed, and centralized logging and monitoring of your in-flight encryption. The TLS operations are offloaded from the real servers in the backend pool to the load balancer.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
