PERF05-BP04 Leverage load-balancing and encryption offloading - AWS Well-Architected Framework (2023-04-10)
Implementation guidanceResources

PERF05-BP04 Leverage load-balancing and encryption offloading

Use load balancers to achieve optimal performance efficiency of your target resources and improve the responsiveness of your system.

Desired outcome: Reduce the number of computing resources to serve your traffic. Avoid resource consumption imbalance in your targets. Offload compute-intensive tasks to the Load Balancer. Leverage cloud elasticity and flexibility to improve performance and optimize your architecture.

Common anti-patterns:

  • You don’t consider your workload requirements when choosing the load balancer type.

  • You don’t leverage the load balancer features for performance optimization.

  • The workload is exposed directly to the Internet without a load balancer.

Level of risk exposed if this best practice is not established: High

Implementation guidance

Load balancers act as the entry point for your workload and from there they distribute the traffic to your back-end targets, such as compute instances or containers. Choosing the right load balancer type is the first step to optimize your architecture.

Start by listing your workload characteristics, such as protocol (like TCP, HTTP, TLS, or WebSockets), target type (like instances, containers, or serverless), application requirements (like long running connections, user authentication, or stickiness), and placement (like Region, Local Zone, Outpost, or zonal isolation).

After choosing the right load balancer, you can start leveraging its features to reduce the amount of effort your back-end has to do to serve the traffic.

For example, using both Application Load Balancer (ALB) and Network Load Balancer (NLB), you can perform SSL/TLS encryption offloading, which is an opportunity to avoid the CPU-intensive TLS handshake from being completed by your targets and also to improve certificate management.

When you configure SSL/TLS offloading in your load balancer, it becomes responsible for the encryption of the traffic from and to clients while delivering the traffic unencrypted to your back-ends, freeing up your back-end resources and improving the response time for the clients.

Application Load Balancer can also serve HTTP2 traffic without needing to support it on your targets. This simple decision can improve your application response time, as HTTP2 uses TCP connections more efficiently.

Load balancers can also be used to make your architecture more flexible by distributing traffic across different back-end types such as containers and serverless. For example, Application Load Balancer can be configured with listener rules that forward traffic to different target groups based on the request parameters such as header, method or pattern.

Your workload latency requirements should also be considered when defining the architecture. As an example, if you have a latency-sensitive application, you may decide to use Network Load Balancer, which offers extremely low latencies. Alternatively, you may decide to bring your workload closer to your customers by leveraging Application Load Balancer in AWS Local Zones or even AWS Outposts.

Another consideration for latency-sensitive workloads is cross-zone load balancing. With cross-zone load balancing, each load balancer node distributes traffic across the registered targets in all allowed Availability Zones. This improves availability, although it can add a single digit millisecond to the roundtrip latency.

Lastly, both ALB and NLB offer monitoring resources such as logs and metrics. Properly setting up monitoring can help with gathering performance insights of your application. For example, you can use ALB access logs to find which requests are taking longer to be answered or which back-end targets are causing performance issues.

Implementation steps

  1. Choose the right load balancer for your workload.

    1. Use Application Load Balancer for HTTP/HTTPS workloads.

    2. Use Network Load Balancer for non-HTTP workloads that run on TCP or UDP.

    3. Use a combination of both (ALB as a target of NLB) if you want to leverage features of both products. For example, you can do this if you want to use the static IPs of NLB together with HTTP header based routing from ALB, or if you want to expose your HTTP workload to an AWS PrivateLink.

    4. For a full comparison of load balancers, see ELB product comparison.

  2. Use SSL/TLS offloading.

    1. Configure HTTPS/TLS listeners with both Application Load Balancer and Network Load Balancer integrated with AWS Certificate Manager.

    2. Note that some workloads may require end-to-end encryption for compliance reasons. In this case, it is a requirement to allow encryption at the targets.

    3. For security best practices, see SEC09-BP02 Enforce encryption in transit.

  3. Select the right routing algorithm.

    1. The routing algorithm can make a difference in how well-used your back-end targets are and therefore how they impact performance. For example, ALB provides two options for routing algorithms:

    2. Least outstanding requests: Use to achieve a better load distribution to your back-end targets for cases when the requests for your application vary in complexity or your targets vary in processing capability.

    3. Round robin: Use when the requests and targets are similar, or if you need to distribute requests equally among targets.

  4. Consider cross-zone or zonal isolation.

    1. Use cross-zone turned off (zonal isolation) for latency improvements and zonal failure domains. It is turned off by default in NLB and in ALB you can turn it off per target group.

    2. Use cross-zone turned on for increased availability and flexibility. By default, cross-zone is turned on for ALB and in NLB you can turn it on per target group.

  5. Turn on HTTP keep-alives for your HTTP workloads.

    1. For HTTP workloads, turn on HTTP keep-alive in the web server settings for your back-end targets. With this feature, the load balancer can reuse backend connections until the keep-alive timeout expires, improving your HTTP request and response time and also reducing resource utilization on your back-end targets. For detail on how to do this for Apache and Nginx, see What are the optimal settings for using Apache or NGINX as a backend server for ELB?

  6. Use Elastic Load Balancing integrations for better orchestration of compute resources.

    1. Use Auto Scaling integrated with your load balancer. One of the key aspects of a performance efficient system has to do with right-sizing your back-end resources. To do this, you can leverage load balancer integrations for back-end target resources. Using the load balancer integration with Auto Scaling groups, targets will be added or removed from the load balancer as required in response to incoming traffic.

    2. Load balancers can also integrate with Amazon ECS and Amazon EKS for containerised workloads.

  7. Monitor your load balancer to find performance bottlenecks.

    1. Turn on access logs for your Application Load Balancer and Network Load Balancer.

    2. The main fields to consider for ALB are request_processing_time, request_processing_time, and response_processing_time.

    3. The main fields to consider for NLB are connection_time and tls_handshake_time.

    4. Be ready to query the logs when you need them. You can use Amazon Athena to query both ALB logs and NLB Logs.

    5. Create alarms for performance related metrics such as TargetResponseTime for ALB.

Resources

Related best practices:

Related documents:

Related videos:

Related examples: