Implemented dual Terraform scenarios for both traditional hub-and-spoke and virtual wan

[FreddyAyala]

Pull Request for Implementing Virtual WAN and Traditional Hub and Spoke Architectures

Overview/Summary

This Pull Request introduces infrastructure as code changes that successfully implement two distinct Azure network architectures: a traditional Hub and Spoke model and a comprehensive Virtual WAN setup. Key highlights include the integration of Azure Bastion for secure connectivity, the establishment of Firewall Policies for network security, and essential connectivity resources across both scenarios.

This PR fixes/adds/changes/removes

1. Adds Azure Virtual WAN configuration for automated global routing and branch connectivity.
2. Implements a traditional Hub and Spoke network topology utilizing hubnetworking and virtual_network_gateway modules.
3. Integrates Azure Firewall Policies to enforce standardized security across both Hub and Spoke and Virtual WAN topologies.
4. Configures Azure Bastion in both scenarios for secure, seamless RDP/SSH access without public IP exposure.
5. Deploys a Virtual Machine as a jumpbox for secure, centralized administrative access within the network.

Breaking Changes

None introduced.

Testing Evidence

The Terraform configuration files have been tested, yielding the following planned actions during deployment:

• Creation of an Azure Firewall Policy and rule collection group within the Virtual WAN to manage traffic securely.
• Updating existing network interfaces for compatibility with the new topology requirements.
• Creation of new subnets, including a dedicated subnet for Azure Bastion and another for shared services.
• Deployment of Azure Bastion host and its corresponding public IP to facilitate secure RDP/SSH access.
• Network changes related to the establishment of a Virtual Network Gateway to support VPN and ExpressRoute connections.

All planned changes have been executed using terraform apply, following the shown plan without errors. The successful deployment was verified through connectivity tests within both scenarios, confirming the intended network operations.

As part of this Pull Request I have

• [x] Checked for duplicate Pull Requests
• [x] Associated it with relevant issues, for tracking and closure.
• [x] Ensured my code/branch is up-to-date with the latest changes in the main branch
• [x] Performed testing and provided evidence through Terraform plan outputs and connectivity tests.
• [x] Updated relevant and associated documentation.

---

Terraform execution plan and subsequent application of the code led to the successful creation, update, and integration of networking resources as designed. Witnessed is the orchestration of creating and updating Azure resources with Terraform's operations. The warnings observed regarding the argument deprecation have been noted, and an update to the code to use the newer property before provider upgrade to version 4.0 is in the plan. The introduction of Azure Virtual WAN between branches offers significant advancements in routing simplicity and operational efficiency. The integration of Azure Bastion across both deployments centralizes and secures administrative access, marking a pivotal step in network management.

[FreddyAyala]

Hello @jaredfholgate , after discussing with @jtracey93 , we see a growing need for a comprehensive example that guides CSAs on transitioning networking from the legacy ALZ to AVM modules, including network and bastion setups in order to anticipate the transition to vNext. We'd be grateful for your thoughts on this, we want to provide more detailed feedback in the delivery guide for ALZ VBD and give ample warning to CSA's to anticipate what should be done for vNext. Thank you for your help!