How do I migrate from Classic Load Balancer to Application Load Balancer or Network Load Balancer?

Resolution

Migrating your Classic Load Balancer to an Application Load Balancer or Network Load Balancer

Use the migration wizard to create and configure an Application Load Balancer or Network Load Balancer. If your Classic Load Balancer has a TCP listener, then the wizard creates a Network Load Balancer. If the Classic Load Balancer has an HTTP(S) listener, then the wizard creates an Application Load Balancer. After the load balancer is created, test your newly created load balancer. If your newly created load balancer works without any issues, then redirect the traffic from your Classic Load Balancer to the newly created load balancer.

Note: The wizard creates a new load balancer. The wizard doesn't convert the existing Classic Load Balancer to an Application Load Balancer or Network Load Balancer. You must manually redirect the traffic to the newly created load balancer.

Then, update any policies, scripts, and code. After you redirect all the traffic to the new load balancer and all existing requests on the old load balancer are completed, delete the old load balancer.

Migration considerations

• If your load balancer has only one subnet, then make sure to specify a second subnet when you create the Application Load Balancer. An Application Load Balancer requires a minimum of two subnets.
• If you're uncertain about which load balancer to migrate to, consider using a Network Load Balancer. If your Classic Load Balancer uses an HTTP or HTTPS listener, then migrate to an Application Load Balancer. If your Classic Load Balancer uses TCP listeners, then migrate to a Network Load Balancer. For more information about the different load balancer features, see Elastic Load Balancing features.
• A Classic Load Balancer allows you to turn off cross-zone load balancing. By default, an Application Load Balancer has cross-zone load balancing turned on, and that load balancing can't be turned off. With Network Load Balancer, you can turn off cross-zone load balancing.
• An Application Load Balancer can support request redirection on the load balancer itself. If a Classic Load Balancer's backend connections are configured for HTTP redirection, redirection can be turned off or removed during a migration to a new load balancer.
• A Network Load Balancer doesn't support security groups at the load balancer level. You can use the security groups associated with the targets to restrict traffic. At the Network Load Balancer level, you can use the subnet's network access control lists (ACLs) to restrict traffic.
• A Network Load Balancer is able to preserve the client IP address. If you use security groups to restrict traffic on the targets, be aware that the source IP of the packets includes the client IP address.

Downtime during a load balancer migration

If the new load balancer setup has errors, then downtime during migration can occur. To minimize or reduce any downtime, consider the following approaches:

• Before shifting any production traffic, run tests against the new load balancer. Make sure that the new load balancer can handle traffic requests.
• Use Amazon Route 53's weighted routing policy to gradually route traffic to the new load balancer. If you see issues with the new load balancer, then assign the traffic weight a value of "0".
• If Route 53 isn't in use as the DNS provider, then keep the old load balancer running. Reduce the time to live (TTL) value of the existing record to "0". Then, wait for the previous TTL value to reset and update the record to point to the new load balancer DNS name. If any issues appear with the new load balancer, update the DNS record to point back to the DNS name of the Classic Load Balancer. The TTL value of "0" prevents the record from being cached. After the issue is resolved, return the TTL value to the original value.
• If the new load balancer is performing without any issues, delete the old load balancer.

Note: The new generation of load balancers don't have support for HTTP/HTTPS and TCP listeners at the same time. If you are using a Classic Load Balancer with HTTP/HTTPS and TCP listeners at the same time, it is best practice to use a Network Load Balancer with all TCP/TLS listeners. With this change, you lose HTTP/ HTTPS level logging, as there is no application level routing in NLB to provide that. An alternative is to continue using a Classic Load Balancer.