Retiring Default Internet Access for VMs
There’s a big change coming to Azure VM networking in September 2025. Yes, that’s a way off, but it will pay to plan for this now.
VM networking in Azure has differed from AWS for a long time, in that Azure VMs are automatically able to make outbound connections to the internet, with no configuration required from the user. AWS on the other hand, takes the opposite approach. By default, AWS VMs have no internet access, and you have to explicitly configure it if you need it, through something like a NAT Gateway.
This is all set to change. Microsoft have announced that on the 30th of September 2025, they will be retiring default outbound connectivity for VMs. This means that any VMs deployed after this date will not have connectivity to the internet and if you need this, you will need to explicitly configure it. It is recommended that before this date you configure your resources to have connectivity if required. So let’s take a look at how that can be done.
Exceptions
There are some exceptions to this change that you should be aware of:
- Existing VM workloads that were deployed before the retirement will not change, and the default outbound access will continue to work. However, if you find you need to delete and recreate a VM then it will not have connectivity
- Cloud Services (extended support) are not affected by this change
Connection Methods
Public IP Address
This may be the simplest, and cheapest, approach if you only have a small amount of VMs. If you connect a public IP to a VM then the VM will use this IP for outbound routing and as its external IP. You do not need to allow any traffic inbound on this IP, so you could block everything inbound with an NSG and purely use it for outbound traffic.
While using a public IP on a VM is a simple approach, you need to bear in mind the security of this. If you do not sufficiently block connects with an NSG then that VM will be exposed directly to the internet.
Standard Load Balancer with Outbound Rules
If you want to support multiple VMs or don’t want a public IP on your VMs then you can use a Standard Load Balancer. Attach a Public IP to the load balancer and then create outbound rules for the VMs you wish to route traffic through this Load Balancer. You do not need to configure any inbound rules and this removes the security concern with VM-attached IPs as a load balancer will only forward traffic for rules it has configured.
vNet NAT Gateway
If you want to configure outbound connectivity for all VMs on a vNet then you can use a NAT Gateway. The NAT Gateway is configured with a public IP and then associated with vNets and subnets. Any VMs configured to use this will send outbound traffic through the gateway and use its Public IP as their outbound IP.
A NAT Gateway is purely concerned with outbound requests (and responses to these requests) so there is no danger of allowing inbound traffic. NAT gateway is relatively inexpensive at around $32 per month plus $0.045 per GB of data processed.
Azure Firewall
Azure Firewall provides outbound connectivity and filtering functionality and so can be used to resolve this issue. However, Azure Firewall is an expensive solution so I would only really look at this if you need the security functionality it requires. If you are working in a production environment then filtering outbound traffic and blocking malicious connections is something you should be doing, so using Azure Firewall may be a good solution, but it comes at a cost.
Traffic can be configured to route through the firewall for the whole vNet or specific subnets using a user-defined route (UDR).
