Networking and CIDR¶
Subnet planning for Azure Container Apps is an environment design task, not a last-minute deployment detail. The minimum CIDR, delegation model, and IP allocation rules all depend on which environment type you create.
Main Content¶
Minimum subnet sizes¶
| Environment type | Minimum subnet size | Notes |
|---|---|---|
| Workload profiles (v2) | /27 | Supports newer networking features |
| Consumption-only (v1) | /23 | Legacy model with different internal addressing needs |
Do not reuse the environment subnet
Microsoft Learn requires a subnet that is dedicated exclusively to the Container Apps environment. Treat it as environment-owned capacity, not shared subnet space.
Delegation and subnet roles¶
For custom VNets:
- Workload profiles (v2): delegate the subnet to
Microsoft.App/environments. - Consumption-only (v1): do not delegate the subnet.
Microsoft Learn also describes the infrastructureSubnetId as the subnet for infrastructure components and user application containers. In other words, the standard deployment model uses one customer-managed infrastructure subnet rather than separate customer-managed runtime and platform subnets.
For the legacy Consumption-only environment, Learn also documents optional internal ranges such as platformReservedCidr and dockerBridgeCidr for platform networking.
flowchart TD
VNET[Customer VNet] --> SUBNET[Dedicated Container Apps subnet]
SUBNET --> INFRA[Reserved infrastructure IPs]
SUBNET --> NODE[Dedicated profile nodes]
SUBNET --> REPLICA[Consumption replicas]
INFRA --> ENV[Managed environment services]
NODE --> APP1[Dedicated profile apps]
REPLICA --> APP2[Consumption profile apps] IP allocation model¶
Microsoft Learn's /27 planning example is the key rule of thumb:
- A
/27subnet has 32 IPs total. - 11 IP addresses are reserved for Container Apps infrastructure.
- That leaves 21 available IP addresses.
The same example then differentiates how those remaining IPs are consumed:
| Placement model | IP pressure driver | Practical meaning |
|---|---|---|
| Consumption | Per replica | Replica count can become the limiting factor |
| Dedicated | Per VM node | Many replicas can share fewer node IPs |
Zero-downtime rollouts can increase temporary IP demand
The CLI guidance explicitly notes that Consumption can need double IPs during zero-downtime deployment because the old revision remains until the new revision is healthy.
Sizing guidance¶
Start larger than the documented minimum when:
- You expect many Consumption replicas.
- You want headroom for revision overlap during rollout.
- You plan to add more dedicated node pools later.
- You expect the environment to become a shared landing zone for multiple teams.
Portal view: non-VNet-integrated baseline¶
The Networking blade on an environment created without a custom VNet is the contrast baseline for this page's CIDR rules — the subnet sizing table only applies when a VNet integration is configured.

[Observed] The General tab shows Public Network Access : Enable - Allows incoming traffic from the public internet (radio button selected). The Virtual network section reads This environment isn't integrated. The tab strip lists General, Ingress settings, Request Routing, Encryption, Custom DNS Suffix. No subnet resource ID, CIDR range, or delegation field is visible on the blade.
[Inferred] The This environment isn't integrated text is consistent with this page's Minimum subnet sizes table only applying once a custom VNet is in scope. The absence of a subnet resource ID or CIDR field on this blade appears to map to topics covered later in this page's Delegation and subnet roles and IP allocation model sections.
[Not Proven] This image does not visualize the infrastructureSubnetId property described in this page's Delegation and subnet roles section, the Microsoft.App/environments delegation requirement, or the platformReservedCidr / dockerBridgeCidr legacy ranges. It does not visualize the /27 vs /23 minimum subnet sizes from this page's Minimum subnet sizes table, the reserved 11 IP addresses, or the per-replica vs per-node IP allocation distinction from this page's IP allocation model section.