Implementing and peering virtual networks to create a secure foundation for cloud workloads.
Following my journey into Azure infrastructure, I recently deployed a core networking configuration that's essential for any serious cloud environment: a hub and spoke virtual network architecture. This was my eighteenth project hands-on with Azure, and it focused on nailing the fundamentals of secure, private connectivity.
Whether you're studying for a certification or building a production environment, understanding how to properly segment and connect networks is a critical skill. Let's break down what I built and why it matters.
The Objective: Why Hub and Spoke?
The goal was to simulate a real-world scenario: migrating a web application to Azure while enforcing strong network security. A single, flat network might work for a simple app, but it's a nightmare for security and scalability.
The hub and spoke model solves this:
The Hub (hub-vnet): The secure core of the network. This is where we place shared services that need to be accessed by all workloads, like firewalls, VPN gateways, or a central DNS server. All traffic entering, leaving, or moving between spokes is routed through the hub for inspection and logging.
The Spoke (app-vnet): The workload-specific network. This is where the actual application lives. In this case, it hosts web servers and databases. Spokes are isolated from each other by default, which contains any potential security breaches.
This design provides centralized security, reduces management overhead, and makes it easy to onboard new applications (new spokes) in the future.
The Build: A Look at the Architecture
Before any deployment, you need a blueprint. Here was the plan, which I then executed in the Azure portal.
The technical objectives were:
Provision two virtual networks with non-overlapping IP address spaces.
Segment the application network into subnets for layered security.
Establish private connectivity between them using VNet Peering.
Step 1: Building the Isolated Networks
In Azure, a Virtual Network (VNet) is a logically isolated network—your own private slice of the cloud. I created two of them in the East US region within the same resource group for co-location.
The Application Spoke (app-vnet):
Address Space: 10.1.0.0/16
*Subnet *- frontend: 10.1.0.0/24 (For web servers/frontend VMs).
*Subnet *- backend: 10.1.1.0/24 (For database services). Segmenting these tiers is a primary security control.
The Security Hub (hub-vnet):
Address Space: 10.0.0.0/16 (Note: It's critical that VNet address spaces don't overlap!).
*Subnet *- AzureFirewallSubnet: 10.0.0.0/26 (This is a special, mandatory name for the Azure Firewall subnet, which has a minimum size requirement of /26).
Step 2: Connecting with VNet Peering
With the networks built, they were completely isolated. To enable private communication without routing traffic over the public internet, I configured VNet Peering.
VNet Peering creates a low-latency, high-bandwidth connection routed through Microsoft's private backbone network. It's seamless and secure.
The process is simple but powerful:
Navigate to app-vnet > Peerings > + Add.
Configure the peering link from the spoke to the hub (app-vnet-to-hub-vnet).
Configure the reciprocal link from the hub back to the spoke (hub-vnet-to-app-vnet).
Azure handles the rest. Within seconds, the status showed "Connected."
Why This Matters: Key Takeaways
This project, while seemingly straightforward, reinforces several non-negotiable cloud concepts:
Intentional Design Beats Default Configs: Cloud environments are secure by default but are often too open. Purpose-built designs like hub-and-spoke are essential for enterprise-grade security and compliance.
Subnet for Security: Subnets are your primary tool for applying network security policies (with Network Security Groups). The separation of frontend and backend tiers means you can create strict rules; e.g., your database subnet can block all traffic except from the frontend subnet.
The Power of Private Peering: VNet Peering is the glue for complex architectures. It provides the benefits of a single network while maintaining administrative separation and isolation. The fact that traffic never hits the public internet is a major security and performance win.
Next Steps
This network is the foundation. The immediate next steps to bring this to life would be:
Deploying an Azure Firewall into the AzureFirewallSubnet.
Configuring routing tables (UDRs) to force traffic from the spoke through the firewall.
Deploying virtual machines into the subnets and testing connectivity.
Building this yourself is the best way to understand it. I highly recommend firing up a subscription and trying it out.
This is my eighteenth project building on Azure, and it's amazing how these fundamental concepts become second nature and form the building blocks for more complex solutions.
What's your preferred network design pattern in the cloud? Have you used hub-and-spoke in production? Share your experiences below!
Top comments (0)