Every project in a Foundry account draws IPs from the same delegated subnet

Two kinds of thing take addresses out of the delegated subnet: the Micro VMs that run hosted agents, and the data proxy instances that reach Storage, Cosmos DB, Azure AI Search and Key Vault through private endpoints ^[10]. Sessions consume IPs the way a connection pool consumes sockets, monuminu writes ^[13]. So the sizing input is peak concurrent sessions. Those 32 addresses are shared with a data proxy that scales out under load ^[2].

The two request paths differ in where they begin consuming subnet addresses. A hosted agent call runs Client to Foundry endpoint to Micro VM (/invoke) to Tools Service to Data Proxy to customer resources via private endpoint ^[11]. A prompt agent call skips the Micro VM: Client to Foundry endpoint to Tools Service to Data Proxy to customer resources ^[12]. Both terminate at the data proxy, and the data proxy sits in your delegated subnet, so prompt agents draw on the same block even though they never occupy a Micro VM ^[16]. The Foundry endpoint your SDK talks to, the Micro VM host layer and the Tools Service are all on Microsoft's side of the boundary ^[9].

The failure signatures are unequal in how much they tell you. Session creation returns HTTP 429 with subnet_exhausted, which names the cause in the error code ^[3]. The data proxy's errors are described only as intermittent 5xx under load ^[4]. "There's no portal dashboard telling you why. There's no alert," monuminu writes ^[6]. The article's diagnosis path is grepping Application Insights traces to work out why an agent is failing on what looks like a networking problem ^[7]. The earliest available signal is a string in a trace, so any alert on exhaustion is one the customer writes.

Enterprises end up here because of a compliance mandate: according to the article, agent traffic has to stay inside customer-managed network boundaries. Microsoft's answer is a Standard Setup that injects the agent compute plane into a subnet you own alongside bring-your-own Storage, Cosmos DB and Azure AI Search ^[19][8]. monuminu's advice is to do the IP math before approving the subnet size. The platform shows almost no utilization until something breaks, and no live graph will help later ^[14]. The article does not say whether a delegated subnet can be widened once Micro VMs are running in it. The evidence supports this much: you size it without telemetry and learn the answer from an outage.

For anyone tempted to borrow the number, the /27 that fell over is a claim about one deployment's concurrency. It transfers only if your peak concurrent hosted agent sessions, your number of projects sharing the account and your data proxy's scale-out behaviour all match. The article's outline lists a section called "Sizing the Subnet: The IP-to-Session Math" and another called "Managed VNet: The Alternative Nobody Mentions First" ^[15].