Merge remote-tracking branch 'samuel/update-subnet-info' into samz

Author: ggailey777

articles/azure-functions/container-concepts.md

@@ -25,7 +25,7 @@ There are several options for hosting your containerized function apps in Azure:
 | --- | --- |  
 | **[Azure Container Apps]** | Azure Functions provides integrated support for developing, deploying, and managing containerized function apps on [Azure Container Apps](../container-apps/overview.md). This integration enables you to manage your apps using the same Functions tools and pages in the Azure portal. Use Azure Container Apps to host your function app containers when you need to run your event-driven functions in Azure in the same environment as other microservices, APIs, websites, workflows, or any container hosted programs. Container Apps hosting lets you run your functions in a managed Kubernetes-based environment with built-in support for open-source monitoring, mTLS, Dapr, and KEDA. Supports scale-to-zero and provides a serverless pay-for-what-you-use hosting model. You can also request dedicated hardware, even GPUs, by using workload profiles. _Recommended hosting option for running containerized function apps on Azure._ | 
 | **Azure Arc-enabled Kubernetes clusters (preview)** | You can host your function apps on Azure Arc-enabled Kubernetes clusters as either a code-only deployment or in a custom Linux container. Azure Arc lets you attach Kubernetes clusters so that you can manage and configure them in Azure. _Hosting Azure Functions containers on Azure Arc-enabled Kubernetes clusters is currently in preview._  For more information, see [Working with containers and Azure Functions](functions-how-to-custom-container.md?pivots=azure-arc).|
-| **[Azure Functions]** | You can host your containerized function apps in Azure Functions by running the container in either an [Elastic Premium plan](./functions-premium-plan.md) or a [Dedicated plan](./dedicated-plan.md). Premium plan hosting provides you with the benefits of dynamic scaling. You might want to use Dedicated plan hosting to take advantage of existing unused App Service plan resources. |  
+| **[Azure Functions]** | You can host your containerized function apps in Azure Functions by running the container in a [Container Apps](./functions-container-apps-hosting.md), an [Elastic Premium](./functions-premium-plan.md), or an [App Service (Dedicated)](./dedicated-plan.md) plan. Use the Container Apps plan for rich container support from Container Apps. Premium plan hosting provides you with the benefits of dynamic scaling. You might want to use Dedicated plan hosting to take advantage of existing unused App Service plan resources.  |  
 | **[Kubernetes]** | Because the Azure Functions runtime provides flexibility in hosting where and how you want, you can host and manage your function app containers directly in Kubernetes clusters. [KEDA](https://keda.sh) (Kubernetes-based Event Driven Autoscaling) pairs seamlessly with the Azure Functions runtime and tooling to provide event driven scale in Kubernetes. Keep in mind that running your containerized function apps on Kubernetes, either by using KEDA or by direct deployment, is an open-source effort that you can use free of cost, with best-effort support provided by contributors and from the community. You're responsible for maintaining your own function app containers in a cluster, even when deploying to Azure Kubernetes Service (AKS). |
 
 ## Feature support comparison

articles/azure-functions/flex-consumption-how-to.md

@@ -316,6 +316,7 @@ You can't currently configure virtual networking in Visual Studio Code.
 When choosing a subnet, these considerations apply:
 
 + The subnet you choose can't already be used for other purposes, such as with private endpoints or service endpoints, or be delegated to any other hosting plan or service. 
+* You cannot share the same subnet between a Container Apps environment and a Flex Consumption app.
 + You can share the same subnet with more than one app running in a Flex Consumption plan. Because the networking resources are shared across all apps, one function app might impact the performance of others on the same subnet.
 + In a Flex Consumption plan, a single function app might use up to 40 IP addresses, even when the app scales beyond 40 instances. While this rule of thumb is helpful when estimating the subnet size you need, it's not strictly enforced.  
 

articles/azure-functions/functions-networking-options.md

@@ -115,10 +115,13 @@ When you use regional virtual network integration, you can use the following Azu
 > Regional virtual network integration isn't able to use port 25.
 
 Considerations for the [Flex Consumption](./flex-consumption-plan.md) plan:
+* The app and the virtual network must be in the same region.
 * Ensure that the `Microsoft.App` Azure resource provider is enabled for your subscription by [following these instructions](../azure-resource-manager/management/resource-providers-and-types.md#register-resource-provider). This is needed for subnet delegation.
 * The subnet delegation required when running in a Flex Consumption plan is `Microsoft.App/environments`. This differs from the Elastic Premium and Dedicated (App Service) plans, which have a different delegation requirement.
 * 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 15 Flex Consumption function apps that are integrated in the same subnet, you must plan for 15x40 = 600 IP addresses used at the most. This limit is subject to change, and is not enforced.
 * The subnet can't already be in use for other purposes (like private or service endpoints, or [delegated](../virtual-network/subnet-delegation-overview.md) to any other hosting plan or service). While you can share the same subnet with multiple Flex Consumption apps, the networking resources are shared across these function apps, which can lead to one app impacting the performance of others on the same subnet.
+* You cannot share the same subnet between a Container Apps environment and a Flex Consumption app.
+* The Flex Consumption plan currently doesn't support subnets with names that contain underscore (`_`) characters.
 
 Considerations for the [Elastic Premium](./functions-premium-plan.md), [Dedicated (App Service)](./dedicated-plan.md), and [Container Apps](./functions-container-apps-hosting.md) plans:
 
@@ -128,6 +131,7 @@ Considerations for the [Elastic Premium](./functions-premium-plan.md), [Dedicate
 * The feature requires an unused subnet that's a /28 or larger in an Azure Resource Manager virtual network.
 * The integration subnet can be used by only one App Service plan.
 * You can have up to two regional virtual network integrations per App Service plan. Multiple apps in the same App Service plan can use the same integration subnet.
+* The subnet can't already be in use for other purposes (like private or service endpoints, or [delegated](../virtual-network/subnet-delegation-overview.md) to the Flex Consumption plan or any other service). While you can share the same subnet with multiple apps in the same App Service plan, the networking resources are shared across these function apps, which can lead to one app impacting the performance of others on the same subnet.
 * You can't delete a virtual network with an integrated app. Remove the integration before you delete the virtual network.
 * You can't change the subscription of an app or a plan while there's an app that's using regional virtual network integration.