Since the application load balancer terminates the connection from the client and establishes a backend session to the target servers, the IP addressing will change along the path. The downside to this is that the target servers do not see who originated the packet since the load balancer has changed the source IP address. To get around this issue, additional data has been added to the HTTP/HTTPS header to append the source IP address and all of the other IP addresses that may be used along the path from the client to the backend server.
The X-Forwarded-For (XFF) protocol is used to deliver the actual source IP address in the header for the destination devices to read. This is a layer 7 extension that works with HTTP and HTTPS only. The proxy or load balancer will add data to tell the server what the actual source IP address of the request is. The client IP address gets added to the list, and as the packet progresses through the network, additional IP addresses are appended as needed. It is important to make sure that the backend server has the ability to read this header, which may require installing a module or upgrading the server application to be able to read the X-Forwarded-For header.
The backend web servers will see the source IP address of the load balancer but can now look inside the HTTP header and see the actual IP address of the client that originated the request. Since this is a web-based protocol at layer 7, only the application load balancer supports the header, and a network load balancer will not since it is only layer 4 aware. Non-HTTP /HTTPS-aware load balancers will use the proxy protocol instead of the X-Forwarded-For protocol.
The ALB looks for the client’s IP address at the routing.http.xff_header_processing.mode attribute; this is the attribute that can be modified or removed from the X-Forwarded-For header before it is sent from the ALB to the target server.
In high availability load balancing designs, it is desirable to spread your instances across multiple availability zones to protect from an AZ failure causing a complete failure of your deployment. The cross-zone load balancing distributes the load across all registered instances in all of the availability zones you define evenly. Route 53 DNS will evenly distribute connections across the availability zones with application load balancer nodes.
This feature is enabled by default with the application load balancer. See Figure 4.7 as an example of a cross-zone load balancer architecture. Notice that availability zone A has two servers and B has four. With cross-zone load balancing disabled, the load would be distributed 50 percent to each AZ. This would create an imbalance as AZ-A has only two servers but gets 50 percent of the traffic resulting in each server processing 25 percent of the load. AZ-B would also get 50 percent of the connections but has four servers in its target group resulting in less server load than AZ-A at 12.5 percent per server.
FIGURE 4.7 Cross-zone load balancing
Using the cross-zone load balancing feature, each server will now receive equal amounts of the load. When enabled, the feature takes into consideration the target server count in each AZ and balances the connections automatically to all registered instances in all availability zones, resulting in optimal server load. There is no reason to not leave this enabled on the ALB.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
