Merge branch 'main' of https://github.com/ADOYLEMSFT/azure-docs-pr

Author: ADOYLEMSFT

articles/api-management/virtual-network-injection-resources.md

@@ -40,17 +40,29 @@ The minimum size of the subnet in which API Management can be deployed is /29, w
 
 * When deploying into an [internal virtual network](./api-management-using-with-internal-vnet.md), the instance requires an extra IP address for the internal load balancer.
 
+> [!NOTE]
+> When considering a subnet size, it is advisable to err on the side of caution due to the integral role that API Management typically holds. Consider growth and scaling in your sizing.
+
 ### Examples
 
-* **/29 subnet**: 8 possible IP addresses - 5 reserved Azure IP addresses - 2 API Management IP addresses for one instance - 1 IP address for internal load balancer, if used in internal mode = 0 remaining IP addresses left for scale-out units.  
-  
-* **/28 subnet**: 16 possible IP addresses - 5 reserved Azure IP addresses - 2 API Management IP addresses for one instance - 1 IP address for internal load balancer, if used in internal mode = 8 remaining IP addresses left for four scale-out units (2 IP addresses/scale-out unit) for a total of five units.   
-  
-* **/27 subnet**: 32 possible IP addresses - 5 reserved Azure IP addresses - 2 API Management IP addresses for one instance - 1 IP address for internal load balancer, if used in internal mode = 24 remaining IP addresses left for 12 scale-out units (2 IP addresses/scale-out unit) for a total of 13 units. 
-  
-* **/26 subnet**: 64 possible IP addresses - 5 reserved Azure IP addresses - 2 API Management IP addresses for one instance - 1 IP address for internal load balancer, if used in internal mode = 56 remaining IP addresses left for 28 scale-out units (2 IP addresses/scale-out unit) for a total of 29 units. 
-  
-* **/25 subnet**: 128 possible IP addresses - 5 reserved Azure IP addresses - 2 API Management IP addresses for one instance - 1 IP address for internal load balancer, if used in internal mode = 120 remaining IP addresses left for 60 scale-out units (2 IP addresses/scale-out unit) for a total of 61 units. This is a large, theoretical number of scale-out units. 
+The following table shows subnet sizing examples for API Management virtual network injection, illustrating how different CIDR blocks affect the number of scale-out units possible:
+
+| Subnet CIDR | Total IP addresses | Azure reserved IPs | API Management instance IPs | Internal load balancer IP | Remaining IPs for scale-out | Max scale-out units | Total max units |
+|------------:|-------------------:|-------------------:|----------------------------:|--------------------------:|----------------------------:|--------------------:|----------------:|
+|        /29  |                  8 |                  5 |                           2 |                         1 |                           0 |                   0 |               1 |
+|        /28  |                 16 |                  5 |                           2 |                         1 |                           8 |                   4 |               5 |
+|        /27  |                 32 |                  5 |                           2 |                         1 |                          24 |                  12 |              13 |
+|        /26  |                 64 |                  5 |                           2 |                         1 |                          56 |                  28 |              29 |
+|        /25  |                128 |                  5 |                           2 |                         1 |                         120 |                 60* |             61* |
+
+## Key Points
+
+- **Minimum subnet size**: /29 (provides 3 usable IP addresses for API Management)
+- **Azure reserved IPs**: 5 addresses per subnet (first and last for protocol conformance, plus 3 for Azure services)
+- **Scale-out requirement**: Each scale-out unit requires 2 IP addresses
+- **Internal load balancer**: Only required when API Management is deployed in internal virtual network mode
+- **Premium SKU limit**: * Currently supports up to 31 units maximum
+- **Recommended sizing**: For high-scale scenarios approaching the Premium SKU limit, consider /26 or /25 subnets
 
 > [!NOTE]
 > It is currently possible to scale the Premium SKU to 31 units. If you foresee demand approaching this limit, consider the /26 subnet or /25 subnet.

articles/app-service/media/tutorial-auth-aad/configure-auth-back-end.png

@@ -75,8 +75,7 @@ In other tiers, an app runs and scales as follows:
 - If multiple apps are in the same App Service plan, they all share the same VM instances.
 - If you have multiple deployment slots for an app, all deployment slots also run on the same VM instances.
 - If you enable diagnostic logs, perform backups, or run [WebJobs](webjobs-create.md), they also use CPU cycles and memory on these VM instances.
-
-In this way, the App Service plan is the scale unit of the App Service apps. If the plan is configured to run five VM instances, then all apps in the plan run on all five instances. If the plan is configured for autoscaling, then all apps in the plan are scaled out together, based on the autoscale settings.
+- All apps in an App Service plan scale together, because they share the same underlying compute resources (VM instances). Scaling the plan — whether manually or through autoscale rules — affects all apps in the plan.
 
 For more information on scaling out an app, see [Get started with autoscale in Azure](/azure/azure-monitor/autoscale/autoscale-get-started).