Merge pull request #297844 from cachai2/network-refactor

Network refactor

Author: AnnaMHuff

articles/container-apps/TOC.yml

@@ -356,12 +356,10 @@
           href: microservices-dapr-bindings.md
         - name: Microservices communication using Dapr Service Invocation
           href: microservices-dapr-service-invoke.md
-- name: Networking, ingress, and network security
+- name: Networking and ingress
   items:
-    - name: Architecture overview
+    - name: Overview
       href: networking.md
-    - name: Use a custom virtual network
-      href: vnet-custom.md
     - name: Ingress
       items:
         - name: Overview
@@ -385,8 +383,18 @@
         - name: CORS
           href: cors.md
           displayName: Cross origin resource sharing
-    - name: Security
+    - name: Virtual network configuration
+      href: custom-virtual-networks.md
+    - name: Managing outbound connections with Azure Firewall
+      href: use-azure-firewall.md
+    - name: Private endpoints and DNS
+      href: private-endpoints-with-dns.md
+    - name: Securing a custom VNET with an NSG
+      href: firewall-integration.md
+    - name: Tutorials
       items:
+        - name: Use a custom virtual network
+          href: vnet-custom.md
         - name: Configure WAF Application Gateway
           href: waf-app-gateway.md
         - name: Enable User Defined Routes (UDR)
@@ -395,10 +403,8 @@
           items:
           - name: Use rule-based routing
             href: rule-based-routing.md
-          - name: Configure a custom domain
+          - name: Use a custom domain with rule-based routing
             href: rule-based-routing-custom-domain.md
-        - name: Securing a custom VNET with an NSG
-          href: firewall-integration.md
         - name: Use a private endpoint
           href: how-to-use-private-endpoint.md
         - name: Use mTLS

articles/container-apps/billing.md

@@ -42,7 +42,7 @@ The following resources are free during each calendar month, per subscription:
 Free usage doesn't appear on your bill. You're only charged as your resource usage exceeds the monthly free grants amounts.
 
 > [!NOTE]
-> If you use Container Apps with [your own virtual network](networking.md#managed-resources) or your apps utilize other Azure resources, additional charges may apply.
+> If you use Container Apps with [your own virtual network](custom-virtual-networks.md#managed-resources) or your apps utilize other Azure resources, additional charges may apply.
 
 ### Resource consumption charges
 

articles/container-apps/blue-green-deployment.md

@@ -14,7 +14,7 @@ ms.author: ruslany
 zone_pivot_groups: azure-cli-bicep
 ---
 
-# Blue-Green Deployment in Azure Container Apps
+# Blue-green deployment in Azure Container Apps
 
 [Blue-Green Deployment](https://martinfowler.com/bliki/BlueGreenDeployment.html) is a software release strategy that aims to minimize downtime and reduce the risk associated with deploying new versions of an application. In a blue-green deployment, two identical environments, referred to as "blue" and "green," are set up. One environment (blue) is running the current application version and one environment (green) is running the new application version. 
 

articles/container-apps/custom-domains-certificates.md

@@ -114,7 +114,7 @@ Azure Container Apps allows you to bind one or more custom domains to a containe
 1. Once the operation is complete, you see your domain name in the list of custom domains with a status of *Secured*. Navigate to your domain to verify that it's accessible.
 
 > [!NOTE]
-> For container apps in internal Container Apps environments, [extra configuration](./networking.md#dns) is required to use custom domains with VNET-scope ingress.
+> For container apps in internal Container Apps environments, [extra configuration](./private-endpoints-with-dns.md) is required to use custom domains with VNET-scope ingress.
 
 ::: zone-end
 

articles/container-apps/custom-virtual-networks.md

@@ -0,0 +1,168 @@
+---
+title: Configuring virtual networks Azure Container Apps environments
+description: Learn how to configure virtual networks in Azure Container Apps.
+services: container-apps
+author: craigshoemaker
+ms.service: azure-container-apps
+ms.topic:  conceptual
+ms.date: 05/01/2025
+ms.author: cshoe
+---
+
+# Virtual network configuration
+
+A virtual network creates a secure boundary around your Azure Container Apps [environment](environment.md). By default, environments are created with a VNet that is automatically generated. However, using an existing VNet provides more Azure networking features such as integration with Application Gateway, Network Security Groups, and communication with resources behind private endpoints. This configuration is important for enterprise customers who need to isolate internal, mission-critical applications from the public internet.
+
+As you create a virtual network, keep in mind the following situations:
+
+- If you want your container app to restrict all outside access, create an [internal Container Apps environment](networking.md#accessibility-level).
+
+- If you use your own VNet, you need to provide a subnet dedicated exclusively to your container app. This subnet isn't available to other services.
+
+- Network addresses are assigned from a subnet range you define as the environment is created.
+
+  - You can define the subnet range used by the Container Apps environment.
+
+  - You can restrict inbound requests to the environment exclusively to the VNet by deploying the environment as [internal](vnet-custom.md).
+
+> [!NOTE]
+> When you provide your own virtual network, additional [managed resources](custom-virtual-networks.md#managed-resources) are created. These resources incur costs at their associated rates.
+
+As you begin to design the network around your container app, refer to [Plan virtual networks](../virtual-network/virtual-network-vnet-plan-design-arm.md).
+
+:::image type="content" source="media/networking/azure-container-apps-virtual-network.png" alt-text="Diagram of how Azure Container Apps environments use an existing V NET, or you can provide your own.":::
+
+> [!NOTE]
+> Moving VNets among different resource groups or subscriptions isn't allowed if the VNet is in use by a Container Apps environment.
+
+## Subnet
+
+Virtual network integration depends on a dedicated subnet. The allocation of IP addresses in a subnet and the supported subnet sizes depend on the [plan](plans.md) you're using in Azure Container Apps.
+
+Select your subnet size carefully. Subnet sizes can't be modified after you create a Container Apps environment.
+
+Different environment types have different subnet requirements:
+
+# [Workload profiles environment](#tab/workload-profiles-env)
+
+- `/27` is the minimum subnet size required for virtual network integration.
+
+- You must delegate your subnet to `Microsoft.App/environments`.
+
+- When using an external environment with external ingress, inbound traffic routes through the infrastructure’s public IP rather than through your subnet.
+
+- Container Apps automatically reserves 12 IP addresses for integration with the subnet. The number of IP addresses required for infrastructure integration doesn't vary based on the scale demands of the environment. Additional IP addresses are allocated according to the following rules depending on the type of workload profile you're using more IP addresses are allocated depending on your environment's workload profile:
+
+  - [Dedicated workload profile](workload-profiles-overview.md#profile-types): As your container app scales out, each node has one IP address assigned.
+
+  - [Consumption workload profile](workload-profiles-overview.md#profile-types): Each IP address may be shared among multiple replicas. When planning for how many IP addresses are required for your app, plan for 1 IP address per 10 replicas. 
+
+- When you make a [change to a revision](revisions.md#revision-scope-changes) in single revision mode, the required address space is doubled for a short period of time in order to support zero downtime deployments. This affects the real, available supported replicas or nodes for a given subnet size. The following table shows both the maximum available addresses per CIDR block and the effect on horizontal scale.
+
+    | Subnet Size | Available IP Addresses<sup>1</sup> | Max nodes (Dedicated workload profile)<sup>2</sup>| Max replicas (Consumption workload profile)<sup>2</sup> |
+    |--|--|--|--|
+    | /23 | 498 | 249 | 2,490 |
+    | /24 | 242 | 121 | 1,210 |
+    | /25 | 114 | 57 | 570 |
+    | /26 | 50 | 25 | 250 |
+    | /27 | 18 | 9 | 90 |
+
+    <sup>1</sup> The available IP addresses is the size of the subnet minus the 14 IP addresses required for Azure Container Apps infrastructure which includes 5 IP addresses reserved by the subnet.
+    <sup>2</sup> This is accounting for apps in single revision mode.  
+
+# [Consumption-only environment](#tab/consumption-only-env)
+
+- `/23` is the minimum subnet size required for virtual network integration.
+
+- Your subnet must not be delegated to any services.
+
+- The Container Apps runtime reserves a minimum of 60 IPs for infrastructure in your VNet. The reserved amount may increase up to 256 addresses as apps in your environment scale.
+
+- As your apps scale, a new IP address is allocated for each new replica.
+
+- When you make a [change to a revision](revisions.md#revision-scope-changes) in single revision mode, the required address space is doubled for a short period of time in order to support zero downtime deployments. This affects the real, available supported replicas for a given subnet size.
+
+---
+
+### Subnet address range restrictions
+
+# [Workload profiles environment](#tab/workload-profiles-env)
+
+Subnet address ranges can't overlap with the following ranges reserved by Azure Kubernetes Services:
+
+- 169.254.0.0/16
+- 172.30.0.0/16
+- 172.31.0.0/16
+- 192.0.2.0/24
+
+In addition, a workload profiles environment reserves the following addresses:
+
+- 100.100.0.0/17
+- 100.100.128.0/19
+- 100.100.160.0/19
+- 100.100.192.0/19
+
+# [Consumption-only environment](#tab/consumption-only-env)
+
+Subnet address ranges can't overlap with the following ranges reserved by Azure Kubernetes Services:
+
+- 169.254.0.0/16
+- 172.30.0.0/16
+- 172.31.0.0/16
+- 192.0.2.0/24
+
+If you created your container apps environment with a custom service CIDR, make sure your container app's subnet (or any peered subnet) doesn't conflict with your custom service CIDR range.
+
+---
+
+### Subnet configuration with CLI
+
+As a Container Apps environment is created, you provide resource IDs for a single subnet.
+
+If you're using the CLI, the parameter to define the subnet resource ID is `infrastructure-subnet-resource-id`. The subnet hosts infrastructure components and user app containers.
+
+If you're using the Azure CLI with a Consumption only environment and the [platformReservedCidr](vnet-custom-internal.md#networking-parameters) range is defined, both subnets must not overlap with the IP range defined in `platformReservedCidr`.
+
+## NAT gateway integration
+
+You can use NAT Gateway to simplify outbound connectivity for your outbound internet traffic in your virtual network in a workload profiles environment.
+
+When you configure a NAT Gateway on your subnet, the NAT Gateway provides a static public IP address for your environment. All outbound traffic from your container app is routed through the NAT Gateway's static public IP address.
+
+## Managed resources
+
+When you deploy an internal or an external environment into your own network, a new resource group is created in the Azure subscription where your environment is hosted. This resource group contains infrastructure components managed by the Azure Container Apps platform. Don't modify the services in this group or the resource group itself.
+
+> [!NOTE]
+> User-defined tags assigned to your Container Apps environment are replicated to all resources within the resource group, including the resource group itself.
+
+# [Workload profiles environment](#tab/workload-profiles-env)
+
+The name of the resource group created in the Azure subscription where your environment is hosted is prefixed with `ME_` by default, and the resource group name *can* be customized as you create your container app environment.
+
+For external environments, the resource group contains a public IP address used specifically for inbound connectivity to your external environment and a load balancer. For internal environments, the resource group only contains a [Load Balancer](https://azure.microsoft.com/pricing/details/load-balancer/).
+
+In addition to the standard [Azure Container Apps billing](./billing.md), you're billed for:
+
+- One standard static [public IP](https://azure.microsoft.com/pricing/details/ip-addresses/) for egress if using an internal or external environment, plus one standard static [public IP](https://azure.microsoft.com/pricing/details/ip-addresses/) for ingress if using an external environment. If you need more public IPs for egress due to SNAT issues, [open a support ticket to request an override](https://azure.microsoft.com/support/create-ticket/).
+
+- One standard [load balancer](https://azure.microsoft.com/pricing/details/load-balancer/).
+
+- The cost of data processed (in GBs) includes both ingress and egress for management operations.
+
+# [Consumption only environment](#tab/consumption-only-env)
+
+The name of the resource group created in the Azure subscription where your environment is hosted is prefixed with `MC_` by default, and the resource group name *can't* be customized when you create a container app. The resource group contains public IP addresses used specifically for outbound connectivity from your environment and a load balancer.
+
+In addition to the standard [Azure Container Apps billing](./billing.md), you're billed for:
+
+- One standard static [public IP](https://azure.microsoft.com/pricing/details/ip-addresses/) for egress. If you need more IPs for egress due to Source Network Address Translation (SNAT) issues, [open a support ticket to request an override](https://azure.microsoft.com/support/create-ticket/).
+
+- Two standard [load balancers](https://azure.microsoft.com/pricing/details/load-balancer/) if using an internal environment, or one standard [load balancer](https://azure.microsoft.com/pricing/details/load-balancer/) if using an external environment. Each load balancer has fewer than six rules. The cost of data processed (in GBs) includes both ingress and egress for management operations.
+
+---
+
+## Next steps
+
+> [!div class="nextstepaction"]
+> [Managing outbound connections with Azure Firewall](use-azure-firewall.md)

articles/container-apps/firewall-integration.md

@@ -1,21 +1,26 @@
 ---
-title: Securing a custom VNET in Azure Container Apps
-description: Firewall settings to secure a custom VNET in Azure Container Apps
+title: Securing a virtual network in Azure Container Apps
+description: Firewall settings to secure a virtual network in Azure Container Apps
 services: container-apps
-author: CaryChai
+author: craigshoemaker
 ms.service: azure-container-apps
-ms.topic:  reference
-ms.date: 01/09/2025
-ms.author: cachai
+ms.topic: reference
+ms.date: 04/08/2025
+ms.author: cshoe
 ---
 
-# Securing a custom VNET in Azure Container Apps  with Network Security Groups
+# Securing a virtual network in Azure Container Apps with Network Security Groups
 
 Network Security Groups (NSGs) needed to configure virtual networks closely resemble the settings required by Kubernetes.
 
 You can lock down a network via NSGs with more restrictive rules than the default NSG rules to control all inbound and outbound traffic for the Container Apps environment at the subscription level.
 
-In the workload profiles environment, user-defined routes (UDRs) and [securing outbound traffic with a firewall](./networking.md#configuring-udr-with-azure-firewall) are supported. When using an external workload profiles environment, inbound traffic to Azure Container Apps is routed through the public IP that exists in the [managed resource group](./networking.md#workload-profiles-environment-2) rather than through your subnet. This means that locking down inbound traffic via NSG or Firewall on an external workload profiles environment isn't supported. For more information, see [Networking in Azure Container Apps environments](./networking.md#user-defined-routes-udr).
+In the workload profiles environment, user-defined routes (UDRs) and [securing outbound traffic with a firewall](./use-azure-firewall.md) are supported.
+
+> [!NOTE]
+> For a guide on how to set up UDR with Container Apps to restrict outbound traffic with Azure Firewall, visit the how to for [Container Apps and Azure Firewall](user-defined-routes.md).
+
+When using an external workload profiles environment, inbound traffic to Azure Container Apps is routed through the public IP that exists in the [managed resource group](./networking.md#ports-and-ip-addresses) rather than through your subnet. This means that locking down inbound traffic via NSG or Firewall on an external workload profiles environment isn't supported. For more information, see [Control outbound traffic with user defined routes](./user-defined-routes.md).
 
 In the Consumption only environment, express routes aren't supported, and custom user-defined routes (UDRs) have limited support. For more information on the level of UDR support available in a Consumption-only environment, see the [FAQ](faq.yml#do-consumption-only-environments-support-custom-user-defined-routes-).
 
@@ -51,7 +56,6 @@ The following tables describe how to configure a collection of NSG allow rules.
 <sup>1</sup> This address is passed as a parameter when you create an environment. For example, `10.0.0.0/21`.   
 <sup>2</sup> The full range is required when creating your Azure Container Apps as a port within the range will by dynamically allocated. Once created, the required ports are two immutable, static values, and you can update your NSG rules.
 
-
 ### Outbound 
 
 # [Workload profiles environment](#tab/workload-profiles)
@@ -87,14 +91,16 @@ The following tables describe how to configure a collection of NSG allow rules.
 | TCP | Your container app's subnet | \* | `Storage.<Region>` | `443` | Only required when using `Azure Container Registry` to host your images. |
 | TCP | Your container app's subnet | \* | `AzureMonitor` | `443` | Only required when using Azure Monitor. Allows outbound calls to Azure Monitor. |
 
-
 ---
 
 <sup>1</sup> This address is passed as a parameter when you create an environment. For example, `10.0.0.0/21`.  
 <sup>2</sup> If you're using Azure Container Registry (ACR) with NSGs configured on your virtual network, create a private endpoint on your ACR to allow Azure Container Apps to pull images through the virtual network. You don't need to add an NSG rule for ACR when configured with private endpoints.
 
-
 #### Considerations
 
 - If you're running HTTP servers, you might need to add ports `80` and `443`.
 - Don't explicitly deny the Azure DNS address `168.63.129.16` in the outgoing NSG rules, or your Container Apps environment doesn't function.
+
+## Next steps
+
+- [Use a private endpoint](how-to-use-private-endpoint.md)