Azure Landing Zones and Networking
I’m continuing the series on Azure Landing Zones (ALZ). If you want to catch up, here are links to the previous entries:
In this post, let’s talk about VNet networking within Azure Landing Zones.
Networking is simple, right?
Sure thing boss! No, seriously, this blog post could be a book. In order to keep it focused, I want to concentrate on networking within Azure. An Azure Virtual Network (VNet) is the primary building block for creating your private network in Azure. Typically, deployments will have a few to several virtual networks, providing management and networking boundaries between workloads.
In order to understand the topologies within the Azure Landing Zone, we need to cover a couple of concepts.
Peering
Virtual networks are private address spaces that can be used to deploy resources. Virtual networks can then be connected by way of peering. With peering, resources in separate virtual networks can directly address each other using private IP addresses. Importantly, Azure supports the concept of global peering, which allows you to directly connect two virtual networks in different regions to each other.
Peering is a complicated topic, but one point to understand for this discussion is the concept of VNet transit. In Azure, virtual networks that are peered together can talk to each other directly. However, spokes in a traditional hub-and-spoke topology cannot natively talk to each other. A networking device (router/firewall/etc.) is required to allow this traffic to work.
Azure Firewall
According to the docs Azure Firewall is a “cloud-native and intelligent network firewall service”. As opposed to network virtual appliances (NVAs) you can think of Azure Firewall as a “firewall-as-a-service”. Designed to scale and providing many of the same features as traditional NVAs, Azure Firewall can be an effective way of providing both north-south (in/out of your environment) and east-west (lateral between systems/services in your environment) protection for your Azure workloads.
Network Security Groups
Network Security Groups allow you to filter traffic at the network level for resources deployed in Azure. Configurable on both the subnet and resource level, you can make use of network security groups to provide micro-segmentation protection.
Networking Options
The ALZ has two built-in models for networking in enterprise scale.
Hub-And-Spoke
The traditional approach to Azure networking is the create a hub-and-spoke topology.
Remember, spokes cannot talk to each other. So, in this topology, a firewall or NVA is required in the hub to enable that communication flow. Because of this, all communication flows will require some step for configuration of that firewall.
One consideration is how to expand this networking topology to be cross region. There are likely 2 ways to accomplish this. The first way would be to create another hub/spoke topology in the second region, and then peer the two “hubs” together. In this scenario, the firewall would be traversed twice during networking transit between regions.
The second way would be to globally peer VNets together that are allowed to talk to each other.
Virtual WAN
Azure Virtual WAN is a “meta” networking service within Azure that brings together several services in Azure to greatly decrease the complexity of networking. You can see how the ALZ uses Virtual WAN here.
In this setup, you effectively deploy a Virtual WAN Hub in each region. Hubs can connect to each other directly. Virtual networks can associate themselves with the hub. Virtual WAN offers a couple of cool capabilities such as direct VNet transit access and secure Virtual WAN hubs. I’m not going to go into detail here, but you can likely understand that there are several benefits to this topology over the traditional hub-and-spoke.
Lastly, you can enable any-to-any type communication patterns.
Hidden 3rd Option
At time of writing, Azure has a new service called the Azure Virtual Network Manager (VNM). I feel like this service really combines the best of both the hub-and-spoke and the Virtual WAN solutions when it comes to VNet considerations within Azure. Here are some key features:
You can centrally manage policy which automatically creates your networking topology.
You can enable hub-and-spoke and mesh topologies (VNets with direct access to each other)
You can manage other features of your virtual networks, including network security groups and new admin rules
There is currently no guidance on how to use ALZ with AVNM. For me, this option really allows you to start configuring your guardrails (around networking and network security) and enforcing that via policy within the platform. There are several reasons why I would recommend starting here vs the other two topologies mentioned above.
Conclusion
Networking is a complex topic with many nuances that can affect your security posture. I hope that I did an okay-ish job going over some of the basics here and showing that there are many alternatives to building a secure networking topology within Azure.