Create a hub and spoke hybrid network topology in Azure using Terraform

This articles series shows how to use Terraform to implement in Azure a hub and spoke network topology.

A hub and spoke topology is a way to isolate workloads while sharing common services. These services include identity and security. The hub is a virtual network (VNet) that acts as a central connection point to an on-premises network. The spokes are VNets that peer with the hub. Shared services are deployed in the hub, while individual workloads are deployed inside spoke networks.

In this article, you learn how to:

  • Lay out hub and spoke hybrid network reference architecture resources
  • Create hub network appliance resources
  • Create hub network in Azure to act as common point for all resources
  • Create individual workloads as spoke VNets in Azure
  • Establish gateways and connections between on premises and Azure networks
  • Create VNet peerings to spoke networks

1. Configure your environment

  • Azure subscription: If you don't have an Azure subscription, create a free account before you begin.

2. Understand hub and spoke topology architecture

In the hub and spoke topology, the hub is a VNet. The VNet acts as a central point of connectivity to your on-premises network. The spokes are VNets that peer with the hub, and can be used to isolate workloads. Traffic flows between the on-premises datacenter and the hub through an ExpressRoute or VPN gateway connection. The following image demonstrates the components in a hub and spoke topology:

Hub and spoke topology architecture in Azure

Benefits of the hub and spoke topology

A hub and spoke network topology is a way to isolate workloads while sharing common services. These services include identity and security. The hub is a VNet that acts as a central connection point to an on-premises network. The spokes are VNets that peer with the hub. Shared services are deployed in the hub, while individual workloads are deployed inside spoke networks. Here are some benefits of the hub and spoke network topology:

  • Cost savings by centralizing services in a single location that can be shared by multiple workloads. These workloads include network virtual appliances and DNS servers.
  • Overcome subscriptions limits by peering VNets from different subscriptions to the central hub.
  • Separation of concerns between central IT (SecOps, InfraOps) and workloads (DevOps).

Typical uses for the hub and spoke architecture

Some of the typical uses for a hub and spoke architecture include:

  • Many customers have workloads that are deployed in different environments. These environments include development, testing, and production. Many times, these workloads need to share services such as DNS, IDS, NTP, or AD DS. These shared services can be placed in the hub VNet. That way, each environment is deployed to a spoke to maintain isolation.
  • Workloads that don't require connectivity to each other, but require access to shared services.
  • Enterprises that require central control over security aspects.
  • Enterprises that require segregated management for the workloads in each spoke.

3. Preview the demo components

As you work through each article in this series, various components are defined in distinct Terraform scripts. The demo architecture created and deployed consists of the following components:

  • On-premises network. A private local-area network running with an organization. For hub and spoke reference architecture, a VNet in Azure is used to simulate an on-premises network.

  • VPN device. A VPN device or service provides external connectivity to the on-premises network. The VPN device may be a hardware appliance or a software solution.

  • Hub VNet. The hub is the central point of connectivity to your on-premises network and a place to host services. These services can be consumed by the different workloads hosted in the spoke VNets.

  • Gateway subnet. The VNet gateways are held in the same subnet.

  • Spoke VNets. Spokes can be used to isolate workloads in their own VNets, managed separately from other spokes. Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers.

  • VNet peering. Two VNets can be connected using a peering connection. Peering connections are non-transitive, low latency connections between VNets. Once peered, the VNets exchange traffic by using the Azure backbone, without needing a router. In a hub and spoke network topology, VNet peering is used to connect the hub to each spoke. You can peer VNets in the same region, or different regions.

4. Implement the Terraform code

  1. Create a directory to contain the example code for the entire multi-article series.

  2. Create a file named main.tf and insert the following code:

    terraform {
    
      required_version = ">=0.12"
    
      required_providers {
        azurerm = {
          source  = "hashicorp/azurerm"
          version = "~>2.0"
        }
      }
    }
    
    provider "azurerm" {
      features {}
    }
    
  3. Create a file named variables.tf to contain the project variables and insert the following code:

    variable "location" {
        description = "Location of the network"
        default     = "eastus"
    }
    
    variable "username" {
        description = "Username for Virtual Machines"
        default     = "azureuser"
    }
    
    variable "password" {
        description = "Password for Virtual Machines"
    }
    
    variable "vmsize" {
        description = "Size of the VMs"
        default     = "Standard_DS1_v2"
    }
    

    Key points:

    • This article uses a password you enter when you call terraform plan. In a real-world app, you might consider using a SSH public/private key pair.
    • For more information about SSH keys and Azure, see How to use SSH keys with Windows on Azure.

Troubleshoot Terraform on Azure

Troubleshoot common problems when using Terraform on Azure

Next steps