Moving a Virtual Network (VNet) from one Azure subscription to another is a common requirement during subscription restructuring, consolidations, or billing changes. Thankfully, Azure provides a built-in service to facilitate this: Azure Resource Mover.

Use Azure Resource Mover

Azure Resource Mover enables you to move supported resources — including VNets — between regions or subscriptions.

Pre-Move Checklist:

• Unpeer the VNet: If your VNet is peered with other VNets, you must delete all peering connections before the move. Peering links are not transferable across subscriptions.
• Check dependencies: Ensure dependent resources (e.g., VMs, NICs, NSGs, route tables) are either moved along with the VNet or detached beforehand.
• Permissions: You need appropriate permissions (Owner or Contributor) in both the source and target subscriptions.

Steps to Move a VNet:

1. Navigate to Azure Resource Mover in the portal.
2. Select your source subscription and region.
3. Choose the VNet you want to move.
4. Review dependencies and select additional resources to include in the move.
5. Choose the target subscription and resource group.
6. Initiate the move by selecting “Start Move”.

Post-Move Considerations:

• Recreate VNet peering in the new subscription if needed.
• Update references in other resources (e.g., firewalls, service endpoints).
• Double-check NSGs and route tables for any issues post-migration.

Pro Tip:

Always test the move in a non-production environment first, especially if your VNet is part of a complex topology. Azure will perform a validation check, but manual review is wise.

The post How to Move an Azure VNet Between Subscriptions appeared first on Azure Security Architect.

Once you set it up this way (Gateway Subnet, Firewall Subnet, and Hub Subnet A), then, all traffic anyway goes through the Gateway-VPN-Subnet.

ROUTING so that ALL TRAFFIC goes through the Firewall?

1. All you have to do is attach a ROUTE (ROUTE-FW) with the NEXT HOP as the Firewall Subnet to the Gateway Subnet.
2. And you have another Route for Subnet B – one that also has the next hop as the Gateway Subnet  AND disables BGP routing.
3. This will ensure that traffic from Subnet B (which is a spoke PEERED with the HUB), goes through the firewall. Also, traffic from Subnet A – also goes through the Firewall.

The post Azure Hub Spoke Best Practices appeared first on Azure Security Architect.