Change an existing FNN VPC to a configured routing profile with the opposite internal setting. Submit the destination routingProfile and optional exact vni; REST reads the current Core version internally and submits one change using that version. Core atomically changes the profile and active VNI, advances the version, and retains the old allocation. VPC identity, Instances, addresses, prefixes, NSGs, metadata, and the creation-time requested VNI are preserved.

Requires the same Infrastructure Provider ownership, registered Site, and PROVIDER_ADMIN authorization as routing-state inspection. Core also enforces the Tenant's permitted access tier; Provider authorization does not permit broader Tenant routing access. Named source and destination profiles, nonoverlapping internal and external pools, and VNIs in 1..16777215 are required. Site-global VNIs, substantive VPC or interface routing overrides, and tenant-managed SitePrefix attachments are unsupported. Every serving Core must support the requested operation, including exact VNI selection; response validation cannot undo a change made by an older Core that ignores the exact VNI.

REST makes no change if the initial read fails. A concurrent VPC update between the read and change returns 412 without rereading or retrying. Authorization, the read, and the change share one 50-second budget from handler entry within the HTTP request deadline. REST does not submit the change if its request context has expired before dispatch; a submitted workflow may outlive the caller. A timeout, lost response, or invalid acknowledgement after submission can leave a committed change; inspect the authoritative routing state before deciding on another request. Neither the mutation nor the full sequence is automatically retried. Each separate HTTP request is a new action, not a replay or deduplicated retry of a previous request.

A 200 response confirms the Core configuration transaction, not restored traffic. Prevent attachment, peering, deletion, and profile-definition changes until all attached and directly peered DPUs and fabric routes have been independently verified and the inactive allocation released. Neither REST nor Core enforces this hold or verifies convergence. Release is a separate operator action. A later change back must pass current validation; retaining the allocation does not guarantee reversal. External routing does not allocate public addresses or configure NAT, fabric routes, or NSGs.

{
  "routingProfile": "external"
}

{
  "vpcId": "497f6eca-6276-4993-bfeb-53cbbbba6f08",
  "version": "V2-T1789147200000000",
  "routingProfile": "external",
  "activeVni": 51000,
  "retainedAllocation": {
    "poolName": "vpc-vni",
    "vni": 12001
  }
}