Outbound Internet Access for Azure VMs – your options

Since Microsoft is retiring default outbound connectivity for Azure Virtual Machines, we should have a look at the other options.

Don’t panic … yet

The retirement is announced for 30 September, 2025. Almost two years from now.

But since we all know how long projects and especially migration projects can drag on, I wouldn’t wait too much longer to start planning.

Furthermore, I recommend not deploying new workloads this way from now on. It was never really a good idea, by the way – no control over the public IP of the machine, risk of using up NAT space quickly, no inbound connections possible, etc.

General approach

It is generally not a good idea to allow VMs direct access to the Internet. Normally, we have a hub and spoke architecture in Azure and traffic from a VM in a spoke is routed through a firewall in the hub. In this case, nothing changes.

But of course, there are test environments, isolated systems, or very small deployments where such access needs to be enabled directly from the VM. So…

What are our options?

Attach a public IP address

You can attach a Basic or Standard Public IP address to the NIC. I wouldn’t recommend adding a Basic Public IP, since they’re also deprecated and will retire at the same date.

You can add either a Public IPv4 or IPv6 to the interface. For IPv6, you’ll have to add an IPv6 range to your VNET and the subnet and add a new IP Configuration to the NIC before attaching this Public IP. If you attach a Public IPv4, you can do this directly to first IP Configuration.

I recommend this approach, if you have only a few VMs within this VNET. If you choose an IPv4 this IP will cost you money. IPv6 addresses are free of charge right now.. You’ll still pay for outgoing bandwith with both options.

Keep in mind: Standard Public IP addresses are closed by default for incoming connections, so you have to attach a Network Security Group (NSG) which allows Internet access to the NIC of the VM or the subnet the VM NIC is deployed to, to get connectivity from the outside. Allowed connection to Internet is one of the default rules of an NSG, so you actually don’t have to change anything else within the NSG (though you should).

Costs: Free – Public IPv6; or Low – Public IPv4 (€3.47*)

Use a Azure Load Balancer

A public Azure Load Balancer (LB) can be configured with Outbound Rules. So if you’re going to add your VMs to a Backend Pool on the LB, the LB will be used for outgoing traffic.

Using only one Public IP can be an upside (costs), but only if you have more than ~4 VMs using the LB.

To be honest, I wouldn’t recommend this approach. The SNAT allocation is mostly static or has other downsides and doesn’t scale well. Only if you also have to provide inbound connectivity, I think this can be a viable option.

Costs: Okay – Standard Load Balancer (€17.36*) + Data Processed by LB (€4.87* for 1TB) + Public IP (€3.47*)

Use a Azure NAT Gateway

A Azure NAT Gateway gives you SNAT port functionality for automatically scaling outbound connectivity and reduce the risk of SNAT port exhaustion. It’s not possible to use it for inbound connectivity (of course), but you can add another Public IP to the VM NIC or use another Load Balancer for this.

I would recommend this, if you have many VMs within your VNET and cannot live with the risk of exhausting your SNAT ports.

Costs: Questionable (my opinion!) – NAT Gateway (€31.25*) + Data Processed by NAT Gateway (€43,84* for 1TB) – Public IP (€3.47*)

Conclusion

I strongly recommend avoiding all these options and building a reasonable Hub-and-Spoke architecture. Direct connection to the Internet is mostly a security nightmare. But if you want to use it for test scenarios or very small deployments, then use the first option (Public IP) if possible. If you need to configure dedicated traffic for multiple VMs or VM scale sets anyway, use the load balancer. Only if SNAT port exhaustion is really a risk in your environment, then use a NAT gateway.

Please remember: This reflects only my personal opinion, which does not have to be that of Microsoft or my employer. Your feedback is always welcome!

* = based on retail prices as of October 2023 in the Azure Region West Europe; Your costs might be different