Hub-and-spoke topology in Azure is a network configuration that uses a central hub to connect multiple spokes. The hub is a virtual network (VNet) that acts as a central point of connectivity to many spoke VNets. The spokes are VNets that peer with the hub and can be used to isolate workloads while sharing services protected by the hub. This topology simplifies network management and reduces the potential for costly network traffic charges by keeping traffic within the Azure network.
Benefits of Hub-and-Spoke Topology
- Centralized Management: Centralized resources like network virtual appliances and gateways in the hub.
- Cost-effective: Reduces the need for redundant connections, thus minimizing costs.
- Security: Centralized security services like firewalls or intrusion detection systems.
- Isolation: Spokes can be used to isolate workloads, environments, or applications.
- Scalability: Easy to add new spokes as the organization grows.
Components of the Hub-and-Spoke Topology
- Hub Virtual Network: Contains shared services like Azure Firewall, VPN Gateway, and Azure Bastion.
- Spoke Virtual Networks: Contains resources such as virtual machines (VMs) and are connected to the hub via VNet peering.
- VPN Gateway: Connects on-premises networks to the Azure VNet.
- Azure Firewall: Provides a centralized, network-level protection.
- Azure Monitor: Monitors the health and connectivity of the network.
- DDoS Protection: Protects the Azure resources from DDoS attacks.
Creating Hub-and-Spoke Topology with Terraform
Below is an example of how you might write a Terraform script to create a hub-and-spoke network topology in Azure:
provider "azurerm" {
features {}
}
# Create the Hub Network
resource "azurerm_virtual_network" "hub" {
name = "hub-network"
address_space = ["10.1.0.0/16"]
location = "East US"
resource_group_name = "network-resources"
}
# Create the Spoke Networks
resource "azurerm_virtual_network" "spoke1" {
name = "spoke1-network"
address_space = ["10.2.0.0/16"]
location = "East US"
resource_group_name = "network-resources"
}
resource "azurerm_virtual_network" "spoke2" {
name = "spoke2-network"
address_space = ["10.3.0.0/16"]
location = "East US"
resource_group_name = "network-resources"
}
# Peering from Hub to Spokes
resource "azurerm_virtual_network_peering" "hub_to_spoke1" {
name = "hub-to-spoke1"
resource_group_name = "network-resources"
virtual_network_name = azurerm_virtual_network.hub.name
remote_virtual_network_id = azurerm_virtual_network.spoke1.id
}
resource "azurerm_virtual_network_peering" "hub_to_spoke2" {
name = "hub-to-spoke2"
resource_group_name = "network-resources"
virtual_network_name = azurerm_virtual_network.hub.name
remote_virtual_network_id = azurerm_virtual_network.spoke2.id
}
# … additional resources like subnets, NSGs, VMs, etc.
This script would need to be expanded to fully create the infrastructure as depicted in the provided image, including subnets, network security groups, virtual machines, and any required services like Azure Firewall and VPN Gateway.
The exact script would need to be tailored to the specific requirements, including the Azure region, resource group names, network configurations, and other services that might be required. Moreover, for a production environment, it’s essential to incorporate best practices such as using modules for reusability, implementing state backends for state management, and considering security practices for managing sensitive information like secrets.
Before applying such a script, you should perform a terraform plan to review the changes that will be made and then terraform apply to create the resources in Azure. Always ensure that your Azure subscription has the necessary permissions to create these resources.
Joao Paulo Costa

