I have been working through the Microsoft AZ-700 course, which covers all things ‘Network-y’ in Azure. It was a tough learning curve for me as up until now, networking in general has been an area of weakness as I am a typical infrastructure engineer, and in the old on-premises only days I would have a networking team I could rely on to help me out here. In the world of software defined networking in Azure however, things are a little different so I took it upon myself to get into Azure networking shape, as it were! I enjoyed the experience of improving my knowledge and expertise in this area and thought it was worth sharing some of my thoughts on this, so here goes!
Design Considerations
Here’s my top 5 things to think about when considering your Azure network design:
1. Network Topology
Might seem obvious, but let me explain…. I think it’s important to think about this in an abstracted view, not really thinking about the specific Azure technology you wish to use. Think of it as a blueprint – you’ll end up using the right tech for your design and requirements this way, rather than the tech you think you should be using just because its an Azure service you have heard of and quite like the look of. Obvious questions are:
- What kind of network segregation is required?
- Are there production and non-production workloads to consider?
- What does/should my WAN look like?
- Are there any geographic affinity requirements?
- Any DMZ requirements to consider?
- Any load balancing requirements?
- etc, etc.
You will find that a lot of the approaches you took on premises still apply here – the tech used to achieve them will be different but the methodology for planning your estate, should be familiar.
2. Bandwidth requirements
Again, fairly self-explanatory but worth being aware of anything specific that you need to keep in mind when deploying to Azure so you can incorporate this in designs.
3. Latency
For example, does an application have a web front end and database at the back, and if so what latency requirements does that connectivity between the two sides of the infrastructure need to be? This may restrict what you can do in terms of transformation to PaaS type services, or indeed might mean this is the only way to go when you move old or deploy your new workloads to Azure.
4. Security
This is a biggie and there are a multitude of options in Azure that you can use, but again try and abstract away from the technology and just think about the network segregation requirements and perimeter initially, then think of the more advanced stuff like IDS/IPS, DDOS, etc. You will find its quite easy to find tech to meet the requirements here as there are many different approaches so just make sure you know what you need, and you’ll be able to make it work.
5. Cost
Always a consideration when using Azure, and that OPEX nature of the Azure world can take some getting your head around when coming from the CAPEX on-premises world. If you are used to it though, it is tempting to get carried away and just enable EVERYTHING because you can and it’s easy to do in Azure. Prime example of this is DDOS Standard protection – it’s a single check box to switch it on, but it’s a mere £2.5k per month for your first 125 resources, with additional costs being lumped on after that for each additional resource.
The above decisions should help you create a High-Level design and give you a budget to work towards so you can start to look at the technology you need to achieve your requirements.
Technology Options
Once you have a design, you can start to check out some of the fantastic features that Azure has to offer to meet your requirements. Some of the highlights are as follows:
VNets
If we’re starting from scratch, then most people will need at least one Virtual Network – or VNet creating. If you are lucky enough to be deploying an Enterprise Scale Azure Landing Zone then you will probably find yourself with at least three networks, and within each of these you will have a variety of Subnets. The general advise is to go big on your network ranges (a /16 per VNet for example) that you can then break down into smaller /24 subnets accordingly. This isn’t always possible, but just go with as large a range as you can for the VNet so you have some network segregation options for your subnets. You can also peer these VNets together, which gives you the option to inter-connect resources throughout your various Subscriptions and Tenants, and the ability to share services like a VPN or ExpressRoute gateway to provide connectivity to on-premises networks.
NSG’s
Network Security Groups, or NSG’s are the first step to securing your Azure environment. The diagram below shows a classic N-Tier architecture, using NSG’s to stop traffic from undesired locations/ports speaking to parts of the environment that it shouldn’t speak to. In this case, you wouldn’t want the end user Web traffic taking directly with the database, you would want an application layer in between to facilitate this connection. NSG’s could be used to ensure that this connectivity is set up as designed.
Firewalls
This is quite a complex area, but it is worth noting that the Azure Firewall (specifically the Premium SKU) offers a significant array of functionality that you would typically expect with an on-premises device from most of the big names, like CheckPoint/Fortinet, etc. It’s a fully stateful virtual device with some IDS/IDP features built-in. You can apply a multitude of rules to allow and restrict traffic to/from the internet to all services you host behind this. There is also the option to use a Network Virtual Appliance (NVA), so if you have a loyalty to a particular brand such as CheckPoint or Fortinet you can stick to what you know and deploy this in place of the Azure Firewall. As you would expect however, the more advanced you go with this the higher the cost so it is a good idea to research this thoroughly when you are deciding.
Also with Azure, it is important to know that almost all services that reside in Azure have access to the internet by default. When you build a VM, it can route to the internet by default routes built in to the platform and simply deploying a firewall is not enough to control this – you have to override these default routes using…
UDR’s
…User Defined Routes. If you have a simple network topology in Azure without an Azure firewall, then there typically isn’t a requirement for a UDR. However, as soon as you want to override the default routes to stop traffic free flowing to the internet openly, you need to use a UDR to achieve this. The default route to the internet can be overridden to point to the firewall using a 0.0.0.0/0 route with the next hop being the firewall, and this needs to be in place on all VNets/Subnets that you have within your environment. This needs to be manually added, unless you are using a…
V-WAN Hub
….Virtual WAN Hub. This is Azure’s answer to managing more complex network architecture within the platform. It allows you to create a Hub, that will deploy and self-manage all routing for you – even if you have more than one Hub network within your environment. Each of the Hub’s is full mesh peered to the other, and any firewalls can then be centrally managed via your V-WAN Hub using layered policies, automated VNet peering and all that good stuff.
WAN Connections
Despite lovely buzz-phrases like ‘Cloud first’ and ‘Digital Transformation’, most of us with have some need for on-premises servers in some form or another. What that need looks like will depend on the type of connectivity you want to use to extend your WAN to Azure. You can terminate these into a simple GatewaySubnet in your hub network in Azure, or you can use the more advanced Virtual WAN to help you with the routing, etc if you wish. Ultimately though you are going to either use a site to site VPN, or an ExpressRoute to achieve what you need when it comes to connecting to on-premises. At a very high level, here’s some features of each of these two options:
- The VPN option is just a typical site-to-site that runs directly across your internet breakout. There are a multitude of SKUs each offering different bandwidth and VPN options, as well as different resilience levels to take advantage of the Availability Zone features that some regions in Azure offer as well. Even the first Standard SKU does have HA built in to the service though, so in the event of a failure Microsoft will fail over to the secondary node for you without you even realising it has happened usually. Site-to-site cost model is based on the hosting costs for the gateway devices plus throughput charges for the amount of data traversing the link. Because of this, it tends to be favoured in smaller deployments where the traffic across the link is expected to be minimal.
- ExpressRoute offers you a dedicated layer 3 WAN link, similar to an MPLS connection for example that connects directly into the Microsoft network at one of the many service provider connection exchanges. Connectivity ca be from an any-to-any (IPVPN) network, a point-to-point Ethernet connection or through a virtual cross connect at an Ethernet exchange. There are a multitude of SKUs that again offer different levels of bandwidth (starting at 50Mbps, going up to 10Gbps) and on-going connectivity. There are several cost modes for this – a throughput based charge, or an unlimited charge where you can send as much traffic over the link as you wish without incurring any additional costs. Because of this it tends to be favoured for larger environments where data transfer costs would make anything other than unlimited very expensive. It is also worth noting with ExpressRoute there is typically a third party provider to consider, as they will be required to provide the last mile connectivity from your on-premise network to the exchange into Microsoft on your behalf, which will incur a cost.
There we have it! My take on the things you should consider for an Azure network deployment. If you stuck with it till the end – well done you! If you would like to know more about this please get in touch, and I would recommend the AZ-700 exam and using the Microsoft Learn journey for this course which is available here: AZ-700 Designing and Implementing Microsoft Azure Networking Solutions – Training | Microsoft Docs.
