Upgrading from basic Load Balancer - Guidance

In this article, we discuss guidance for upgrading your Basic Load Balancer instances to Standard Load Balancer. Standard Load Balancer is recommended for all production instances and provides many key differences to your infrastructure.

Steps to complete the upgrade

We recommend the following approach for upgrading to Standard Load Balancer:

1. Learn about some of the key differences between Basic Load Balancer and Standard Load Balancer.
2. Identify the Basic Load Balancer to upgrade.
3. Create a migration plan for planned downtime.
4. Perform migration with automated PowerShell scripts for your scenario or create a new Standard Load Balancer with the Basic Load Balancer configurations.
5. Verify your application and workloads are receiving traffic through the Standard Load Balancer. Then delete your Basic Load Balancer resource.

Basic Load Balancer SKU vs. standard Load Balancer SKU

This section lists out some key differences between these two Load Balancer SKUs.

For information on limits, see Load Balancer limits.

Upgrade using automated scripts (recommended)

Use these PowerShell scripts to help with upgrading from Basic to Standard SKU:

• Upgrading a basic to standard public load balancer with PowerShell

Upgrade manually

When manually migrating from a Basic to Standard SKU Load Balancer, there are a couple key considerations to keep in mind:

• It is not possible to mix Basic and Standard SKU IPs or Load Balancers. All Public IPs associated with a Load Balancer and its backend pool members must match.
• Public IP allocation method must be set to 'static' when a Public IP is disassociated from a Load Balancer or Virtual Machine, or the allocated IP will be lost.
• Standard SKU public IP addresses are secure by default, requiring that a Network Security Group explicitly allow traffic to any public IPs
• Standard SKU Load Balancers block outbound access by default. To enable outbound access, a public load balancer needs an outbound rule for backend members. For private load balancers, either configure a NAT Gateway on the backend pool members' subnet or add instance-level public IP addresses to each backend member.

Suggested order of operations for manually upgrading a Basic Load Balancer in common virtual machine and virtual machine scale set configurations using the Portal:

1. Change all Public IPs associated with the Basic Load Balancer and backend Virtual Machines to 'static' allocation
2. For private Load Balancers, record the private IP addresses allocated to the frontend IP configurations
3. Record the backend pool membership of the Basic Load Balancer
4. Record the load balancing rules, NAT rules and health probe configuration of the Basic Load Balancer
5. Create a new Standard SKU Load Balancer, matching the public or private configuration of the Basic Load Balancer. Name the frontend IP configuration something temporary. For public load balancers, use a new Public IP address for the frontend configuration. For guidance, see Create a Public Load Balancer in the Portal or Create an Internal Load Balancer in the Portal
6. Duplicate the Basic SKU Load Balancer configuration for the following:
   1. Backend pool names
   2. Backend pool membership (virtual machines and virtual machine scale sets)
   3. Health probes
   4. Load balancing rules - use the temporary frontend configuration
   5. NAT rules - use the temporary frontend configuration
7. For public load balancers, if you do not have one already, create a new Network Security Group with allow rules for the traffic coming through the Load Balancer rules
8. For Virtual Machine Scale Set backends, remove the Load Balancer association in the Networking settings and update the instances
9. Delete the Basic Load Balancer

   Note

   For Virtual Machine Scale Set backends, you will need to remove the load balancer association in the Networking settings. Once removed, you will also need to update the instances

10. Upgrade all Public IPs previously associated with the Basic Load Balancer and backend Virtual Machines to Standard SKU. For Virtual Machine Scale Sets, remove any instance-level public IP configuration, update the instances, then add a new one with Standard SKU and update the instances again.
11. Recreate the frontend configurations from the Basic Load Balancer on the newly created Standard Load Balancer, using the same public or private IP addresses as on the Basic Load Balancer
12. Update the load balancing and NAT rules to use the appropriate frontend configurations
13. For public Load Balancers, create one or more outbound rules to enable internet access for backend pools
14. Remove the temporary frontend configuration
15. Test that inbound and outbound traffic flow through the new Standard Load Balancer as expected

FAQ

Will the Basic Load Balancer retirement impact Cloud Services Extended Support (CSES) deployments?

No, this retirement will not impact your existing or new deployments on CSES. This means that you can still create and use Basic Load Balancers for CSES deployments. However, we advise using Standard SKU on ARM native resources (those that do not depend on CSES) when possible, because Standard has more advantages than Basic.

Next Steps

For guidance on upgrading basic Public IP addresses to Standard SKUs, see: