updating FAQ for virtual networks

Author: aahill

articles/ai-foundry/agents/faq.yml

@@ -8,9 +8,10 @@ metadata:
   ms.service: azure-ai-foundry
   ms.subservice: azure-ai-foundry-agent-service
   ms.topic: faq
-  ms.date: 10/09/2025
+  ms.date: 10/20/2025
   ms.author: aahi
   author: aahill
+  ms.custom: references_regions
 title: Azure AI Foundry Agent Service frequently asked questions
 summary: |
   If you can't find answers to your questions in this document, and still need help check the [Azure AI services support options guide](../../ai-services/cognitive-services-support-options.md). Azure AI Foundry Agent Service is part of Azure AI services.
@@ -55,4 +56,56 @@ sections:
       - question: |
           Is there any additional pricing or quota for using Foundry Agent Service? 
         answer: |
-          No. All [quotas](quotas-limits.md) apply to using models with Foundry Agent Service.
+          No. All [quotas](quotas-limits.md) apply to using models with Foundry Agent Service.
+  - name: Virtual networking
+    questions:
+      - question: |
+          What does 'bring your own virtual network' mean? 
+        answer: |
+          Virtual networks secure the inbound and outbound access of your Azure resources, preventing bad actors from accessing your resources. Network isolation is achieved through virtual network integrations in Azure. This is a fundamental requirement for security in enterprises. To learn more about virtual network isolation, see [Virtual network integration of Azure services for network isolation](/azure/virtual-network/vnet-integration-for-azure-services) and [What is Azure Virtual Network?](/azure/virtual-network/virtual-networks-overview)
+      - question: |
+          Why is subnet delegation needed? 
+        answer: |
+          Both the Agent client and its' compute run on Azure Container Apps (ACA). When you run the Agent client and its compute on Azure Container Apps (ACA) inside an existing virtual network, you must supply a dedicated subnet delegated to `Microsoft.App/environments`.
+          1. Delegation pins them to the right subnet. It tells Azure exactly where to “inject” the Agent client so ACA can create its network interfaces there.   
+          2. ACA then applies the needed plumbing - IP addresses, routing, NSGs, and service-managed identity wiring, is configured automatically.   
+          3. Without the delegation, ACA refuses to deploy, so neither the Agent client nor the compute layer could join your VNet, breaking isolation and compliance requirements.   
+          In short, delegating the subnet is the prerequisite that lets ACA, and therefore your Agent runtime, live inside your private network with the correct security and routing policies in place and in your control. 
+      - question: |
+          What regions are supported for Class A? 
+        answer: | 
+          Supported regions: West US, East US, East US 2, Japan East, France Central, UAE North, South Central US, Italy North, Germany West Central, Brazil South, South Africa North, Australia East, Sweden Central, Canada East, West Europe, Spain Central, UK South 
+      - question: |
+          What class range is supported? Public or Private Class A, B, C Subnets? 
+        answer: |
+          Only private class A, B, and C ranges are supported. No public class ranges are supported.  
+      - question: |
+          What is the minimum size for the agent subnet? How many IPs should we use initially and how many IPs should be used for each Agent?
+        answer: |
+          The recommended subnet size is /24 (256 address) and is what we default to in our templates. The minimum subnet size is /27 (32 addresses). The reason why /24 is recommended is because of the runtime impact in the event of a container update, listed in the ACA documentation. For more information, see [Configuring virtual networks Azure Container Apps environments](/azure/container-apps/custom-virtual-networks?tabs=workload-profiles-env#subnet). 
+
+          We set an IP range per Azure AI Foundry account. Each project gets an IP from the range. There is not IP address set per Agent, but per project. This means there is no limit to the number of agents to create within your project. The user is not limited by the minimum address space of the subnet to create any number of agents. 
+      - question: |
+          What is the minimum and recommended virtual network address range for the Agent service? 
+        answer: |
+          As long as there is address space for Agent subnet and private endpoints, then virtual network address range can be anything. 
+      - question: |
+          Can I use peered VNETs? Can I have an AI search in one virtual network, CosmosDB in another virtual network, Foundry and Agents in another virtual network?   
+        answer: |
+          Yes this is feasibly possible since the virtual network is in the your subscription, and you  should be able to peer with any virtual network. But data transfer is quite costly so it is not recommended to do this. The requirement is all resources must be in the same region as the Foundry resource.  
+      - question: |
+          Do I need to whitelist any FQDNs if I am using an Azure firewall? 
+        answer: |
+          Yes, allowlist the Fully Qualified Domain Names (FQDNs) listed **Managed Identity in the [Use Azure Firewall with Azure Container Apps](/azure/container-apps/use-azure-firewall) article or add the service tag `AzureActiveDirectory`. Verify no TLS inspection happens in the firewall that could be adding a self-signed certificate. During failures, inspect if there is any traffic landing on the firewall and what traffic is being blocked by the firewall.  
+      - question: 
+          Can the virtual network be re-used by multiple Azure AI Foundry resources? 
+        answer: |
+          Yes, a virtual network can be re-used by multiple Foundry resources, but the Agent runtime subnet is per Foundry account.
+      - question: |
+          Does the virtual network need to be in the same resource group as Foundry?
+        answer: |
+          No, the same resource group is not needed, but the same region is required.
+      - question: |
+          What additional configuration is needed if I want to add tools to my agents? 
+        answer: |
+          The template provides support for the built-in tools: Code Interpreter, File Search, Azure AI Search, Cosmos DB (all tools that use the Bring-Your-Own (BYO) resource connections). To configure tools that require the creation of a new connection, you must create a private endpoint from your `peSubnet`` and create a private link from the Azure Resource.