Merge pull request #302652 from brianlehr/patch-92

Update default-outbound-access.md

Author: denrea

articles/virtual-network/ip-services/default-outbound-access.md

@@ -1,5 +1,5 @@
 ---
-title: Default outbound access in Azure
+title: Default Outbound Access in Azure
 titleSuffix: Azure Virtual Network
 description: Learn about default outbound access in Azure.
 author: mbender-ms
@@ -13,68 +13,55 @@ ms.date: 06/11/2025
 
 # Default outbound access in Azure
 
-In Azure, virtual machines created in a virtual network without explicit outbound connectivity defined are assigned a default outbound public IP address. This IP address enables outbound connectivity from the resources to the Internet. This access is referred to as default outbound access. 
+In Azure, when a virtual machine (VM) is deployed in a virtual network without an explicitly defined outbound connectivity method, it's automatically assigned an outbound public IP address. This IP address enables outbound connectivity from the resources to the Internet and to other public endpoints within Microsoft. This access is referred to as default outbound access.
 
 Examples of explicit outbound connectivity for virtual machines are:
 
-* Created within a subnet associated to a NAT gateway.
-
+* Deployed in a subnet associated to a NAT gateway.
 * Deployed in the backend pool of a standard load balancer with outbound rules defined.
-
 * Deployed in the backend pool of a basic public load balancer.
-
 * Virtual machines with public IP addresses explicitly associated to them.
 
 :::image type="content" source="./media/default-outbound-access/explicit-outbound-options.png" alt-text="Diagram of explicit outbound options.":::
 
-## How is default outbound access provided?
+## How and when default outbound access is provided
 
-The public IPv4 address used for the access is called the default outbound access IP. This IP is implicit and belongs to Microsoft. This IP address is subject to change and it's not recommended to depend on it for production workloads.
-
-## When is default outbound access provided?
-
-If you deploy a virtual machine in Azure and it doesn't have explicit outbound connectivity, it's assigned a default outbound access IP.
+If a Virtual Machine (VM) is deployed without an explicit outbound connectivity method, Azure assigns it a default outbound public IP address. This IP, known as the default outbound access IP, is owned by Microsoft and may change without notice. It isn't recommended for production workloads.
 
 :::image type="content" source="./media/default-outbound-access/decision-tree-load-balancer-thumb.png"  alt-text="Diagram of decision tree for default outbound access." lightbox="./media/default-outbound-access/decision-tree-load-balancer.png":::
 
 >[!Important]
->On September 30, 2025, default outbound access for new deployments will be retired. For more information, see the [official announcement](https://azure.microsoft.com/updates/default-outbound-access-for-vms-in-azure-will-be-retired-transition-to-a-new-method-of-internet-access/).  We recommend that you use one of the explicit forms of connectivity discussed in the following section.
+>After September 30, 2025, new virtual networks will default to using private subnets, meaning that an explicit outbound method must be enabled in order to reach public endpoints on the Internet and within Microsoft. For more information, see the [official announcement](https://azure.microsoft.com/updates/default-outbound-access-for-vms-in-azure-will-be-retired-transition-to-a-new-method-of-internet-access/).  We recommend that you use one of the explicit forms of connectivity discussed in the following section.
 
 ## Why is disabling default outbound access recommended?
 
-* Secure by default
-    
-    * It's not recommended to open a virtual network to the Internet by default using the Zero Trust network security principle.
-
-* Explicit vs. implicit
+* Security: Default Internet access contradicts Zero Trust principles.
 
-    * It's recommended to have explicit methods of connectivity instead of implicit when granting access to resources in your virtual network.
+* Clarity: Explicit connectivity is preferred over implicit access.
 
-* Loss of IP address
+* Stability: The default outbound IP isn't customer-owned and may change, leading to potential disruptions.
 
-    * Customers don't own the default outbound access IP. This IP might change, and any dependency on it could cause issues in the future.
+Some examples of configurations that don't work when using default outbound access:
+- Multiple NICs on a VM may yield inconsistent outbound IPs
+- Scaling VM Scale Sets can result in changing outbound IPs
+- Outbound IPs aren't consistent or contiguous across VMSS instances
 
-Some examples of configurations that won't work when using default outbound access:
-- When you have multiple NICs on the same VM, default outbound IPs won't consistently be the same across all NICs.
-- When scaling up/down Virtual Machine Scale sets, default outbound IPs assigned to individual instances can change.
-- Similarly, default outbound IPs aren't consistent or contiguous across VM instances in a Virtual Machine Scale Set.
+Additionally,
+* Default outbound access IPs don't support fragmented packets
+* Default outbound access IPs don't support ICMP pings
 
 ## How can I transition to an explicit method of public connectivity (and disable default outbound access)?
 
-There are multiple ways to turn off default outbound access. The following sections describe the options available to you.
- 
-### Utilize the Private Subnet parameter
+### Private subnets overview
 
 * Creating a subnet to be Private prevents any virtual machines on the subnet from utilizing default outbound access to connect to public endpoints.
- 
-* VMs on a Private subnet can still access the Internet using explicit outbound connectivity.
- 
+* VMs on a Private subnet can still access the Internet (or any public endpoints within Microsoft) using explicit outbound connectivity.
     > [!NOTE]
-    > Certain services won't function on a virtual machine in a Private Subnet without an explicit method of egress (examples are Windows Activation and Windows Updates).
+    > Certain services don't function on a virtual machine in a Private Subnet without an explicit method of egress (examples are Windows Activation and Windows Updates).
  
-#### Add the Private subnet feature
+### How to configure private subnets
 
- * From the Azure portal, select the subnet and select the checkbox to enable Private subnet as shown below:
+ * From the Azure portal, select the subnet and select the checkbox to enable Private subnet as shown:
 
 :::image type="content" source="./media/default-outbound-access/private-subnet-portal.png"  alt-text="Screenshot of Azure portal showing Private subnet option.":::
 
@@ -156,56 +143,43 @@ az network vnet subnet update --resource-group rgname --name subnetname --vnet-n
 }
 ```
 
-#### Private subnet limitations
+### Limitations of private subnets
 
 * To activate or update virtual machine operating systems, such as Windows, an explicit outbound connectivity method is required.
 
-* In configurations using User Defined Routes (UDRs), any configured routes with [next hop type `Internet`](../virtual-networks-udr-overview.md#next-hop-types-across-azure-tools) will break in a Private subnet.
+* In configurations using User Defined Routes (UDRs), any configured routes with [next hop type `Internet`](../virtual-networks-udr-overview.md#next-hop-types-across-azure-tools) break in a Private subnet.
 
   * A common example is the use of a UDR to steer traffic to an upstream network virtual appliance/firewall, with exceptions for certain Azure Service Tags to bypass inspection.
 
     * A default route for the destination 0.0.0.0/0, with a next hop type of Virtual Appliance applies in the general case.
 
-    * One or more routes are configured to [Service Tag destinations](../virtual-networks-udr-overview.md#service-tags-for-user-defined-routes) with next hop type `Internet`, to bypass the NVA/firewall. Unless an [explicit outbound connectivity method](#add-an-explicit-outbound-connectivity-method) is also configured for the source of the connection to these destinations, attempts to connection to these destinations will fail, because default outbound access isn't available.
+    * One or more routes are configured to [Service Tag destinations](../virtual-networks-udr-overview.md#service-tags-for-user-defined-routes) with next hop type `Internet`, to bypass the NVA/firewall. Unless an explicit outbound connectivity method is also configured for the source of the connection to these destinations, attempts to connection to these destinations fail, because default outbound access isn't available.
 
   * This limitation doesn't apply to the use of Service Endpoints, which use a different next hop type `VirtualNetworkServiceEndpoint`. See [Virtual Network service endpoints](../virtual-network-service-endpoints-overview.md).
 
 * Private Subnets aren't applicable to delegated or managed subnets used for hosting PaaS services. In these scenarios, outbound connectivity is managed by the individual service.
+
+>[!Important]
+> When a load balancer backend pool is configured by IP address, it uses default outbound access due to an ongoing known issue. For secure by default configuration and applications with demanding outbound needs, associate a NAT gateway to the VMs in your load balancer's backend pool to secure traffic. See more on existing [known issues](../../load-balancer/whats-new.md#known-issues).
  
-### Add an explicit outbound connectivity method
- 
-* Associate a NAT gateway to the subnet of your virtual machine.
+### Add an explicit outbound method
 
+* Associate a NAT gateway to the subnet of your virtual machine.  Note this is the recommended method for the majority of scenarios.
 * Associate a standard load balancer configured with outbound rules.
- 
 * Associate a Standard public IP to any of the virtual machine's network interfaces (if there are multiple network interfaces, having a single NIC with a standard public IP prevents default outbound access for the virtual machine).
+* Add a Firewall or Network Virtual Appliance (NVA) to your virtual network and point traffic to it using a User Defined Route (UDR).
 
 >[!NOTE]
-> There's a NIC-level parameter (defaultOutboundConnectivityEnabled) which tracks if default outbound access is being utilized.  When an explicit outbound connectivity method is added to a virtual machine, in order for the parameter to be updated, the virtual machine must be rebooted. The Advisor "Add explicit outbound method to disable default outbound" operates by checking for this parameter- so a stop/deallocate of the virtual machine is required for changes to be reflected and the action to clear. 
- 
-### Use Flexible orchestration mode for Virtual Machine Scale Sets
+> There's a NIC-level parameter (defaultOutboundConnectivityEnabled) which tracks if default outbound access is being utilized.  When an explicit outbound connectivity method is added to a virtual machine, in order for the parameter to be updated, the virtual machine must be rebooted. The Advisor "Add explicit outbound method to disable default outbound" operates by checking for this parameter- so a stop/deallocate of the virtual machine is required for changes to be reflected and the action to clear. (This is also true in the reverse; in order for a machine to be given a default outbound IP after having the subnet-level parameter set to false, a stop/deallocate of the virtual machine is required.)
+
+#### Use flexible orchestration mode for Virtual Machine Scale Sets
 
 * Flexible scale sets are secure by default. Any instances created via Flexible scale sets don't have the default outbound access IP associated with them, so an explicit outbound method is required. For more information, see [Flexible orchestration mode for Virtual Machine Scale Sets](/azure/virtual-machine-scale-sets/virtual-machine-scale-sets-orchestration-modes#what-has-changed-with-flexible-orchestration-mode)
- 
->[!Important]
-> When a load balancer backend pool is configured by IP address, it will use default outbound access due to an ongoing known issue. For secure by default configuration and applications with demanding outbound needs, associate a NAT gateway to the VMs in your load balancer's backend pool to secure traffic. See more on existing [known issues](../../load-balancer/whats-new.md#known-issues).
-
-## If I need outbound access, what is the recommended way? 
-
-NAT gateway is the recommended approach to have explicit outbound connectivity. A firewall can also be used to provide this access.
-
-## Constraints
-
-* Default outbound access IP doesn't support fragmented packets.
-
-* Default outbound access IP doesn't support ICMP pings.
 
 ## Next steps
 
-For more information on outbound connections in Azure and Azure NAT Gateway, see:
+For more information on outbound connections in Azure, see:
 
 * [Source Network Address Translation (SNAT) for outbound connections](../../load-balancer/load-balancer-outbound-connections.md).
 
 * [What is Azure NAT Gateway?](../../nat-gateway/nat-overview.md)
-
-* [Azure NAT Gateway FAQ](../../nat-gateway/faq.yml)