B
brianlehr
This article was co-authored by @aimeelittleton and @brianlehr
While there are multiple methods for obtaining explicit outbound connectivity to the internet from your virtual machines on Azure, there is also one method for implicit outbound connectivity – default outbound access. When virtual machines (VMs) are created in a virtual network without any explicit outbound connectivity, they are assigned a default outbound public IP address. These IP addresses may seem convenient, but they have a number of issues and therefore are only used as a “last resort”:
Because of these factors, we recently announced the retirement of this type of implicit connectivity, which will be removed for all VMs in subnets created after September 2025.
Private subnet
At Ignite, a new feature—private subnet—was released in preview. This feature will let you prevent this type of insecure implicit connectivity for all subnets with the “default outbound access” parameter set to false. Any virtual machines created on this subnet will be prevented from connecting to the Internet without an explicit outbound method specified. To enable this feature, simply ensure the option is selected when a new subnet is created as shown below.
View of Azure portal with Private subnet selection
Note that currently:
The good news is that there are much better, more scalable, and secure methods for having your VMs access the Internet. The three recommended options—in order of preference—are a NAT gateway, using outbound rules with a public load balancer, or placing a public IP directly on the VM network interface card (NIC).
Diagram of multiple explicit outbound methods
Azure NAT Gateway
NAT Gateway is the best option for connecting outbound to the internet as it is specifically designed to provide highly secure and scalable outbound connectivity. NAT Gateway enables all instances within private subnets of Azure virtual networks to remain fully private and source network address translate (SNAT) to a static public IP address. No connections sourced directly from the internet are permitted through a NAT gateway. NAT Gateway also provides on-demand SNAT port allocation to all virtual machines in its associated subnets. Since ports are not in fixed amounts to each VM, this means you don’t need to worry about knowing the exact traffic patterns of each VM. To learn more, take a look at our documentation on SNATing with NAT Gateway or our blog that explores a specific outbound connectivity failure scenario where NAT Gateway came to the rescue.
Azure Load Balancer with outbound rules
Another method for explicit outbound connectivity is using public Azure load balancers with outbound rules. To provide outbound connectivity with Azure Load Balancer, you assign a dedicated public IP address or addresses as the frontend IP of the outbound rule. Private instances in the backend pool of the Load balancer then use the frontend IP of the outbound rule to connect outbound in a secure manner, similar to NAT Gateway. However, unlike NAT Gateway, SNAT ports are not allocated dynamically with outbound rules. Rather, using a load balancer requires manual allocation of SNAT ports in fixed amounts to each instance of your backend pool prior to deployment. This manual SNAT port allocation gives you full declarative control over outbound connectivity since you decide the exact amount of ports each VM is allowed. However, this manual allocation creates more overhead management in ensuring that you have assigned the correct amount of SNAT ports needed by your backend instances for connecting outbound. While you can scale your Load balancer by adding more frontend IPs to your outbound rule, this scaling requires you to then re-allocate assigned SNAT ports per backend instance to ensure that you are utilizing the full inventory of SNAT ports available.
Public IP address assignment to virtual machine NICs
Another option for providing explicit outbound connectivity from an Azure virtual network is the assignment of a public IP address directly to the NIC of a virtual machine. Customers that want to have control over which public IP address their VMs use for connecting to specific destination endpoints may benefit from assigning public IPs directly to the VM NIC. However, customers with more complex and dynamic workloads that need a many to one SNATing relationship that scales with their traffic volume should look to NAT Gateway or Load Balancer.
To learn more about each of these explicit outbound connectivity methods, see our public documentation on using source network address translation for outbound connections.
What outbound method am I currently using?
As mentioned earlier, default outbound access is enabled only when no other explicit outbound connectivity method exists. Note that there is an order of priority among the explicit methods, shown in the flowchart below. In other words, if your VM has multiple forms of outbound connectivity defined, then the higher order one will be used (e.g. NAT Gateway takes precedence above a public IP address attached to the VM NIC).
To check the form of outbound your deployments are using, you can refer to the flowchart below which lists them in the order of precedence.
Flowchart showing priority order for diffrent outbound methods
To read more about default outbound access and private subnets, please refer to Default outbound access in Azure - Azure Virtual Network | Microsoft Learn.
To learn more about how to deploy a NAT Gateway, please use Quickstart: Create a NAT Gateway - Azure portal | Microsoft Learn.
Continue reading...
While there are multiple methods for obtaining explicit outbound connectivity to the internet from your virtual machines on Azure, there is also one method for implicit outbound connectivity – default outbound access. When virtual machines (VMs) are created in a virtual network without any explicit outbound connectivity, they are assigned a default outbound public IP address. These IP addresses may seem convenient, but they have a number of issues and therefore are only used as a “last resort”:
- These implicit IPs are subject to change which can result in issues later on if any dependency is taken on them.
- Their dynamic nature also makes them challenging to use for logs or filtering with network security groups (NSGs).
- Because these IPs are not associated with your subscription, they are very difficult to troubleshoot.
- This type of open egress does not adhere to Microsoft’s “secure-by-default” model which ensures customers have a strong security policy without having to take additional steps.
Because of these factors, we recently announced the retirement of this type of implicit connectivity, which will be removed for all VMs in subnets created after September 2025.
Private subnet
At Ignite, a new feature—private subnet—was released in preview. This feature will let you prevent this type of insecure implicit connectivity for all subnets with the “default outbound access” parameter set to false. Any virtual machines created on this subnet will be prevented from connecting to the Internet without an explicit outbound method specified. To enable this feature, simply ensure the option is selected when a new subnet is created as shown below.
View of Azure portal with Private subnet selectionNote that currently:
- A subnet must be created as private; this parameter cannot be changed following creation.
- Certain services will not function on a virtual machine in a private subnet without an explicit method of egress (examples are Windows Activation and Windows Updates).
- Both CLI and ARM templates can also be used; PowerShell is in development.
The good news is that there are much better, more scalable, and secure methods for having your VMs access the Internet. The three recommended options—in order of preference—are a NAT gateway, using outbound rules with a public load balancer, or placing a public IP directly on the VM network interface card (NIC).
Diagram of multiple explicit outbound methodsAzure NAT Gateway
NAT Gateway is the best option for connecting outbound to the internet as it is specifically designed to provide highly secure and scalable outbound connectivity. NAT Gateway enables all instances within private subnets of Azure virtual networks to remain fully private and source network address translate (SNAT) to a static public IP address. No connections sourced directly from the internet are permitted through a NAT gateway. NAT Gateway also provides on-demand SNAT port allocation to all virtual machines in its associated subnets. Since ports are not in fixed amounts to each VM, this means you don’t need to worry about knowing the exact traffic patterns of each VM. To learn more, take a look at our documentation on SNATing with NAT Gateway or our blog that explores a specific outbound connectivity failure scenario where NAT Gateway came to the rescue.
Azure Load Balancer with outbound rules
Another method for explicit outbound connectivity is using public Azure load balancers with outbound rules. To provide outbound connectivity with Azure Load Balancer, you assign a dedicated public IP address or addresses as the frontend IP of the outbound rule. Private instances in the backend pool of the Load balancer then use the frontend IP of the outbound rule to connect outbound in a secure manner, similar to NAT Gateway. However, unlike NAT Gateway, SNAT ports are not allocated dynamically with outbound rules. Rather, using a load balancer requires manual allocation of SNAT ports in fixed amounts to each instance of your backend pool prior to deployment. This manual SNAT port allocation gives you full declarative control over outbound connectivity since you decide the exact amount of ports each VM is allowed. However, this manual allocation creates more overhead management in ensuring that you have assigned the correct amount of SNAT ports needed by your backend instances for connecting outbound. While you can scale your Load balancer by adding more frontend IPs to your outbound rule, this scaling requires you to then re-allocate assigned SNAT ports per backend instance to ensure that you are utilizing the full inventory of SNAT ports available.
Public IP address assignment to virtual machine NICs
Another option for providing explicit outbound connectivity from an Azure virtual network is the assignment of a public IP address directly to the NIC of a virtual machine. Customers that want to have control over which public IP address their VMs use for connecting to specific destination endpoints may benefit from assigning public IPs directly to the VM NIC. However, customers with more complex and dynamic workloads that need a many to one SNATing relationship that scales with their traffic volume should look to NAT Gateway or Load Balancer.
To learn more about each of these explicit outbound connectivity methods, see our public documentation on using source network address translation for outbound connections.
What outbound method am I currently using?
As mentioned earlier, default outbound access is enabled only when no other explicit outbound connectivity method exists. Note that there is an order of priority among the explicit methods, shown in the flowchart below. In other words, if your VM has multiple forms of outbound connectivity defined, then the higher order one will be used (e.g. NAT Gateway takes precedence above a public IP address attached to the VM NIC).
To check the form of outbound your deployments are using, you can refer to the flowchart below which lists them in the order of precedence.
Flowchart showing priority order for diffrent outbound methodsTo read more about default outbound access and private subnets, please refer to Default outbound access in Azure - Azure Virtual Network | Microsoft Learn.
To learn more about how to deploy a NAT Gateway, please use Quickstart: Create a NAT Gateway - Azure portal | Microsoft Learn.
Continue reading...