Networking & Content Delivery
Load Balancer Migration to AWS: Recommended Strategies and Best Practices
In today’s world, organizations are increasingly looking to migrate their on-premises infrastructure to the cloud to take advantage of scalability, cost-effectiveness, and agility offered by cloud. One critical component of many enterprise architectures is the load balancer, which distributes incoming traffic across multiple servers. If you’re considering migrating your on-premise hardware load balancers to AWS, it’s essential to carefully evaluate your current configuration and requirements to determine the most suitable AWS load balancing solution. This blog guides you through the pre-planning phase, discussing how to assess your existing load balancer setup, assess the suitability of Elastic Load Balancers (ELB) for your needs, and explore the various types of ELB and other AWS services that can be integrated to support your specific requirements.
Pre-Migration Planning: Analyzing Your Existing Load Balancer Configuration and Architecture
Load balancers often serve as an entry point to applications, acting as a crucial component that handles more than just simple request routing. Before migrating on-premise load balancers to the cloud, it’s essential to thoroughly evaluate the functions and capabilities your current load balancer provides. Beyond basic load balancing and request distribution to backend servers, your existing load balancer might be performing additional tasks such as attack prevention, header modification, or content-based routing.
As part of the pre-migration planning process, create a comprehensive inventory of your current load balancer setup. The following checklist covers some essential aspects you should consider, but the specific items may vary depending on the type and configuration of your on-premises load balancer:
- Load balancer type, make, model, capacity, and redundancy requirements (active-passive or active-active)
- Internet-facing (public) or internal (private) load balancer
- IP addressing requirements, including support for IPv4, IPv6, or dual-stack (IPv4 and IPv6)
- Traffic patterns, peak loads, traffic types (HTTP/HTTPS, TCP, UDP), and session persistence requirements
- Backend configuration, including the number of backends, health checks, and traffic distribution algorithms (round-robin, least connection, IP hash)
- Security requirements, such as SSL/TLS termination, firewall rules, and DDoS protection
- Additional features like content-based routing, logging, monitoring, and alerting
- Compliance with specific standards such as FIPS
A clear understanding of the specific functionality required for your load balancer in the cloud environment helps you determine which ELB product suits your needs or if you need to explore building a custom load balancing solution. For example, the ‘Migrating from F5 BIG-IP to F5 BIG-IP VE on the AWS Cloud’ AWS Prescriptive Guidance guides you on migrating F5 BIG-IP to F5 BIG-IP VE running on EC2 instances.
AWS offers various load balancing products tailored for specific use cases, with distinct features and capabilities.
Application Load Balancer (ALB) is well-suited for HTTP/HTTPS workloads. It enables content-based routing for intelligent request handling, integrates with AWS Web Application Firewall (WAF) for security, supports diverse targets like EC2, Lambda, and containers, and allows authentication offloading via Amazon Cognito. These features make the ALB ideal for secure, low-latency applications requiring advanced request handling, flexible integration, and sophisticated traffic distribution.
The Network Load Balancer (NLB) is suitable for high-performance TCP/UDP workloads, operating at layer 4. It excels in scenarios demanding low latency, high throughput, and a vast number of concurrent connections, such as online gaming. NLB supports static IP addresses, making it well-suited for workloads that require IP whitelisting or databases that require seamless scalability without IP changes. Its ability to handle long-lived connections makes it an ideal choice for latency-sensitive applications with stringent performance requirements. You have the option to combine NLB with ALB to leverage its strengths while benefiting from advanced layer 7 features. Both ALB and NLB support FIPS 140-3 validated Transport Layer Security (TLS) termination by using TLS policies which helps you meet your compliance requirements.
The Gateway Load Balancer (GWLB) serves as a transparent, layer 3 gateway for inspection and security purposes. It excels in scenarios that require deep packet inspection, network virtualization, or integrating third-party virtual appliances. By leveraging the GENEVE protocol, the Gateway Load Balancer encapsulates and forwards traffic to target appliances without modifying the original packet, enabling seamless inspection without disrupting end-to-end connectivity. This makes it ideal for workloads that demand granular visibility, traffic monitoring, or advanced security controls like firewalls or intrusion detection systems.
To assist you in making an informed decision for an ELB type, AWS provides a comparison of the different load balancer types and their supported features in the Elastic Load Balancing features documentation.
Note that for certain advanced features or capabilities, the load balancer alone may not suffice, and you may need to integrate it with other AWS services. The architecture section of this blog will cover specific use cases that might require integrating ELB with additional AWS services to achieve the desired functionality.
Moreover, as part of the pre-migration planning process, it’s crucial to evaluate your current load balancer’s features and determine which ones are truly necessary in the cloud environment. Often, features are enabled simply because they are available, but they might not be actively utilized or required. Simplifying the load balancer configuration by removing unnecessary features can help streamline management and reduce complexity in the cloud.
Common Load Balancer Architecture Patterns
-
Header-Based Routing for Web Application Hostin
Figure1: Using Application Load Balancer to do Host based routing for web applications
Key Architecture Points:
- AWS Global Accelerator is used as the entry point, providing a static IP address to improve availability and performance by routing traffic to the nearest AWS edge location.
- AWS ALB serves as the main load balancer, handling HTTP/HTTPS traffic and performing advanced routing based on conditions like host headers, HTTP headers/methods, path patterns, and query strings. ALB can take actions like authentication, fixed responses, forwarding, redirection based on the defined conditions. ALB integrates with Cognito for authentication, redirecting unauthenticated requests to Cognito, and verifying Cognito-issued tokens to allow access.
- The ALB routes traffic to different target groups containing Auto Scaling groups of EC2 instances, potentially for different application paths (/path1, /path2, /path3). It support different types of targets instances, IPs, and Lambda functions
- ALB integrates with AWS WAF for web application security controls including allow-list, deny-list, and protection against common exploits
- AWS Certificate Manager provisions and manages SSL/TLS certificates, enabling TLS termination for HTTPS traffic on the Application Load Balancer.
-
Centralized Inbound Traffic via Central ALB and PrivateLink with NLB
Figure 2: Using a central Application Load Balancer and AWS PrivateLink with Network Load Balancer to securely publish Internet Applications
Key Architecture Points:
- Centralized internet access through a single VPC acting as a DMZ
- Internet-facing ALB as the front-end ingress point, routing traffic to applications hosted via internal NLB, without direct internet access, connected to the central VPC via PrivateLink
- Enables secure publishing of internet applications at scale across multiple VPCs without exposing them directly to the internet
- Refer to the blog on “How to securely publish Internet applications at scale using Application Load Balancer and AWS PrivateLink”for more details
Traffic migration strategy from on-premises load balancer to AWS load balancer
Before migrating your production traffic to AWS, it’s crucial to thoroughly test the AWS Load Balancer setup to ensure a smooth transition. The testing process should involve confirming that the response from the AWS Load Balancer is acceptable and that the end-user experience is not significantly affected. If there are noticeable changes, consider employing A/B testing to direct a small portion of users to the cloud setup, gather feedback, and make any necessary adjustments before proceeding with the full migration.
Additionally, it’s essential to conduct load testing to simulate customer traffic volumes and ensure that the new setup is configured correctly to handle the expected load without compromising performance or availability. There are various third-party tools available that can assist you with load testing, allowing you to simulate real-world scenarios and identify potential bottlenecks or issues before the migration. Regularly gathering user feedback and monitoring performance metrics during this phase will allow you to make necessary adjustments in real-time.
Once you have verified that the application’s performance on the AWS cloud is acceptable and meets your requirements, you can begin gradually shifting traffic from the on-premises setup to the new AWS environment. This gradual migration can be achieved in two ways:
- Using your current load balancer: If your existing on-premises load balancer supports traffic distribution across multiple environments, you can configure it to gradually increase the proportion of traffic directed to the AWS Load Balancer while reducing the traffic to the on-premises setup.
- Using Route53 weighted DNS routing: With Amazon Route53, you can create a DNS record with weighted endpoint entries for both the on-premises load balancer and the AWS Load Balancer. Initially, assign a higher weight to the on-premises endpoint to route most traffic to the existing infrastructure. Then, gradually decrease the weight for the on-premises endpoint and increase the weight for the AWS Load Balancer endpoint, effectively shifting more traffic to the cloud environment.
By following this approach, you can migrate traffic to the AWS Load Balancer in a controlled and gradual manner, minimizing the risk of downtime or performance issues. Continuously monitor the application’s performance and end-user experience during the migration process, and be prepared to adjust the traffic distribution or roll back if necessary. Implement automated alerts to proactively catch any potential problems.
Conclusion
Thorough planning and assessment of your existing load balancing setup are crucial for a seamless migration to AWS. By identifying your specific requirements and selecting the right AWS load balancing solution, you can optimize the migration process. Extensive testing, including A/B testing and load testing, is essential before initiating the migration. Follow the optimized strategies and best practices listed in this blog, to unlock the scalability, cost-effectiveness, and agility benefits offered by the AWS cloud for your load balancing infrastructure.
If you’re ready to start your load balancer migration journey to AWS, explore the AWS Load Balancer documentation. Additionally, you can engage with an AWS Partner or AWS Professional Services to assist you in planning, designing, and executing a successful migration tailored to your specific needs.
About the authors