Standalone network reference

A standalone foundation manages its own workload network rather than relying on a shared hub. With isolation enabled it can include local private DNS, private endpoints, firewall, Bastion and a jumpbox. For shared network services, use the hub-and-spoke design.

Execute Deploy infrastructure only from the Agent Landing Zone repository root. Execute Deploy the full stack when the Agent application is required. This page is the network reference for those procedures, not a third deployment path.

Ownership and scope

The workload team owns resources, backups and cost in its dedicated group. The network/security owners approve addresses, egress and public exceptions. Confirm regional capacity, resource-provider registration and scoped deployment permissions before provisioning.

Agent Landing Zone owns the Bicep foundation under infra/bicep/ and runs it through platform lifecycle hooks. Do not use a separate foundation checkout. The inventory and cost estimates describe foundation building blocks; selected application resources can differ.

Address planning

Reserve a VNet range that does not overlap other VNets, VPN/on-premises ranges or future hub connections. The native foundation default VNet is 192.168.0.0/21. Changing only that prefix does not change the individual subnet prefixes.

The following is a complete illustrative allocation, not a universally safe range. Replace it as a unit if it conflicts with your approved design.

Native parameter	Example allocation
`vnetAddressPrefixes`	`["10.200.0.0/21"]`
`agentSubnetPrefix`	`10.200.0.0/24`
`acaEnvironmentSubnetPrefix`	`10.200.6.0/23`
`peSubnetPrefix`	`10.200.2.0/26`
`azureBastionSubnetPrefix`	`10.200.2.64/26`
`azureFirewallSubnetPrefix`	`10.200.2.128/26`
`gatewaySubnetPrefix`	`10.200.2.192/26`
`azureAppGatewaySubnetPrefix`	`10.200.3.0/27`
`jumpboxSubnetPrefix`	`10.200.3.64/27`
`devopsBuildAgentsSubnetPrefix`	`10.200.3.96/27`
`applicationPeSubnetPrefix`	`10.200.3.128/26`
`powerPlatformSubnetPrefix`	`10.200.4.0/24`
`aiGatewaySubnetPrefix`	`10.200.5.0/24`

Set vnetAddressPrefixes as an explicit array in reviewed root main.parameters.json; there is no VNET_ADDRESS_PREFIXES mapping. All twelve subnet names and prefixes also have environment bindings in that root file. A reused VNet's actual address space is authoritative and is not resized by these inputs. Keep the complete file with the deployment inputs and carry it to a connected host. Environment refresh does not restore file customizations.

Every subnet must fit without overlap. Keep AzureBastionSubnet and AzureFirewallSubnet at least /26. Reserve private-endpoint capacity and growth. The workload-profile Container Apps environment example uses the recommended /23; current preflight enforces /27 minimum and warns below the recommendation. That minimum is not a future-scale guarantee.

Private network choices

Input	Private standalone intent
`DEPLOYMENT_MODE`	`standalone`; records intent, not a replacement for explicit flags
`NETWORK_ISOLATION`	`true`
`DEPLOY_AZURE_FIREWALL`	`true` for local inspected egress
`DEPLOY_JUMPBOX`, `DEPLOY_BASTION`, `DEPLOY_NAT_GATEWAY`	Independently selected; the canonical guide shows the self-contained choice
`BASTION_SKU_NAME`, `BASTION_ENABLE_TUNNELING`	Standard/Premium with tunneling for native RDP
`DEPLOY_ACR_TASK_AGENT_POOL`	The Agent platform selects a pool for private remote builds. Review the build-mode contract before overriding

The NAT gateway supports its configured subnet; it is not a firewall or a substitute for reviewing effective routes. Inspect the local firewall route and required destinations in the outbound-access reference and foundation firewall source. Agent platform build egress also includes its own dependency-specific inputs. An ACR Tasks pool does not make the deployment host VNet-connected.

With empty native allowedIpRanges, private service endpoints are the intended path. A nonempty approved list can enable IP-restricted public access. Storage trusted-service/resource-instance exceptions and Shared Key access remain independent controls; see Storage controls. Optional Application Gateway ingress is a separate, explicitly reviewed public entry point.

Existing VNet and DNS ownership

With USE_EXISTING_VNET=true, decide who manages each subnet, NSG, route table and delegation. All twelve subnets are selected by default for both new and existing VNets; use the individual creation flags to select ownership per subnet. A false creation flag requires an existing valid subnet for each enabled consumer, or that consumer must be disabled. Do not update selected existing subnets under isolation with native root deployNsgs=false; retain managed NSGs or use DEPLOY_SUBNETS=false and have the network owner prepare the complete subnet configuration.

Choose local DNS, per-zone BYO IDs or Azure Policy-managed DNS deliberately. Shared zones require links or forwarding for every actual client VNet; peering alone does not propagate zone links. Avoid duplicate authoritative zones. See private DNS parameters and Policy ownership.

The BYO-VNet reserved AzureBastionSubnet is excluded from generic NSG attachment when Bastion is disabled; enabled Bastion uses its dedicated compliant NSG. The reserved GatewaySubnet at default 192.168.2.192/26 must have no NSG, default-route UDR or delegation. Do not rename subnets, renumber prefixes or reapply an older workaround automatically on existing deployments. Plan such migrations explicitly.

Provisioning boundary

Return to preview and provision after the network inputs are approved. Preflight validates parameters and regional readiness, not successful bootstrap or data-plane access. Inspect the VM Custom Script Extension result if software bootstrap is selected; it is not evidence that all Agent prerequisites are installed.

For a new build subnet created in a BYO VNet, the ACR Tasks pool depends on the conditional subnet deployment. With DEPLOY_SUBNETS=false or DEPLOY_DEVOPS_BUILD_AGENTS_SUBNET=false, subnet readiness is the external network owner's responsibility for an enabled pool. A first-attempt cold-start check must start with that subnet absent, record successful operations and the pool's final state, and distinguish retries from the first attempt. Source availability and offline CI do not prove this live result.

Verify private connectivity

Inspect the actual endpoint names and approvals in the selected resource group:

az containerapp list -g <resource-group> \
  --query "[].{name:name,fqdn:properties.configuration.ingress.fqdn}" -o table
az network private-endpoint list -g <resource-group> \
  --query "[].{name:name,state:provisioningState,connections:privateLinkServiceConnections[].privateLinkServiceConnectionState.status}" -o json

From the actual connected Windows host, repeat these checks for the app, Search, Storage, App Configuration and registry hostnames:

Resolve-DnsName -Name <service-hostname> -Type A
Test-NetConnection -ComputerName <service-hostname> -Port 443

Expect private answers matching the intended endpoint NICs and successful TCP connections. Test HTTPS with normal certificate validation and the intended authorized identity. A 401/403 can show an endpoint responds, but is not a successful data-access authorization test. Confirm telemetry reaches the intended workspace.

For a placeholder app, an HTTPS 200 from inside the network is a runtime/network smoke test only. Agent acceptance also requires sign-in, agent/tool execution and positive/negative document-access tests. An unconnected workstation must not serve a private app or read private data; public DNS outside the VNet alone does not establish exposure.

Use the portal's Bastion connection or approved VPN for interactive access. Native Bastion RDP requires a supported Windows client, Standard/Premium SKU and tunneling. Use the provisioned VM credential or an authorized portal reset (default username testvmuser); never put passwords in command history or add a public VM IP as a shortcut.

Recovery and retirement

Inspect failed deployment operations, system logs and firewall denies. Correct the specific quota, Policy, DNS, route, egress or role failure; preserve the same approved inputs on retry. Do not disable isolation, purge a partially deployed group or move existing resources to another region as generic recovery.

Use infrastructure change review and safe removal. If this environment later adopted a hub, preserve shared services and retire only its own attachments with their owners.