leijgao · Oct 28, 2026 · Oct 28, 2026
@@ -172,6 +172,10 @@ CIDRs, BYO storage model, deploying identity, the policy set, and mandatory
 `rbac.humanAccessMode` (`permanent-role-assignments` or `customer-jit-managed`). The JIT mode also
 requires `rbac.jitEligibilityDurationDays` as a whole number from 7 through 3650.
 
+The control-plane region is independent of the workload region. The VNet/subnets and all
+resources in the managed resource groups (MRGs) must share `workloadRegion`. Stage 1 validates
+an existing VNet against that region; Stage 4 checks deployment subnet regions before submission.
+
 FR1.2 [P0] Embedded subnet-sizing validation. Validate each Discovery subnet against the
 required prefix and confirm all fit inside the provided VNet without overlap:
 

@@ -49,10 +49,12 @@
       ]
     },
     "controlPlaneRegion": {
-      "type": "string"
+      "type": "string",
+      "description": "Region for Discovery control-plane resources. Can differ from workloadRegion."
     },
     "workloadRegion": {
-      "type": "string"
+      "type": "string",
+      "description": "Region for the VNet/subnets and all managed-resource-group resources."
     },
     "systemSku": {
       "type": "string",

@@ -37,6 +37,10 @@ Confirm the subscription is allowlisted for Discovery, record the RP-registratio
 
 ### capture_fields — FR1.1
 Capture and normalize control-plane region, workload region, VNet CIDR, per-service subnet CIDRs, BYO storage model, deploying identity, and policy set. Normalize regions to Azure short names and CIDRs to canonical form; flag any required field left blank.
+
+For `byo-existing`, validate the existing VNet against `workloadRegion`, not `controlPlaneRegion`.
+The VNet/subnets and all managed-resource-group resources must share the workload region;
+the Discovery control-plane resources can use a different region.
 - Missing field: complete the corresponding cell in the planning sheet.
 
 ### project_storage — FR1.1

@@ -59,9 +59,9 @@ to activate the role. Eligible-but-inactive does not fail the completed deployme
 principals and managed identities keep standard assignments. Other assignment failures are Warn.
 The workspace `publicNetworkAccess` comes from `workspace.publicNetworkAccess` (default `Enabled`) and is applied on the bicep deploy, the direct workspace PUT, and the recovery re-PUT.
 The immutable `NetworkIsolation` tag comes from `workspace.networkIsolation` (default `true`) and is applied by both Bicep and direct workspace deployment.
-Region co-location (pre-flight): the supercomputer `location` (from `controlPlaneRegion`) must equal the region of the BYO VNet that holds the managedcluster/nodepool subnets. Discovery validates the node pool `SubnetId` against the supercomputer's primary region, and `discovery.overridemrgregion` (workloadRegion) does not relax that check. The chosen region must also be a Discovery-creatable region: creation is rejected in some regions (e.g. eastus2 returns "Creation of new Supercomputer resources is not supported in region") even though the ARM provider location list advertises them; eastus is confirmed creatable. So the BYO VNet must live in a creatable region. The script resolves the VNet region from the subnet id and fails fast with a RegionMismatch remediation before the PUT. Region is immutable, so a mismatch requires setting `controlPlaneRegion` to a creatable VNet region, deleting the failed supercomputer, and re-running (a plain re-PUT cannot move it).
-- RegionMismatch on SubnetId: set controlPlaneRegion = the managedcluster/nodepool VNet region (which must itself be a Discovery-creatable region); delete the failed supercomputer and re-run.
-- Creation not supported in region: the region is not Discovery-creatable for this resource type; place the BYO VNet and set controlPlaneRegion to a creatable region (eastus confirmed; eastus2 rejected despite being advertised).
+Region alignment (pre-flight): Discovery resource `location` comes from `controlPlaneRegion` and can differ from the VNet region. All resources in the managed resource groups must share `workloadRegion`, set by `discovery.overridemrgregion` on the supercomputer and workspace. The script resolves each deployment subnet's VNet region and checks it against `workloadRegion` before either Bicep or ARM submission. An unreadable VNet or a mismatch returns `deploy-network-region` and stops deployment.
+- RegionMismatch on SubnetId: set `workloadRegion` to the VNet/subnet region, or use subnets in `workloadRegion`. Existing managed resources may need to be recreated to change region.
+- Creation not supported in region: select a Discovery-creatable `controlPlaneRegion` for the affected resource type. This does not require moving the VNet or changing `workloadRegion`.
 
 ### true_state_detection — FR4.3
 Allow 15-30 minutes for the supercomputer and up to about an hour for the workspace; plan one to two hours overall. Deployment/recovery callers use a 120-minute resource-state polling timeout per resource; this is not a guaranteed completion time.
@@ -73,8 +73,8 @@ Catch the case where the ARM resource list shows Succeeded while a Foundry accou
 ### error_remediation_engine — FR4.4
 Match the ARM error signature and emit the specific remediation:
 - `InsufficientQuota` (Tokens Per Minute) on a managed-RG model deployment → not enough free gpt-5.4 GlobalStandard TPM in the workload region (workspace needs 250K, the chat model 200K) → free or request quota, then re-run (Stage 1 `model-quota` catches this up front).
-- `Creation of new X resources is not supported in region` → the target region is not Discovery-creatable for that resource type (ARM advertises more locations than the service allows) → deploy into a creatable region (eastus confirmed; eastus2 rejected) and place the BYO VNet there so the supercomputer stays co-regional with its node pool subnet.
-- `RegionMismatch` on supercomputer/nodePool `SubnetId` → supercomputer location differs from the BYO VNet/subnet region → set controlPlaneRegion to the VNet region so the supercomputer is co-regional with its subnets, delete the failed supercomputer, and re-run (region is immutable).
+- `Creation of new X resources is not supported in region` → the target control-plane region is not Discovery-creatable for that resource type → select a supported `controlPlaneRegion`; keep the VNet and MRG resources aligned in `workloadRegion`.
+- `RegionMismatch` on supercomputer/nodePool `SubnetId` → the MRG workload region differs from the VNet/subnet region → align `workloadRegion` and the VNet; `controlPlaneRegion` can differ.
 - `AKSCapacityHeavyUsage` / `InternalServerError` on AKS create → region capacity for API Server VNet Integration → retry, or deploy workload in a region with capacity and global-peer to the firewall.
 - Repeated `AZFWApplicationRule` deny on packages.microsoft.com → firewall source scoped to the wrong CIDR → add the real spoke CIDR and allow the bootstrap FQDNs.
 - 409 `FlagMustBeSetForRestore` → Foundry account soft-deleted then recreated → set Restore=true, or purge and wait before re-PUT.

@@ -247,11 +247,11 @@ Notes next to each field explain what to enter. A few that trip people up:
 | `network.model` | Choose one of the options described above. Only `byo-existing` skips Stage 2 network-template provisioning. |
 | `network.networkResourceGroup` | The resource group holding the existing VNet for `byo-existing`, or the target group for tool-provisioned networking. Stage 2 creates/uses the target network group for provisioning models. |
 | `network.dnsResourceGroup` | Resource group containing the private DNS zones linked to the Discovery VNet. Leave it blank when DNS zones live in `network.networkResourceGroup`; specify it for centralized DNS in another resource group. Stage 2 creates/reuses the required zones and exact VNet links there and includes this RG in its RBAC targets. |
-| `network.vnetName` | For `byo-existing`, enter the existing VNet name (Stage 1 checks it exists and is in `controlPlaneRegion`). For `managed`, `byo` or `byo-spoke`, enter the VNet name to deploy; blank defaults to `vnet-<names.workspace>`. |
+| `network.vnetName` | For `byo-existing`, enter the existing VNet name (Stage 1 checks it exists and is in `workloadRegion`). For `managed`, `byo` or `byo-spoke`, enter the VNet name to deploy; blank defaults to `vnet-<names.workspace>`. |
 | `network.existingSubnets` | BYO form: list existing subnet CIDRs outside the planned Discovery subnets so address planning can check for overlaps. This field does not make a provisioning model preserve unlisted subnets. |
 | `network.outboundType` | Select `UserDefinedRouting` for customer firewall/NVA egress, or `LoadBalancer` for AKS load-balancer-based egress. |
 | `network.nvaNextHop` | For UDR, enter the actual firewall/NVA private IP. It is not a NAT Gateway public IP. Not required for `LoadBalancer`. |
-| `controlPlaneRegion` / `workloadRegion` | Use a supported production region: **East US**, **Sweden Central**, or **UK South**. Keep resources for one deployment in the same region unless an approved architecture requires otherwise. |
+| `controlPlaneRegion` / `workloadRegion` | Use a supported production region: **East US**, **Sweden Central**, or **UK South**. `controlPlaneRegion` places the Discovery control-plane resources and can differ from `workloadRegion`. The VNet/subnets and all resources in the managed resource groups (MRGs) must be in `workloadRegion`. |
 | `names.*` | The resource names (workspace, project, supercomputer, node pool, etc.). Keep them unique in the subscription. |
 | `storage.account` | Required for every project, independently of Bookshelf. The name of the storage account you pre-created (prerequisite 8); keep `storage.model=byo`. Stage 1 fails if the account doesn't exist. Stage 2 adds the Blob CORS rules and private endpoint. The account denies public network traffic, so users who open project outputs in Discovery Studio need network access to it: from the VNet (VPN or ExpressRoute), or through a client IP rule you add. |
 | `workspace.publicNetworkAccess` | `Enabled` (default) or `Disabled`. With `Disabled`, the workspace data plane (agents, investigations, conversations) answers only from inside the VNet, so Stage 5 must run from a runner with private network access. |
@@ -260,8 +260,8 @@ Notes next to each field explain what to enter. A few that trip people up:
 Notes:
 - **Policies are collected live** from the subscription at runtime — you do not list deny/audit
   policies in the form. Add a `POLICY` row only to declare or override one.
-- For **`byo-existing`**, `controlPlaneRegion` must equal the region of the existing VNet that holds
-  the `managedcluster` / `nodepool` subnets.
+- For **`byo-existing`**, `workloadRegion` must equal the existing VNet region.
+  `controlPlaneRegion` does not need to match it.
 - For **`byo-existing`**, Stage 2 skips the VNet/network-template deployment. Before Stage 3, make sure that:
   - Each SUBNET row's CIDR matches an existing subnet. Stage 1 maps rows to subnet names by CIDR
     and fails `byo-subnets` on a mismatch.

@@ -714,10 +714,10 @@ function Invoke-Stage1Checks {
             $existing = Get-AzJson -Args @('network', 'vnet', 'show', '-g', $byoRg, '-n', $byoVnet, '--subscription', $Cfg.subscriptionId) -AllowFail
             if ($existing) {
                 $loc = [string]$existing.location
-                $status = if ($loc -and $Cfg.controlPlaneRegion -and $loc -ne $Cfg.controlPlaneRegion) { 'Fail' } else { 'Pass' }
+                $status = if ($loc -and $Cfg.workloadRegion -and $loc -ne $Cfg.workloadRegion) { 'Fail' } else { 'Pass' }
                 $R.Add((New-CheckResult -Id 'byo-vnet' -Name 'Existing VNet (byo-existing)' -Status $status -Fr 'FR1.2' `
                             -Detail "VNet '$byoVnet' found in '$byoRg' (location=$loc, address space=$(@($existing.addressSpace.addressPrefixes) -join ','))." `
-                            -Remediation ($status -eq 'Fail' ? "Set controlPlaneRegion/workloadRegion to '$loc' (the VNet's region) or use a VNet in '$($Cfg.controlPlaneRegion)'." : '') `
+                            -Remediation ($status -eq 'Fail' ? "Set workloadRegion to '$loc' (the VNet's region) or use a VNet in '$($Cfg.workloadRegion)'. controlPlaneRegion can differ." : '') `
                             -Data @{ vnetId = $existing.id; location = $loc }))
                 # Customer subnets keep their own names; later stages default to snet-<role>, so
                 # record each existing subnet's real name, matched by the planned CIDR.

@@ -6,10 +6,10 @@
 
 targetScope = 'resourceGroup'
 
-@description('Region for all Discovery resources. Must equal the BYO VNet/subnet region.')
+@description('Control-plane region for Discovery resources. Can differ from the VNet/subnet and managed-resource-group region.')
 param location string
 
-@description('workloadRegion tag (discovery.overridemrgregion) for the managed RGs.')
+@description('Region for all managed-resource-group resources, set through discovery.overridemrgregion. Must match the VNet/subnet region.')
 param workloadRegion string = location
 
 param supercomputerName string

@@ -4,22 +4,22 @@
   "metadata": {
     "_generator": {
       "name": "bicep",
-      "version": "0.41.2.15936",
-      "templateHash": "3453505155457192370"
+      "version": "0.39.26.7824",
+      "templateHash": "12946762802184486479"
     }
   },
   "parameters": {
     "location": {
       "type": "string",
       "metadata": {
-        "description": "Region for all Discovery resources. Must equal the BYO VNet/subnet region."
+        "description": "Control-plane region for Discovery resources. Can differ from the VNet/subnet and managed-resource-group region."
       }
     },
     "workloadRegion": {
       "type": "string",
       "defaultValue": "[parameters('location')]",
       "metadata": {
-        "description": "workloadRegion tag (discovery.overridemrgregion) for the managed RGs."
+        "description": "Region for all managed-resource-group resources, set through discovery.overridemrgregion. Must match the VNet/subnet region."
       }
     },
     "supercomputerName": {