Hi Everyone!

This post is continuation of how to series about Hub-Spoke network topology in Azure. Over the time, I will update this page with links to individual posts :

Connect an on-premises network to a Microsoft Azure - Part 1

Connect an on-premises network to a Microsoft Azure - Part 2

This Post - Implementing Hub-Spoke network topology in Azure - Part 1

Implementing Hub-Spoke network topology in Azure - Part 2

Introducing Azure Firewall in Hub-Spoke network topology in Azure

Implementing Azure Firewall in Hub-Spoke network topology in Azure

Before deep dive into implementation, we need to know what Hub-Spoke topology is all about.

The spoke-hub distribution paradigm is a form of transport topology optimization in which traffic planners organize routes as a series of “spokes” that connect outlying points to a central “hub” – Wikipedia

To simplify, while you are using public cloud, you need a secure entry point in your cloud network to access resources and this topology does exactly same by introducing a central virtual network (Hub) which you connect from outside world and other internal virtual networks (Spokes) will connect with central hub. Benefits for this topologies are -

  • Easier to manage shared services
  • Lower licensing costs
  • Improved segregation
  • Easy to scale

However, Please note this might be your single point of failure.

Keeping drawbacks aside, let’s see the overall architecture.

Architecture

Below diagram will give you overall idea : Simplified Hub Spoke Topology

The architecture consists of the following components.

  • Hub virtual network - The virtual network used as the hub in the hub-spoke topology. The hub is the central point of connectivity to your azure network, and a place to host services that can be consumed by the different workloads hosted in the spoke virtual networks.

  • VPN Gateway - In previous post, I discussed in details.

  • Spoke virtual networks - One or more virtual networks that are used as spokes in the hub-spoke topology. Spokes can be used to isolate workloads in their own virtual networks, managed separately from other spokes. Each workload might include multiple tiers, with multiple subnets connected through Azure load balancers.

  • Virtual network peering - Two virtual networks can be connected using a peering connection. Peering connections are non-transitive, low latency connections between virtual networks. Once peered, the virtual networks exchange traffic by using the Azure backbone, without the need for a router. In a hub-spoke network topology, you use virtual network peering to connect the hub to each spoke. You can peer virtual networks in the same region, or different regions. For more information, see requirements and constraints.1

In the above diagram, though I have shown all virtual networks are in same subscription and same region but please note it is absolutely possible to connect virtual networks from different subscription or different azure region.

In my next post , I will start to implement the architecture.

  1. Azure Architecture Reference ↩︎