Proxy protocol connections are used by the classic load balancer to inject source and destination IP addresses and port numbers into the connection request by the load balancer before sending it to the target server. Both TCP and SSL/TLS support is standard. Many applications require this data to not be modified by the load balancer, so the proxy protocol was created to allow the source information to pass through the load balancer and into the web target servers.
Since the application load balancer inserts X-Forwarded_For HTTP headers, proxy protocol support is not required on that platform. On network load balancers, the IP source information is passed through, so there is no need to support the proxy protocol. Only on the classic load balancer is proxy protocol supported. Note that if you are already running the proxy protocol on another device in front of the classic load balancer, you do not enable it on the ELB as they will interfere with each other.
AWS availability zones are physically and logically separated data centers in a region. By placing groups of servers into different availability zones and load balancing the workloads between them, resiliency can be achieved. If an AZ should go offline for whatever reason, then the workload can shift to the remaining AZ for continuity.
Cross-zone load balancing is supported in both the application and classic load balancers, as shown in Figure 1.11. This feature allows you to load balance across AZs and not have standby servers in a separate availability zone for fault tolerance.
FIGURE 1.11 Cross-zone load balancing
Layer 7 application load balancing allows us to make connection decisions based on many different data points such as URLs, headers, cookies, or any other attribute.
Deployments can be either internal when configured with an internal VPC IP address or external to the Internet with a public, Internet-facing IP address. Security groups and access control lists can be configured in your VPC for security. When the ALB is external facing, AWS Shield or Shield Advanced protects your data from Internet exploits.
ALB supports the latest SSL/TLS security transforms and current features such as HTTP/2 that can use 256 sessions on a single connection from the client. Inter-service microservice communications can leverage the gRPC now available in the ALB using HTTP/2.
HTTPS support is integrated with AWS Certificate Manager and Identity and Access Manager (IAM). SSL/TLS offload allows the load balancer to perform all encrypt and decrypt operations on the platform to reduce the encryption burden normally assumed by the target servers. Predefined policies can be used to simplify the configuration process.
When a server is being taken offline or disabled, connection draining can be implemented to allow existing connections to complete their operations and prevent any new connections from being made to the server. This allows for a nondisruptive operation that is transparent to the end users. Connection draining is sometimes called a deregistration delay. When enabling this feature, you will need to specify a time period that the ELB will maintain the connections before deregistration takes effect. The default value is 300 seconds (5 minutes) with a supported range of 1 to 3,600 seconds (one hour). When the time value is reached, the connections are forced off the device.
Acedexam Training Policies
Learning resources
Other resources
Our Training Providers
