Today to match the fast-growing pace of the world everybody wants to launch their business as soon as possible to hit the market on time. This requires technology with more flexibility and features that can help your products and services capture the market as quickly as possible. At the same time, it should be easy to maintain and scale as the user base grows. That’s where we prefer cloud services, where a feature-rich cloud platform provides you an all the components to deploy your IT product or service. Amazon Web Services AWS is one of the Cloud services market leaders and it always keeps adding and improving its services. As AWS add new services, they do discontinue a some services or launch an updated version of the same. Few months back AWS decided to discontinue their EC2 classic load balancer from AWS load balancer and through this article you will come to know why.
In March 2006 Amazon launched its cloud services that we all know as AWS. It starts with only one type of instance i.e. m1.small, one region us-west, and one type of flat network i.e. EC classic network. After the launch of the first version service, AWS kept on adding new services. Considering the user demands and evolution of new technologies also required them to deprecate some of their legacy services e.g. AWS server migration service and recently CLB in AWS Elastic Load Balancer on 15 August 2022.
Why Classic Load Balancer is Discontinued?
Before going too deep and exploring different alternatives and better options to replace our Classic Load Balancer, let’s first understand what actually means the discontinuation of CLB here. It is basically Classic Load Balancer with EC2 classic being discontinued not the whole classic load balancer service. In simple terms, while launching the CLB you will not get the option to use EC2 classic instances rather you will get the option to select a VPC.
How to Migrate?
Before we actually start discussing all the migration options know how to migrate your Classic Load Balancer. Let’s first list the steps that need to be followed to be sure that the new system is completely up and running and is ready to serve all our user base and features without any surprising issues because of migration. We can follow the below steps for a safer migration –
- Setup a new load balancer, by following one of the migration options.
- Start redirecting the traffic gradually to the new load balancer.
- Create all the required roles, and policies and make the necessary code updates in your application/deployment scripts e.g. CI/CD tools.
- Once it works fine with 70% of the traffic routed to it then we can delete the old load balancer i.e. CLB.
Now let’s explore different possible migration options
- Using Migration wizard in AWS console.
- Load balancer copy utility from Github (URL??).
- Using manual migration to the application or Network Load Balancer.
- Using manual migration to a Classic Load Balancer with VPC.
After seeing the above four options you might be thinking that there are a number of articles online that describe all the above four options and also explains them in detail. Yes, you are correct and I do not have any problem accepting it. The value that I want to bring here is every option provided above has certain challenges with it and some of the options e.g. option 1 and 2 it not as straightforward as it seems from the fancy word like wizard/utility inside it.
And the main concern is the CLB should be in the VPC, I still see the steps not defined clearly, they already assume a solution before they actually solve the problem, and they do not address the issue of how to migrate from EC2 classic to ALB or NLB directly rather they give you a next-level option where they expect you to migrate to ALB or NLB considering you might have already migrated you EC2 classic to VPC. But what about this first step here i.e EC2 classic to VPC and what is recommended as a way to follow it and address different challenges in this. Going forward to address the main challenge, first I would list down the blockers we need to consider to do it –
- Migrating EC classic to VPC instance.
- What if we have both application and network layer rules in our CLB i.e. HTTP/HTTPS or TCP. The migration wizard to ALB will only consider HTTP/HTTPS once and to NLB it will only consider TCP.
Now let’s Discuss Both of Them in Detail
1. Migrating EC2 Classic to VPC Instance
- Create a new VPC with at least two subnets in it. Now, create subnets in the availability zone you want your new EC2 resource to distribute the load by ELB.
- Create a new security group and copy the rules from your existing security group to the new sg.
- Create AMI of the old EC2 classic resources and launch new resources using these AMIs. Make sure to attach the new instance to the same VPC we created in step 1.
- Assign the security group and subnet created previously to the new instance.
- Create a new classic load balancer by selecting the VPC in step 1. And one subnet from each availability zone containing the instance that you plan to register with the new VPC CLB.
- Register new instances with the new CLB. Make sure to add tags if any from previous Ec2 classic CLB.
- Update your DNS record, if your DNS server supports a weighted feature to route the requests like Route53 then gradually load transfer is recommended e.g. first only transfer 10% of the traffic to the new LB then 50% then 100%.
2. Handle Both HTTP and TCP Listeners/Rules
Once you are done with this you can use approaches like migrate wizard or GitHub copy utility or manually migrate to ALB. Or even NLB to move your existing VPC CLB to ALB or NLB. While doing this we will face another challenge i.e how to route the rules if CLB contains both HTTP and TCP-based rules. None of the next-generation AWS LB supports both.
ALB supports HTTP and NLB supports TCP rules. Considering this fact we need to make changes in our applications to listen over HTTP APIs instead of TCP sockets if we want to migrate to ALB. Or converting APIs to TCP socket if we want to migrate to NLB. And it depends on the type of your application, if it’s more of Rest APIs then ALB is preferred. Another way is to adopt a hybrid approach where registering different subdomains for TCP rules and using NLB to route TCP-based requests. The flexibility to register the same set of instances behind both NLB and ALB gives us the choice to use the same instance. Even though we use a hybrid approach. We can consider the below image for an overview diagram of the above explanation.
A place for big ideas.
Reimagine organizational performance while delivering a delightful experience through optimized operations.
Conclusion
In the above article rather than describing the actual steps of migration I tried to make it even simpler. I rearranged the steps and completed the flow from EC2 classic CLB to VPC CLB. And then further advancing it to the ALB or NLB. Based on the application or deployment you have another more feasible way to address the migration. The main concept I tried to explain here might give you a way forward to take the migration challenge. The article does not actually describe the migration with wizard or Git utility completely. But if you find any good resource covering the migration, please do share the URL in the comment section. If you have any questions, connect with me by writing the question in comments. I will be more than happy to assist you in that.
