Is it possible to increase the size for the subnet that is used by a Container App Environment?

Zhang, Ivy 20 Reputation points
2026-08-28T13:09:43.9533333+00:00

A subnet with size /27 was created and used by a Container App Environment. Now we need to increase the maximin instances from 10 to 12, but got error saying the subnet is too small.

When trying to change the subnet size to /26, got error saying that the operation failed because the subnet was in use.

Is it possible to increase the size for the subnet that is used by a Container App Environment?

Azure Container Apps
Azure Container Apps

An Azure service that provides a general-purpose, serverless container platform.

0 comments
Answer accepted by question author
Marcin Policht 107K Reputation points MVP Volunteer Moderator
2026-08-28T13:39:47.2133333+00:00

Unfortunately, AFAIK, no - you won't be able to resize the subnet in place while it is being used by an Azure Container Apps Environment. The error indicating that the subnet is in use is expected. Azure does not allow you to change the address prefix of a subnet that is currently attached to a Container Apps Environment.

The /27 subnet contains 32 IP addresses, but not all 32 are available for Container Apps replicas. Azure reserves addresses for the subnet and the Container Apps environment infrastructure, so the usable capacity is lower. Increasing the maximum number of replicas from 10 to 12 can therefore cause Azure to report that the subnet is too small.

You also cannot solve this by adding another subnet to the existing Container Apps Environment. The environment uses its configured infrastructure subnet, so adding a second subnet does not expand the available IP address capacity for that environment.

One option is to create a larger subnet, such as a /26, and create a new Container Apps Environment that uses the larger subnet. You can then deploy the existing Container Apps into the new environment and validate them before switching production traffic to it. This allows you to make the change with minimal or no user-visible interruption, provided the applications and their ingress, DNS, certificates, identities, networking, and other dependencies are configured correctly in the new environment.

A /26 provides 64 IP addresses rather than the 32 provided by a /27, giving the Container Apps Environment substantially more address capacity for replicas and infrastructure. If you expect the applications to scale beyond 12 instances in the future, it is worth sizing the new subnet with additional growth capacity rather than choosing the smallest subnet that works today.

If the above response helps answer your question, remember to "Accept Answer" so that others in the community facing similar issues can easily find the solution. Your contribution is highly appreciated.

hth

Marcin

Was this answer helpful?

1 person found this answer helpful.

2 additional answers

Sort by: Newest
Most helpful Newest Oldest
  1. Zhang, Ivy 20 Reputation points
    2026-08-28T17:33:24.1366667+00:00

    Thanks everyone for the answers.

    Was this answer helpful?

    0 comments
  2. Rukmini 43,915 Reputation points Microsoft External Staff Moderator
    2026-08-28T15:26:01.83+00:00

    Hello @Zhang, Ivy

    Hey! Based on the docs, what you’re seeing is expected behavior.

    Can you increase the subnet size after creating an Azure Container Apps environment?

    For Azure Container Apps environments (workload profile and consumption scenarios), you can’t modify the subnet size after you create the environment. The environment’s networking setup (including the infrastructure subnet) is chosen at deployment time, and subnet size changes aren’t supported—so updates like changing /27 to /26 will fail because the subnet is already in use by the existing environment.

    Why the subnet looks “too small” when scaling

    When you scale the environment/container apps, Container Apps needs IP addresses for its infrastructure components plus the integration between the apps and the subnet. For example, for workload profile environments, Container Apps:

    • requires at least a /27 subnet for virtual network integration, and
    • automatically reserves 12 IP addresses for infrastructure integration, independent of scale demands
    • allocates additional IPs as replicas/nodes scale (with rules that depend on dedicated vs consumption workload profiles)
    • in single-revision mode, IP requirements are temporarily doubled during revision changes (zero-downtime deployments), which can further reduce the “available” supported replicas/nodes for the subnet size during those operations.

    So even though you only want to increase max instances from 10 to 12, the /27 CIDR may not have enough usable IP space for the additional replicas/nodes once all reserved/temporary addressing is accounted for.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.