How many IP Restriction Rules can a ContainerApp have? How can we see the state of updates to a ContainerApp?

Chris 0 Reputation points
2025-07-01T15:58:15.9933333+00:00

We're trying to setup Ingress IP Restriction Rules that allow access only from Azure and other cloud providers. To do this we are adding their published CIDRs to the IP Restriction Rules of our ContainerApp.

In total this is slightly over 10,000 rules.
We were able to deploy a ContainerApp via TerraForm with that many rules successfully.

But as CIDRs change regularly, and some valid users have unpublished CIDRS, we need to be able to update the rules frequently.

The latest REST API uses JSON Merge via the PATCH verb.
We've been able to update a small set of rules this way.

When we apply our full set of rules, we get a 202 response.
Our change log for the ContainerApp shows the request was Accepted, and the status is Started.

It never changes from that, and the rules never show up in the App.

Making a call to the API again for the ContainerApp status it's ProvisioningState does move from InProgress to Succeeded.

So, we have proven that the number of rules can be applied to a ContainerApp when being created.
It seems like the PATCH REST API is unable to complete the update.

How can we get our rules into the ContainerApp?

How can we see what the ACTUAL state of our update is? It never tells us it has failed, or maybe timed out, nothing.

Azure Container Apps
Azure Container Apps
An Azure service that provides a general-purpose, serverless container platform.
698 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Alex Burlachenko 10,800 Reputation points
    2025-07-02T07:04:56.43+00:00

    hi chris! thanks for posting this, its a tricky one but lets break it down ))

    first off, wow 10k+ ip rules? thats a lot but hey if terraform handled it on create, thats a good sign )) for containerapps, theres no hard limit on ip restriction rules in the docs, but performance can get weird with huge batches. microsoft's official stance is 'it depends' on backend processing, which isnt super helpful i know... check their containerapps networking docs here.

    about that patch issue yeah the 202 with no failure state is frustrating. when u hit this, try splitting updates into smaller chunks. like 500 rules at a time. the api might just be choking on the payload size. also, after patching, poll the provisioning state manually. sometimes the ui lags but the api knows whats up. heres a quick powershell snippet to check

    az containerapp revision list --name yourApp --resource-group yourRG
    
    

    as well check the 'revision' status separately! containerapps can get stuck in revision purgatory. run

    az containerapp revision list 
    

    if u see a revision stuck in 'processing', thats ur culprit. might need to roll back or force a new deploy.

    for tracking actual rule states... its messy. the ip restrictions dont show up in 'az containerapp show' output clearly. u gotta dig into the 'configuration.ingress.ipSecurityRestrictions' field. try

    az containerapp show 
    

    avoid giant json patches. use terraform or bicep for incremental changes instead. and yes this headache applies to other azure services too - app services have similar quirks with big ip rule sets.

    ps: microsoft's containerapps team is actively improving this area. their github issues page has some workarounds here. worth subscribing to updates ))

    let us know if chunking the updates helps

    rgds,

    Alex


Your answer

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