Adding Multi-Region Network Deployment

docs/wiki/Deploying-ALZ-HubAndSpoke.md

@@ -74,12 +74,39 @@ Depending on your requirements, you may choose to deploy additional network infr
 
  ![img](./media/clip_image036b.png)
 
+### Deploying networking resources in an additional region
+
+You may also deploy your Azure landing zone networking resources to an additional region, to allow you to prepare for multi-region operations.
+
+To do so, select either "Hub and spoke with Azure Firewall" or "Hub and spoke with your own third-party NVA" in the Extend your network into a second region option.  For this example, we will select the "Hub and spoke with Azure Firewall".
+
+![img](./media/clip_image080.png)
+
+You will need to specify the additional region to deploy to, and then you will be given the option to repeat many of the decisions above.  For best results, use similar inputs to make sure that your regional deployments can both support the same architecture.  However, if you want to forgo deploying a gateway or firewall in the second region, you can select the appropriate options.
+
+Once deployed, your regional hubs will be peered together and have routing tables assigned to the firewall subnets to handle routing to each other.  You can add routes to this route table later, as you add spoke networks.  If you have deployed DDoS protection in the primary region, it will be applied to the secondary region as well.
+
+![img](./media/clip_image081.png)
+
+One area where the deployment may differ between regions is with private DNS zones.
+
+![img](./media/clip_image082.png)
+
+If you choose to deploy zones for both regions, you will receive two sets of the DNS zones, each one linked to the appropriate region's hub.  Each hub will resolve to a different DNS zone, allowing for private endpoints in different regions to be associated to the same resource.
+
+However, if you choose to deploy zones only for the primary region, then the private DNS zones will be linked to both hub virtual networks.  Only one host name per resource will be able to be used, preventing you from having multiple private endpoints for a service.
+
+See [Private Link and DNS integration at scale](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/azure-best-practices/private-link-and-dns-integration-at-scale) to help determine the right architecture for you.
 
 ## 8. Identity
-On the *Identity* blade you can specify if you want to assign recommended policies to govern identity and domain controllers. If you decide to enable this feature, you do need to provide an empty subscription for this. You can then select which policies you want to get assigned, and you will need to provide the address space for the virtual network that will be deployed on this subscription. Please note that this virtual network will be connected to the hub virtual network via VNet peering. 
+On the *Identity* blade you can specify if you want to assign recommended policies to govern identity and domain controllers. If you decide to enable this feature, you do need to provide an empty subscription for this. You can then select which policies you want to get assigned, and you will need to provide the address space for the virtual network that will be deployed on this subscription. Please note that this virtual network will be connected to the hub virtual network via VNet peering.
 
  ![img](./media/clip_image036c.png)
 
+In addition, if you wish to deploy an additional virtual network in a secondary region, if you are deploying network resources in the secondary region.
+
+![img](./media/clip_image085.png)
+
 ## 9. Landing zone configuration
 
 In the top section you can select which policies you want to assign broadly to all of your application landing zones. You also have the ability to set policies to *Audit only* which will assign the policies for Audit.

docs/wiki/Deploying-ALZ-VWAN.md

@@ -69,12 +69,38 @@ Depending on your requirements, you may choose to deploy additional network infr
 
 ![vwan](./media/clip_image078.jpg)
 
+### Deploying networking resources in an additional region
+
+You may also deploy an additional virtual hub in an additional region, to prepare for multi-region operations.
+
+To do so, select "Additional virtual WAN hub" in the Extend your network into a second region option.
+
+![img](./media/clip_image080.png)
+
+You will need to specify the additional region to deploy to, and then you will be given the option to repeat many of the decisions above.  For best results, use similar inputs to make sure that your regional deployments can both support the same architecture.  However, if you want to forgo deploying a gateway or firewall in the second region, you can select the appropriate options.
+
+![img](./media/clip_image084.png)
+
+One area where the deployment may differ between regions is with private DNS zones.
+
+![img](./media/clip_image082.png)
+
+If you choose to deploy zones for both regions, you will receive two sets of the DNS zones.  This allows for private endpoints in different regions to be associated to the same resource.
+
+However, if you choose to deploy zones only for the primary region, then you will only have one set of private DNS zones.  Only one host name per resource will be able to be used, preventing you from having multiple private endpoints for a service.
+
+See [Private Link and DNS integration at scale](https://learn.microsoft.com/azure/cloud-adoption-framework/ready/azure-best-practices/private-link-and-dns-integration-at-scale) to help determine the right architecture for you.
+
 ## 8. Identity
 
 On the *Identity* blade you can specify if you want to assign recommended policies to govern identity and domain controllers. If you decide to enable this feature, you do need to provide an empty subscription for this. You can then select which policies you want to get assigned, and you will need to provide the address space for the virtual network that will be deployed on this subscription. Please note that this virtual network will be connected to the hub virtual network via VNet peering.
 
  ![img](./media/clip_image036c.png)
 
+In addition, if you wish to deploy an additional virtual network in a secondary region, if you are deploying network resources in the secondary region.
+
+![img](./media/clip_image085.png)
+
 ## 9. Landing zone configuration
 
 In the top section you can select which policies you want to assign broadly to all of your application landing zones. You also have the ability to set policies to *Audit only* which will assign the policies for Audit.

docs/wiki/Whats-new.md

@@ -44,6 +44,22 @@ Here's what's changed in Enterprise Scale/Azure Landing Zones:
 
 ### April 2024
 
+#### Documentation
+
+- Added new instructions for deploying hub and spoke network topology in [multiple regions](./Deploying-ALZ-HubAndSpoke#deploying-networking-resources-in-an-additional-region).
+- Added new instructions for deploying additional vWAN hubs in [multiple regions](./Deploying-ALZ-HubAndSpoke#deploying-networking-resources-in-an-additional-region).
+
+#### Tooling
+
+- Added functionality to deploy platform resources into multiple regions.  
+  - **New deployments will now:**
+    - Allow for the deployment of hub virtual networks into a secondary region.  Hub virtual networks will be peered together, and if DDoS protection is enabled, it will be applied to the secondary region.
+    - Allow for the deployment of a virtual WAN hub into a secondary region.
+    - Allow for the deployment of Private DNS Zones for multiple regions.
+    - Allow for Private DNS zones in the primary region to be linked to the secondary region.
+    - Allow for the deployment of VPN Gateways and ExpressRoute Gateways in both regions.
+    - Allow for the deployment of Azure Firewall in both regions.  Azure Firewall subnets will have a route table to forward traffic intended for the other hub to the Firewall in the other region.
+    - Allow for the deployment of Identity virtual networks in both regions, peered to the appropriate hub.
 #### Tooling
 
 - Add additional, optional, telemetry to help the ALZ team identify styles of deployments.