Adding some Flex Consumption notes to Networking; updating Premium regions scale numbers

nzthiago · nzthiago · commit 8f0aba98c71b · 2024-06-20T14:49:40.000-07:00
diff --git a/articles/azure-functions/flex-consumption-plan.md b/articles/azure-functions/flex-consumption-plan.md
@@ -128,6 +128,7 @@ In Flex Consumption, many of the standard application settings and site configur
 
 Keep these other considerations in mind when using Flex Consumption plan during the current preview:
 
++ **VNet Integration** Ensure that the `Microsoft.App` Azure resource provider is enabled for your subscription by [following these instructions](https://learn.microsoft.com/azure/azure-resource-manager/management/resource-providers-and-types#register-resource-provider). The subnet delegation required by Flex Consumption apps is `Microsoft.App/environments`.
 + **Triggers**: All triggers are fully supported except for Kafka, Azure SQL, and SignalR triggers. The Blob storage trigger only supports the [Event Grid source](./functions-event-grid-blob-trigger.md). Non-C# function apps must use version `[4.0.0, 5.0.0)` of the [extension bundle](./functions-bindings-register.md#extension-bundles), or a later version. 
 + **Regions**: Not all regions are currently supported. To learn more, see [View currently supported regions](flex-consumption-how-to.md#view-currently-supported-regions).
 + **Deployments**: These deployment-related features aren't currently supported:
diff --git a/articles/azure-functions/functions-networking-options.md b/articles/azure-functions/functions-networking-options.md
@@ -13,17 +13,7 @@ ms.author: cachai
 
 This article describes the networking features available across the hosting options for Azure Functions. All the following networking options give you some ability to access resources without using internet-routable addresses or to restrict internet access to a function app.
 
-The hosting models have different levels of network isolation available. Choosing the correct one helps you meet your network isolation requirements.
-
-You can host function apps in several ways:
-
-* You can choose from plan options that run on a multitenant infrastructure, with various levels of virtual network connectivity and scaling options:
-    * The [Consumption plan](consumption-plan.md) scales dynamically in response to load and offers minimal network isolation options.
-    * The [Premium plan](functions-premium-plan.md) also scales dynamically and offers more comprehensive network isolation.
-    * The Azure [App Service plan](dedicated-plan.md) operates at a fixed scale and offers  network isolation similar to the Premium plan.
-* You can run functions in an [App Service Environment](../app-service/environment/intro.md). This method deploys your function into your virtual network and offers full network control and isolation.
-
-## Matrix of networking features
+The [hosting models](functions-scale.md) have different levels of network isolation available. Choosing the correct one helps you meet your network isolation requirements.
 
 [!INCLUDE [functions-networking-features](../../includes/functions-networking-features.md)]
 
@@ -50,7 +40,7 @@ The following features let you filter inbound requests to your function app.
 
 You can use access restrictions to define a priority-ordered list of IP addresses that are allowed or denied access to your app. The list can include IPv4 and IPv6 addresses, or specific virtual network subnets using [service endpoints](#use-service-endpoints). When there are one or more entries, an implicit "deny all" exists at the end of the list. IP restrictions work with all function-hosting options.
 
-Access restrictions are available in the [Premium](functions-premium-plan.md), [Consumption](consumption-plan.md), and [App Service](dedicated-plan.md).
+Access restrictions are available in the [Flex Consumption plan](flex-consumption-plan.md), [Elastic Premium](functions-premium-plan.md), [Consumption](consumption-plan.md), and [App Service](dedicated-plan.md).
 
 > [!NOTE]
 > With network restrictions in place, you can deploy only from within your virtual network, or when you've put the IP address of the machine you're using to access the Azure portal on the Safe Recipients list. However, you can still manage the function using the portal.
@@ -112,7 +102,7 @@ To learn how to set up virtual network integration, see [Enable virtual network
 
     :::image type="content" source="./media/functions-networking-options/vnet-int-add-vnet-function-app.png" alt-text="Select the VNet":::
 
-    * The Functions Premium Plan only supports regional virtual network integration. If the virtual network is in the same region, either create a new subnet or select an empty, pre-existing subnet.
+    * The Functions Flex Consumption and Elastic Premium plans only supports regional virtual network integration. If the virtual network is in the same region, either create a new subnet or select an empty, pre-existing subnet.
 
     * To select a virtual network in another region, you must have a virtual network gateway provisioned with point to site enabled. Virtual network integration across regions is only supported for Dedicated plans, but global peerings work with regional virtual network integration.
 
@@ -141,9 +131,15 @@ When you use regional virtual network integration, you can use the following Azu
 > 
 > Regional virtual network integration isn't able to use port 25.
 
+For the Flex Consumption plan:
+1. Ensure that the `Microsoft.App` Azure resource provider is enabled for your subscription by [following these instructions](https://learn.microsoft.com/azure/azure-resource-manager/management/resource-providers-and-types#register-resource-provider). The subnet delegation required by Flex Consumption apps is `Microsoft.App/environments`.
+1. The subnet delegation required by Flex Consumption apps is `Microsoft.App/environments`. This is a change from Elastic Premium and App Service which have a different delegation requirement.
+1. You can plan for 40 IP addresses to be used at the most for one function app, even if the app scales beyond 40. For example, if you have fifteen Flex Consumption function apps that will be VNet integrated into the same subnet, you can plan for 15x40 = 600 IP addresses used at the most. This limit is subject to change, and is not enforced.
+1. The subnet can't already be in use for other purposes (like private or service endpoints, or [delegated](https://learn.microsoft.com/azure/virtual-network/subnet-delegation-overview) to any other hosting plan or service). While you can share the same subnet with multiple Flex Consumption apps, the networking resources will be shared across these function apps and this can lead to one function app impacting the performance of others on the same subnet.
+
 There are some limitations with using virtual network:
 
-* The feature is available from all App Service deployments in Premium V2 and Premium V3. It's also available in Standard but only from newer App Service deployments. If you are on an older deployment, you can only use the feature from a Premium V2 App Service plan. If you want to make sure you can use the feature in a Standard App Service plan, create your app in a Premium V3 App Service plan. Those plans are only supported on our newest deployments. You can scale down if you desire after that.
+* The feature is available from Flex Consumption, Elastic Premium, and App Service Premium V2 and Premium V3. It's also available in Standard but only from newer App Service deployments. If you are on an older deployment, you can only use the feature from a Premium V2 App Service plan. If you want to make sure you can use the feature in a Standard App Service plan, create your app in a Premium V3 App Service plan. Those plans are only supported on our newest deployments. You can scale down if you desire after that.
 * The integration subnet can be used by only one App Service plan.
 * The feature can't be used by Isolated plan apps that are in an App Service Environment.
 * The feature requires an unused subnet that's a /28 or larger in an Azure Resource Manager virtual network.
@@ -154,7 +150,7 @@ There are some limitations with using virtual network:
 
 ### Subnets
 
-Virtual network integration depends on a dedicated subnet. When you provision a subnet, the Azure subnet loses five IPs from the start. One address is used from the integration subnet for each plan instance. When you scale your app to four instances, then four addresses are used. 
+Virtual network integration depends on a dedicated subnet. When you provision a subnet, the Azure subnet loses five IPs from the start. For the Elastic Premium and App Service plans, one address is used from the integration subnet for each plan instance. When you scale your app to four instances, then four addresses are used. For Flex Consumption this does not apply and instances share IP addresses.
 
 When you scale up or down in size, the required address space is doubled for a short period of time. This 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 this has on horizontal scale:
 
@@ -166,7 +162,7 @@ When you scale up or down in size, the required address space is doubled for a s
 
 <sup>*</sup>Assumes that you need to scale up or down in either size or SKU at some point. 
 
-Since 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 for Functions Premium plans, you should use a /24 with 256 addresses for Windows and a /26 with 64 addresses for Linux. When creating subnets in Azure portal as part of integrating with the virtual network, a minimum size of /24 and /26 is required for Windows and Linux respectively.
+Since 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 for Functions Elastic Premium plans, you should use a /24 with 256 addresses for Windows and a /26 with 64 addresses for Linux. When creating subnets in Azure portal as part of integrating with the virtual network, a minimum size of /24 and /26 is required for Windows and Linux respectively.
 
 When you want your apps in another plan to reach a virtual network that's already connected to by apps in another plan, select a different subnet than the one being used by the pre-existing virtual network integration.
 
@@ -197,7 +193,7 @@ After your app integrates with your virtual network, it uses the same DNS server
 
 When you create a function app, you must create or link to a general-purpose Azure Storage account that supports Blob, Queue, and Table storage. You can replace this storage account with one that is secured with service endpoints or private endpoints. 
 
-This feature is supported for all Windows and Linux virtual network-supported SKUs in the Dedicated (App Service) plan and for the Premium plans. The Consumption plan isn't supported. To learn how to set up a function with a storage account restricted to a private network, see [Restrict your storage account to a virtual network](configure-networking-how-to.md#restrict-your-storage-account-to-a-virtual-network).
+This feature is supported for all Windows and Linux virtual network-supported SKUs in the Dedicated (App Service) plan and for the Elastic Premium plans, as well as the Flex Consumption plan. The Consumption plan isn't supported. To learn how to set up a function with a storage account restricted to a private network, see [Restrict your storage account to a virtual network](configure-networking-how-to.md#restrict-your-storage-account-to-a-virtual-network).
 
 ## Use Key Vault references
 
@@ -210,11 +206,11 @@ If virtual network integration is configured for the app, [Key Vault references]
 Currently, you can use non-HTTP trigger functions from within a virtual network in one of two ways:
 
 + Run your function app in an [Elastic Premium plan](./functions-premium-plan.md) and enable virtual network trigger support.
-+ Run your function app in an App Service plan or App Service Environment.
++ Run your function app in a Flex Consumption, App Service plan or App Service Environment.
 
-### Premium plan with virtual network triggers
+### Elastic Premium plan with virtual network triggers
 
-The [Premium plan](functions-premium-plan.md) lets you create functions that are triggered by services inside a virtual network. These non-HTTP triggers are known as _virtual network triggers_.   
+The [Elastic Premium plan](functions-premium-plan.md) lets you create functions that are triggered by services inside a virtual network. These non-HTTP triggers are known as _virtual network triggers_.   
 
 By default, virtual network triggers don't cause your function app to scale beyond their pre-warmed instance count. However, certain extensions support virtual network triggers that cause your function app to scale dynamically. You can enable this _dynamic scale monitoring_ in your function app for supported extensions in one of these ways:
 
@@ -283,9 +279,9 @@ To learn more, see the [App Service documentation for Hybrid Connections](../app
 
 ## Outbound IP restrictions
 
-Outbound IP restrictions are available in a Premium plan, App Service plan, or App Service Environment. You can configure outbound restrictions for the virtual network where your App Service Environment is deployed.
+Outbound IP restrictions are available in a Flex Consumption plan, Elastic Premium plan, App Service plan, or App Service Environment. You can configure outbound restrictions for the virtual network where your App Service Environment is deployed.
 
-When you integrate a function app in a Premium plan or an App Service plan with a virtual network, the app can still make outbound calls to the internet by default. By integrating your function app with a virtual network with Route All enabled, you force all outbound traffic to be sent into your virtual network, where network security group rules can be used to restrict traffic.
+When you integrate a function app in an Elastic Premium plan or an App Service plan with a virtual network, the app can still make outbound calls to the internet by default. By integrating your function app with a virtual network with Route All enabled, you force all outbound traffic to be sent into your virtual network, where network security group rules can be used to restrict traffic. For Flex Consumption all trafic is already routed through the virtual network and Route All is not needed.
 
 To learn how to control the outbound IP using a virtual network, see [Tutorial: Control Azure Functions outbound IP with an Azure virtual network NAT gateway](functions-how-to-use-nat-gateway.md). 
 
diff --git a/articles/azure-functions/functions-premium-plan.md b/articles/azure-functions/functions-premium-plan.md
@@ -263,6 +263,7 @@ These are the currently supported maximum scale-out values for a single plan in
 |Jio India West| 100 | 20 |
 |Korea Central| 100 | 20 |
 |Korea South| 40 | 20 |
+|Mexico Central| 20 | 20 |
 |North Central US| 100 | 20 |
 |North Europe| 100 | 100 |
 |Norway East| 100 | 20 |
@@ -271,6 +272,7 @@ These are the currently supported maximum scale-out values for a single plan in
 |South Central US| 100 | 100 |
 |South India | 100 | Not Available |
 |Southeast Asia| 100 | 20 |
+|Spain Central| 20 | 20 |
 |Switzerland North| 100 | 20 |
 |Switzerland West| 100 | 20 |
 |UAE North| 100 | 20 |
diff --git a/includes/functions-timeout-duration.md b/includes/functions-timeout-duration.md
@@ -16,11 +16,11 @@ The following table shows the default and maximum values (in minutes) for specif
 | Plan | Default | Maximum<sup>1</sup> |  
 |------|---------|---------|---------|  
 | **[Consumption plan](../articles/azure-functions/consumption-plan.md)** |  5 | 10 |  
-| **[Flex Consumption plan](../articles/azure-functions/flex-consumption-plan.md)** | 30 | Unlimited<sup>3</sup> |
-| **[Premium plan](../articles/azure-functions/functions-premium-plan.md)** |  30<sup>2</sup> | Unlimited<sup>3</sup> |  
-| **[Dedicated plan](../articles/azure-functions/dedicated-plan.md)** |  30<sup>2</sup> | Unlimited<sup>3</sup> |  
+| **[Flex Consumption plan](../articles/azure-functions/flex-consumption-plan.md)** | 30 | Unlimited<sup>2</sup> |
+| **[Premium plan](../articles/azure-functions/functions-premium-plan.md)** |  30<sup>3</sup> | Unlimited<sup>3</sup> |  
+| **[Dedicated plan](../articles/azure-functions/dedicated-plan.md)** |  30<sup>4</sup> | Unlimited<sup>3</sup> |  
 
-<sup>1</sup> Regardless of the function app timeout setting, 230 seconds is the maximum amount of time that an HTTP triggered function can take to respond to a request. This is because of the [default idle timeout of Azure Load Balancer](../articles/app-service/faq-availability-performance-application-issues.yml#why-does-my-request-time-out-after-230-seconds-). For longer processing times, consider using the [Durable Functions async pattern](../articles/azure-functions/durable/durable-functions-overview.md#async-http) or [defer the actual work and return an immediate response](../articles/azure-functions/performance-reliability.md#avoid-long-running-functions).  
-<sup>2</sup> The default timeout for version 1.x of the Functions runtime is _unlimited_.   
-<sup>3</sup> Guaranteed for up to 60 minutes. [OS and runtime patching](../articles/app-service/overview-patch-os-runtime.md), vulnerability patching, and [scale in behaviors](../articles/azure-functions/event-driven-scaling.md#scale-in-behaviors) can still cancel function executions so [ensure to write robust functions](../articles/azure-functions/functions-best-practices.md#write-robust-functions).
-<sup>4</sup> In a Flex Consumption plan, the host doesn't enforce an execution time limit. However, there are currently no guarantees because the platform might need to terminate your instances during scale-in, deployments, or to apply updates.
+<sup>1</sup> Regardless of the function app timeout setting, 230 seconds is the maximum amount of time that an HTTP triggered function can take to respond to a request. This is because of the [default idle timeout of Azure Load Balancer](../articles/app-service/faq-availability-performance-application-issues.yml#why-does-my-request-time-out-after-230-seconds-). For longer processing times, consider using the [Durable Functions async pattern](../articles/azure-functions/durable/durable-functions-overview.md#async-http) or [defer the actual work and return an immediate response](../articles/azure-functions/performance-reliability.md#avoid-long-running-functions).
+<sup>2</sup> In a Flex Consumption plan, the host doesn't enforce an execution time limit. However, there are currently no guarantees as the platform might need to terminate your instances during scale-in, deployments, or to apply updates.
+<sup>3</sup> The default timeout for version 1.x of the Functions runtime is _unlimited_.
+<sup>4</sup> Guaranteed for up to 60 minutes. [OS and runtime patching](../articles/app-service/overview-patch-os-runtime.md), vulnerability patching, and [scale in behaviors](../articles/azure-functions/event-driven-scaling.md#scale-in-behaviors) can still cancel function executions so [ensure to write robust functions](../articles/azure-functions/functions-best-practices.md#write-robust-functions).
