In Azure, it is common knowledge to create virtual networks. However one thing that always leaves doubts is: how to ensure the best network topology?
With that in mind, it's important to understand why you plan your network topology when working on your deployments.
Only with planning, and a correct understanding of Azure architecture, can we keep in mind how to build a viable topology that starts small and allows scalability.
Today the main deployment patterns used in Microsoft Azure are:
- Daisy chain;
Hub-spoke Topology is characterized by having a dedicated network for shared services (hub) and isolated networks for workloads. Traffic between on-premises and Hub can be established using ExpressRoute or VPN Gateway.
You will get a lot out of this type of topology if you want to work with multiple isolation workloads Working in the cloud. Bi-directional communication is not required, but is usually implemented. When you want to centralize shared resources such as DNS, NTP, AD DS, ADFS servers, this topology can also be very useful.
You can have many benefits from this implementation by these aspects.
- Cost reduction centering workloads shared;
- Override subscription limits performing the peering of VNETs;
- Activity separation: between IT Central (InfraOps and SecOps) and workloads (DevOps).
The Azure Architecture Center provides rich documentation on how to deploy a hub spoke architecture as well as PowerShell references.
Daisy-chain topology works with the concept of transient network. Unlike the Hub-spoke topology, communication between other networks is possible, but the route will always go through a central network. Think of it this way, you have 3 virtual networks: vnet1, vnet2 and vnet3 and vnet 2 is your central vnet. If vnet1 wants to talk to vnet3, the package must first go through vnet2. The same must happen when vnet3 wants to communicate with vnet1.
The main benefit on this front is that you can take advantage of the fact that there is already an established route between 2 networks for communications between other networks.
On the other hand, if your transient network is down, you will lose connectivity between all other networks.
Finally we have the FullMesh topology, being one of the best known and used today. In this topology, all of your virtual networks communicate in all directions and this ensures a great deal of connectivity resiliency. When it comes to deployment practices in Azure, this topology can pose some challenges because you must:
- Or create a single virtual network and treat multiple subnet ranges and “treat” these subnets as separate networks. The challenge here is to address filtering / isolation of workloads more criticism.
- Or create multiple virtual networks and connect using VNET Peering or VPN Gateway. In both situations traffic costs are expected, and in the second option there is an additional cost with the VPN Gateway.
Design and Deployment Tips
Among the topologies I have shown, the most widely used as a deployment pattern in the cloud is the Hub-spoke topology. Microsoft has a very well documented architecture and implementation model and the main one presented is the possibility of isolating workloads of shared resources.
By bringing advantages in the logical isolation of resources we have in this topology a model that is simple to implement and at the same time scalable. So here are some tips for implementing your Hub-Spoke architecture:
- Define shared services and specialized services;
- Pay attention to the limitations of the subscription feature (500 peerings per subscription);
- If you are interested in working with a DMZ (public or private), implement a NVA;
Here we close the topic about Network deployment patterns in Azure. The subject can sometimes generate many doubts, but as I passed, it is very important keep the architect vision in mind, because your deployments need to be scalable and allowable to repeat.
- Hub-Spoke Topology
- Hub-Spoke Topology with Shared Services
- Hub & Spoke, Daisy Chain and Full-Mesh VNET topologies in Azure ARM (V2)
- Mesh and hub-and-spoke networks on Azure
Want more information? Follow the first episode of Foot on the Cloud where I talk about VNET Standards!