In Azure, when you create a VM, it must be connected to a subnet from a VNET. The VM automatically can connect to the Internet. No configuration is needed in the VM, the subnet, or the VNET. It is the implicit outbound connectivity. Azure manages the public IP and the NAT configuration. It is convenient, but you don’t manage the outbound public IP, it can change without notice, and it can be very complex to manage security rules and you have no control over how the VM connects to the Internet.

You can manage an explicit outbound connectivity to have better control. It could be a Load Balancer with outbound configuration, a NAT gateway, a firewall (Azure Firewall or NVA), or a Public IP.

The implicit connectivity is on a path to retirement. On the 30th of September 2025, the implicit outbound access will be retired, link. After this date, VM will no longer be connected to the Internet if there is no explicit outbound connectivity (like in AWS). Without preparation, it will ruin your 26th of September morning.

Two main options are using a standard load balancer or a Nat Gateway.

With the load balancer, you have to set up a public IP, a backend pool, and an outbound rule. There are two problems. First, the configuration of the backend pool is by IP or by vNic, each time you create a VM you will need to add vNic to the backend pool. The second problem is more complex, the load balancer will use ephemeral ports to associate privateIP-PublicIP flow, and you can run out of this port (SNAT port exhaustion) leaving you with no connection.

With the Nat Gateway, you associate it with a public IP, then associate a subnet to the outbound configuration, so every new VM connected to the subnet will use the Nat Gateway. But if you create a new subnet you will need to associate it to the Nat Gateway. You can also manage the SNAT port exhaustion by adding a new public IP to the Nat Gateway.