Merge pull request #232954 from madsd/ipupdate

Ipupdate

Author: prmerger-automator[bot]

articles/app-service/overview-vnet-integration.md

@@ -3,7 +3,7 @@ title: Integrate your app with an Azure virtual network
 description: Integrate your app in Azure App Service with Azure virtual networks.
 author: madsd
 ms.topic: conceptual
-ms.date: 03/16/2023
+ms.date: 03/31/2023
 ms.author: madsd
 ms.custom: UpdateFrequency3
 
@@ -66,19 +66,11 @@ The feature supports two virtual interfaces per worker. Two virtual interfaces p
 
 ## Subnet requirements
 
-Virtual network integration depends on a dedicated subnet. When you create a subnet, the Azure subnet consumes five IPs from the start. One address is used from the integration subnet for each plan instance. If you scale your app to four instances, then four addresses are used.
+Virtual network integration depends on a dedicated subnet. When you create a subnet, the Azure subnet consumes five IPs from the start. One address is used from the integration subnet for each App Service plan instance. If you scale your app to four instances, then four addresses are used.
 
-When you scale up or down in size, the required address space is doubled for a short period of time. The scale operation affects the real, available supported instances for a given subnet size. The following table shows both the maximum available addresses per CIDR block and the effect the available addresses has on horizontal scale.
+When you scale up or down in size, the required address space is doubled for a short period of time. The scale operation affects the real, available supported instances for a given subnet size. Platform upgrades need free IP addresses to ensure upgrade can happen without interruptions to outbound traffic. Finally, after scale up, down or in operations complete, there might be a short period of time before IP addresses are released. 
 
-| CIDR block size | Maximum available addresses | Maximum horizontal scale (instances)<sup>*</sup> |
-|-----------------|-------------------------|---------------------------------|
-| /28             | 11                      | 5                               |
-| /27             | 27                      | 13                              |
-| /26             | 59                      | 29                              |
-
-<sup>*</sup>Assumes that you need to scale up or down in either size or SKU at some point.
-
-Because subnet size can't be changed after assignment, use a subnet that's large enough to accommodate whatever scale your app might reach. To avoid any issues with subnet capacity, use a `/26` with 64 addresses. When you're creating subnets in Azure portal as part of integrating with the virtual network, a minimum size of /27 is required. If the subnet already exists before integrating through the portal, you can use a /28 subnet.
+Because subnet size can't be changed after assignment, use a subnet that's large enough to accommodate whatever scale your app might reach. You should also reserve IP addresses for platform upgrades. To avoid any issues with subnet capacity, use a `/26` with 64 addresses. When you're creating subnets in Azure portal as part of integrating with the virtual network, a minimum size of /27 is required. If the subnet already exists before integrating through the portal, you can use a /28 subnet.
 
 >[!NOTE]
 > Windows Containers uses an additional IP address per app for each App Service plan instance, and you need to size the subnet accordingly. If you have for example 10 Windows Container App Service plan instances with 4 apps running, you will need 50 IP addresses and additional addresses to support horizontal (up/down) scale.