Azure VM Internet Access is Changing: What You Need to Know  

Microsoft Azure is making a significant change that will affect how virtual machines connect to the internet. 

From the 30th September 2025, default outbound access connectivity for virtual machines will be retired. If you’re currently deploying VMs in virtual networks without explicitly defined outbound methods, this change will directly impact your infrastructure. 

Our Azure consultant Chris has made a video walkthrough of these changes and what you can do to get ready for them. Check it out below for more detailed explanations for each approach. Otherwise, read on to understand what’s changing and how to prepare. 

Currently, when you create a VM in Azure and put it in a virtual network without any explicit outbound routing configured, Azure automatically assigns it a default public IP address. This implicit connectivity has been a convenient fallback, allowing VMs to reach the internet without additional configuration. 

But after 30 September 2025, you’ll no longer be able to provision new virtual machines without giving them an explicit outbound method. 

The key points to remember: 

• Existing VMs that currently use default outbound access will continue to work after the retirement date 

• New VMs created after this date must have an explicitly configured outbound connectivity method 

• You don’t need to take any action immediately, but we strongly recommend transitioning away from default outbound access now 

Whilst this might initially seem like an inconvenience, retiring default outbound access does fix some fairly significant security and operational issues: 

• Unpredictable IP addresses: The public IP assigned for default outbound access can change without notice. This potentially breaks connections with external services that use IP whitelisting or need consistent source addresses. 

• Limited visibility: It’s difficult to trace outbound activity back to specific virtual machines, making security monitoring and auditing more challenging. 

• Lack of control: You have no control over how your virtual machines connect to the internet. Whilst Network Security Groups do give some protection, managing internet access at scale becomes unwieldy without proper outbound connectivity controls. 

Simply put, default outbound access just isn’t secure enough for modern cloud deployments. 

Azure has four main approaches to configure explicit outbound connectivity for your VMs, each with different levels of complexity, cost, and security capabilities. 

Option 1: Public IP assignment 

The most straightforward approach is to assign a public IP directly to your virtual machine. You can do this during VM creation or afterwards by modifying the network interface configuration. 

• When to use it: Small deployments where individual VM internet access is acceptable and network complexity is minimal. 

• Pros: Simple to implement, consistent public IP address, can be configured during or after VM deployment. 

• Cons: Each VM has direct internet exposure, limited security controls, not cost-effective at scale, challenging to manage across multiple VMs. 

• Key consideration: Whilst this solves the changing IP problem, it doesn’t address the fundamental security concerns of having VMs directly exposed to the internet. 

Option 2: Standard Load Balancer with outbound rules 

This approach uses a Standard Load Balancer with outbound rules to provide source NAT for your VMs. Your virtual machines sit in a backend pool behind the load balancer, which presents a single public IP for all outbound traffic. 

• When to use it: When you already have a Standard Load Balancer in place and don’t have excessive traffic requirements. 

• Pros: Cost-effective if you’re already using load balancing, flexible control over outbound connections, can assign multiple public IPs for different VM groups. 

• Cons: Still relies on Network Security Groups for destination control. It adds complexity if you don’t need load balancing. Outbound rules won’t apply if VMs have instance-level public IPs. 

• Key considerations: As soon as you place a VM in a load balancer’s backend pool, default outbound access is automatically disabled. Internal load balancers don’t provide outbound connectivity. 

Option 3: NAT Gateway (Microsoft’s recommended) 

NAT Gateway is a fully managed, highly resilient network address translation service that allows all instances in a private subnet to connect outbound to the internet. 

• When to use it: For most scenarios where you need reliable, scalable outbound connectivity without the complexity of a full security appliance. 

• Pros: Simple to deploy and configure, excellent performance and scalability, cost-effective compared to firewall solutions, automatically overrides default routes, and can serve multiple subnets from a hub VNet. 

• Cons: Limited to basic NAT functionality, not supported in secured Virtual WAN environments, and fewer security controls than firewall-based solutions. 

• Key considerations: Microsoft explicitly recommends NAT Gateway as the preferred method for outbound internet access, mostly due to its simplicity and cost-effectiveness. Once deployed, it takes precedence over user-defined routes, making configuration straightforward. 

Option 4: Azure Firewall or Network Virtual Appliances 

Choosing the best solution for you depends on several factors: 

• For small, simple deployments with minimal security requirements, public IP assignment might do the job, though we’d generally recommend NAT Gateway for better security and management. 

• For existing load balancer users who don’t need advanced security features, outbound rules with Standard Load Balancer can be cost-effective. 

• For most organisations, NAT Gateway offers the best balance of simplicity, security, and cost. It’s Microsoft’s recommended approach for good reason. 

• For enterprise environments with strict security requirements, zero-trust architectures, or Virtual WAN deployments, Azure Firewall or Network Virtual Appliances provide the control and visibility they need. 

There are five steps you’ll want to get stuck into before the changes take place: 

• Assess your current environment: Identify which VMs currently rely on default outbound access. Look for VMs in virtual networks without explicit outbound routing or public IP assignments. 

• Plan your migration strategy: Choose the appropriate outbound connectivity method based on your security requirements, budget, and network complexity. 

• Test your chosen solution: Deploy your selected approach in a test environment first. Verify that applications continue to function correctly and that outbound connectivity meets your requirements. 

• Update your deployment templates: Modify your Infrastructure as Code templates, ARM templates, or Terraform configurations to include explicit outbound connectivity methods. 

• Monitor and document: Make sure your monitoring and documentation reflect the new outbound connectivity approach. 

The retirement of default outbound access is generally a positive step towards more secure and manageable Azure deployments. Although it does need some planning, the explicit outbound connectivity options available give better security, visibility, and control than the current default approach. 

For most organisations, we recommend starting with NAT Gateway due to its simplicity and Microsoft’s endorsement. That said, the right choice depends on your exact needs and existing infrastructure, as well as the level of security you’re looking for. 

Don’t wait until September to make these changes! Starting your migration now gives you time to test thoroughly and make sure your deployments are secure and compliant. 

Need help choosing the right approach? We’re happy to help you navigate these changes and keep your Azure infrastructure secure. Get in touch today to find out more.