If you work in a regulated environment, or you simply want tighter control of outbound traffic, this is a useful step. It gives you a cleaner path to private connectivity for evaluation runs, while still letting you use Foundry's hosted evaluation features.
The nice part is that Microsoft handles most of the plumbing. You still choose the isolation mode and approve access to the services you need, but you don't have to manage the underlying network estate yourself.
Managed virtual network creates a Microsoft-managed network boundary around the Foundry account. For evaluations, that means outbound traffic can stay inside a controlled path instead of falling back to broad internet access.
The service can use managed private endpoints to reach dependencies such as Azure Storage, Azure Cosmos DB, and Azure AI Search. Those private endpoints are managed by Microsoft, so you won't see customer-visible NICs appear in your own subscription.
Microsoft announced the launch here: Generally Available: Managed virtual network for evaluations in Microsoft Foundry. The main setup guide is here: Configure managed virtual network for Microsoft Foundry projects.
This matters most if you're running evaluation jobs against models or agents that touch private data, internal services, or tightly controlled storage accounts. It is also useful if your security team already expects private endpoints and approved egress paths for cloud services.
I think this will land well with platform teams who want Foundry evaluations but don't want the overhead of designing a full bring-your-own virtual network for every project. It is a bit like renting a secure room instead of building a new office block just to hold one meeting.
At a high level, you create the Foundry account with managed network injection enabled, assign the Foundry managed identity the right approval role, then choose the outbound mode for the managed network.
For teams that want the tightest egress control, allow_only_approved_outbound is the interesting option. In that mode, Foundry creates required outbound rules for core dependencies, including private endpoints for Storage, Cosmos DB, and AI Search, plus service tags for Azure Active Directory and Azure Machine Learning for the evaluations catalogue.
Here's a simple Azure CLI example based on the Microsoft docs:
az rest --method PUT \
--url "https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group}/providers/Microsoft.CognitiveServices/accounts/{account-name}?api-version=2026-03-01" \
--body '{
"location": "{region}",
"kind": "AIServices",
"sku": { "name": "S0" },
"identity": { "type": "SystemAssigned" },
"properties": {
"allowProjectManagement": true,
"customSubDomainName": "{account-name}",
"networkInjections": [
{
"scenario": "agent",
"subnetArmId": "",
"useMicrosoftManagedNetwork": true
}
]
}
}'
az cognitiveservices account managed-network create \
--resource-group {resource-group} \
--name {account-name} \
--managed-network allow_only_approved_outbound \
--firewall-sku Standard
After that, run your evaluations in the usual way with the Foundry SDK. The cloud evaluation guide is here if you want the Python workflow: Run evaluations in the cloud by using the Microsoft Foundry SDK.
If you prefer infrastructure as code, Microsoft has sample templates for both Bicep and Terraform.
There are a few catches worth knowing up front. The network injection settings must be present when you create the Foundry account. You can't bolt them on later.
The isolation modes are also not fully interchangeable. Once you configure allow_internet_outbound, you can't switch that resource back to disabled. If you configure allow_only_approved_outbound, you can't later change it to allow_internet_outbound.
If you add FQDN outbound rules, Foundry creates a managed Azure Firewall and you pay for it. Those FQDN rules only support ports 80 and 443. You also can't bring your own firewall to the managed network model.
One more practical point: if you send evaluation or trace data to Application Insights, you may need outbound FQDN rules for settings.sdk.monitor.azure.com, *.livediagnostics.monitor.azure.com, and *.in.applicationinsights.azure.com.
This is a solid update for anyone who wants to evaluate AI workloads in Foundry without leaving networking as an afterthought. You get a safer default, less network setup to own, and a clearer path to using evaluations in environments that care about private connectivity and controlled egress.
If I were already using Foundry evaluations and had been holding back because of network concerns, I would take another look now.
]]>For teams running large hub-and-spoke estates, or anyone segmenting traffic with lots of explicit routes and rules, this removes a common scaling pain. You can keep cleaner designs with fewer workarounds.
The new defaults are 2,000 rules per NSG, up to 6,000 addresses or ports in an NSG rule, 1,000 routes per route table, and 600 route tables per subscription by default.
This update increases baseline Virtual Network scale limits that many of us hit during growth phases. In plain terms, Azure now gives more room for security policy and routing logic before you need redesigns.
Microsoft announced this as generally available here: Azure Virtual Network updates, default limits increased for NSGs and route tables.
You can also validate the live platform limits in the official limits page: Azure networking limits.
If you manage enterprise landing zones, shared services VNets, or centralised inspection patterns, this one matters. These are the environments where NSG and UDR counts can grow quickly.
I also think this helps platform teams that support many app teams. It reduces the need to split resources purely to avoid old ceiling values.
Higher limits do not remove design trade-offs. Very large NSGs can still be harder to review, and giant route tables can still increase operational complexity.
I would still keep policy grouped by purpose, keep naming clear, and avoid overloading single objects just because the limit is higher.
Also remember that related services have their own constraints. Always check adjacent limits before you consolidate too aggressively.
This is a useful quality-of-life update for Azure networking. You get more default scale for NSGs and route tables, which gives you cleaner growth paths and fewer forced workarounds.
If you hit old limits in the past, this is a good time to revisit those designs and simplify where it makes sense.
]]>This matters when your hub-and-spoke estate gets large and your route table starts to look like a junk drawer. Fewer advertised prefixes can reduce operational noise and help you stay under ExpressRoute advertised prefix limits.
The update applies to Azure VPN Gateway and ExpressRoute Gateway scenarios where route advertisement scale and control are both pain points.
Azure added support for a virtual network property called summarizedGatewayPrefixes. You define one or more aggregated CIDR blocks on the gateway VNet, and Azure advertises those summaries to on-prem BGP peers.
By default, Azure advertises the hub address space plus peered spoke address spaces. With summarized prefixes configured, Azure advertises your summary list instead and suppresses covered spoke prefixes.
If you run hybrid networking with hub-and-spoke in Azure, this is for you. It is most useful when:
A few points are easy to miss:
Also remember the route-scale context: ExpressRoute private peering has limits on how many prefixes Azure can advertise to on-prem. This feature helps reduce that count, but you still need to design your address plan and summaries carefully.
This preview gives you a practical route-summarisation control point for Azure hybrid gateways. If you are battling advertised prefix scale in hub-and-spoke, this is a feature worth testing now.