Are you deciding whether to stay with AWS Classic Load Balancer (CLB), previously known as Elastic Load Balancer, or migrate to one of the newer types of Elastic Load Balancing (ELB) solutions:
- AWS Classic Load Balancer (CLB), previously known as Elastic Load Balancer
- Application Load Balancer (ALB)
- Network Load Balancer (NLB)
If you’re currently using CLB, could you use some guidance on how to migrate to ALB or NLB? If so, this blog is for you.
As you may know, AWS ELB can help improve the scalability, reliability, and performance efficiency of your AWS environments. It does so by automatically distributing incoming application traffic across servers in multiple Availability Zones.
In this blog, we’ll look at each of the types of AWS ELB to help you decide which of them is best for your workload or organization. And, if you’re already using CLB and decide that ALB or NLB is more appropriate for your needs, we’ll guide you through the steps to perform a migration.
Should you stay with CLB or migrate to ALB or NLB?
Here at nClouds, when we build container infrastructure for our customers, our default choice is to use AWS ALB. We select ALB because it integrates really well with Amazon Elastic Container Service (Amazon ECS), Amazon Elastic Container Service for Kubernetes (Amazon EKS), AWS Fargate, and AWS Lambda. So, it’s a no-brainer choice for building new infrastructure.
Many customers are still running on CLB. Our customers typically want to switch due to key features available only from ALB, like:
- Ability to use AWS Web Application Firewall (AWS WAF)
- AWS Lambda as targets
- IP addresses as targets
- Ability to add multiple TLS/SSL certificates using Server Name Indication (SNI)
The list of features goes on — you can find the complete list here.
If you have already configured ELB in AWS, what you have is most likely CLB. You may decide to stay with CLB if your AWS environment is comprised of clearly defined services that can each be mapped to a specific address.
However, if you have a microservice architecture or a container-based infrastructure, you may want to migrate from CLB to the newer types of Elastic Load Balancing — ALB or NLB. That said, before migrating, it’s essential to understand the differences between and benefits of the new types of ELB.
How does Elastic Load Balancing (ELB) work?
As mentioned above, ELB distributes the traffic between EC2 instances within single or multiple target groups. It scales as traffic to your application changes over time and can scale to most workloads automatically.
In this illustration, you can see the traffic distribution with ELB:
The main advantages of ELB are:
- High availability (distributing traffic between instances when overloading).
- Fault tolerance (continual health check of instances and rerouting of traffic to the working instances).
Comparison
Let’s compare ELB types by some of their features. (You can see the complete comparison in the official AWS Elastic Load Balancing product description.)
| CLB | ALB | NLB | |
|---|---|---|---|
| Protocols | TCP, SSL/TLS, HTTP, HTTPS | HTTP, HTTPS | TCP, TLS |
| Performance (a higher number is slower): the ability to handle more traffic | 2 | 3 | 1 (fastest) |
| Host/Path-based routing | No | Yes | No |
| Sticky Session (for session-based applications) | Yes (redirect to the same machine) | Yes (redirect to the same target) | No |
| Static/Elastic IP | No | No | Yes |
| Load balancing to multiple ports on the same instance | No | Yes | Yes |
| Configurable idle connection timeout | Yes | Yes | No |
Based on the official comparison, here’s an illustration showing the features that the three types of ELBs have in common, and the features that are unique to each ELB type:
As you can see, ALB and NLB support almost all the features of CLB, except for:
- EC2-Classic (for AWS accounts created before December 4, 2013).
- Sticky Session feature (also known as session affinity). This feature enables the load balancer to bind a user’s session to a specific instance so that all requests from the user during the session are sent to the same instance.
That said, you will derive more benefits by migrating from CLB to ALB or NLB, including host/path-based routing and containerized applications (Amazon ECS).
Before we talk about the migration path, it’s worth mentioning that, unlike CLB, ALB doesn’t support Layer 4 protocol, the transport layer that describes the Transmission Control Protocol (TCP) connection between the client and your back-end instance, through the load balancer. To support Layer 4 protocol, you need to use NLB for layer load balancing.
Migration
Here are some migration strategies for migration from ELB to ALB or NLB:
Steps before the migration:
Before the migration, we recommend that you generate the AWS CloudFormation template from your existing ELB by using CloudFormer, a template creation tool that creates a CloudFormation template from existing AWS resources in your account. Currently, this AWS service is a beta. It may help you to roll back from the new ELB, if necessary.
Decide which new load balancer to migrate to:
- If you have an existing CLB in a VPC and you have determined that an ALB or NLB would best meet your needs, you can migrate from CLB.
- If the CLB has an HTTP or HTTPS listener, then you can migrate to ALB.
- If the CLB has a TCP listener, then you can migrate to NLB.
Using the AWS console-based Migration Wizard:
The Migration Wizard helps you create an ALB or an NLB with a configuration that is equivalent to your CLB. With the Migration Wizard, there’s no need for you to do step-by-step configuration. It enables you to:
- Quickly test your application with the new type of load balancer.
- Have a single-screen view of the new configuration.
- Modify the new configuration before creating the new load balancer.
After the migration, you can configure the advanced features offered by the new load balancer. You can access the Migration Wizard from the Migration tab in the console for a CLB.
Steps to migrate your CLB:
You can find the complete guide in the official AWS Elastic Load Balancing documentation.
Beware of the “gotchas”:
- Don’t delete your old ELB until your new ELB is running properly.
- If your applications are session based for ALB, make sure to set the session stickiness at the target group level.
Rollback strategy:
If for some reason you want to roll back to the previous ELB, we recommend that you wait for several days to make sure everything is working properly before deleting your previous ELB. Why?
- If you have used the unique features of the new ELB, it is going to be complex to roll back.
- If you generate the CloudFormation template before the migration, it will be easy to create a new one by using the CloudFormation template.
In conclusion
We recommend that you consider the following factors when deciding on the best type of AWS Elastic Load Balancing for your business.
- Have an AWS environment comprised of clearly defined services that can each be mapped to a specific address? CLB will work for you.
- Have a microservice architecture or a container-based infrastructure? Select ALB or NLB.
- Need host/path-based routing? Choose ALB.
- Want load balancer-generated cookies? Select ALB.
- Need support for both static and elastic IP addresses? Go with NLB.
- Want to support configurable idle connection timeout? Either CLB or ALB can do this.
- Are you looking for very high throughput and not concerned about Layer 7 routing functionalities? Choose NLB.
Need help with AWS Elastic Load Balancing? The nClouds team is here to help with that and all your AWS infrastructure requirements.
