On September 30, 2025, the Azure Basic Load Balancer will be retired. For more information, see the official announcement. If you are currently using Basic Load Balancer, make sure to upgrade to Standard Load Balancer prior to the retirement date.
You can use the guidance to upgrade, please ensure that all of the steps are followed when you test and then implement the change. This is due to the fact that there are multiple differences between the basic and standard load balancer SKU. If you are not prepared, your VMs behind the load balancer may lose outbound/Internet access.
Standard Vs Basic Azure Load Balancer Differences
We can illustrate the differences by first looking at the Azure portal.
On the left is the basic LB. On the right is a standard LB. Note that the standard LB has many more options such as:
- Outbound Rules
- Diagnostic Settings
- Logs
- Resource Health
We will circle back the highlighted Outbound Rules as that has been a gotcha for many.
Secondly we can look in the docs. In the documentation there is a convenient table.
Again note the differences in how these two SKUs operate.
These changes in functionality must be reviewed and planned. The PowerShell upgrade script has an hour long training video to help you understand the process and how to deal with issues.
Outbound Network Access
If you simply recreate the existing basic LB config in a standard LB then you may not have Internet access for VMs. This assumes that you copied over the health checks, inbound NAT rules etc. and that the VMs do not have a directly assigned public IP or a separate NAT gateway.
This was a common scenario as deploying a basic LB, putting the VMs behind it would allow those VMs to have Internet access.
Outbound connectivity, for vnets with a standard SKU load balancer does not exist automatically: the VMs requiring outbound access must either be given an external facing IP address, or be put into a backend pool of the load balancer AND the load balancer must have an outbound rule defined for the required outbound traffic on that backend pool (even if the rule merely accepts the default options).
You should proactively review the options listed here: Use Source Network Address Translation (SNAT) for outbound connections
The options presented below are:
- Assign public IP directly to the VM
- Use frontend IP of load balancer
- Assign NAT gateway to the subnet
Not shown is the Default outbound access. This is also being removed.
On September 30, 2025, default outbound access for new deployments will be retired. For more information, see the official announcement.
You may also want to take a peek at the Load Balancer FAQ.
Outbound Network Access – Standard Load Balancer Limitations
If you do select to use the standard load balancer to provide outbound access to the Internet, you will need to be aware of its limitations.
Else you are going run commands as shown below and think there is something wrong.
This is working as designed. The standard load balancer only supports outbound TCP and UDP. Neither of the protocols used in the above test operate at the OSI Transport layer.
The limitations as of April 2024:
- The maximum number of usable ephemeral ports per frontend IP address is 64,000.
- The range of the configurable outbound idle timeout is 4 to 120 minutes (240 to 7200 seconds).
- Load balancer doesn't support ICMP for outbound NAT, the only supported protocols are TCP and UDP.
- Outbound rules can only be applied to primary IP configuration of a NIC. You can't create an outbound rule for the secondary IP of a VM or NVA. Multiple NICs are supported.
- All virtual machines within an availability set must be added to the backend pool for outbound connectivity.
- All virtual machines within a virtual machine scale set must be added to the backend pool for outbound connectivity.
Make sure you take the time to read through all of the outbound options and add this into the planning for replacing basic load balancers.
Cheers,
Rhoderick
