Azure Networking : Blueprint patterns for enterprises

Introduction

When moving to the cloud, one cannot imagine this without some kind of network integration. Taking a look at “Infrastructure-as-a-Service”, there are several common patterns that are utilized by enterprises. Today we’ll discuss these patterns…

 

Update – June 2018

Despite that this post isn’t even a year old, I’ll be updating it with the new guidance that come from the introduction of the standard LB. Here we advise to use a single legged deployment.

 

Typical Network Maturity Models

Embarking on a cloud journey? You’ll typically go through the following patterns depending on your “maturity level” in working with the cloud ;

1. “Island” : The first approach is typically “the island”. The VMs reside in a VNET that is not connected/integrated with any other networks, except for (maybe) the internet.
2. “Hybrid Connection” : The first step towards integration is creating a hybrid connection. Here you want to access “On Premises” resources, though the mass of the resources on Azure do not justify the investment into a “Network Virtual Appliance” (AKA Firewall). Two flavours typically arise here;
   1. “Forced Tunneling” : Here you set up a “UDR” (User Defined Route, AKA Static Route), where you force all traffic to go back to the “On Premises” network.
   2. “Azure = Internet Zone” : Here you assume that the Azure zone is does what it needs to do to protect its resources Though you’ll protect your “On Prem” zone by considering the Azure VNET as being “the bad internet”.
3. “Single VNET with DMZ” : One step beyond “forced tunneling”, is moving towards the typical DMZ-alike pattern, where you setup a HA-pair of “Network Virtual Appliances” and segregate network zones.
4. “Hub & Spoke”-model : Growing even further, you’ll have multiple subscriptions. Setting up “NVAs” on all of those can be quite expensive. In terms of governance, this also a nice model, where you can consolidate all network integration into a segregated subscription/vnet.

The advantage of these patterns is that you can evolve into another pattern without breaking anything in terms of design.

 

“The Island”

The most simple deployment model… A single VNET, connected to the internet. Life is great, as you don’t need to care about anyone else! Though once you start integrating, you’ll notice that this might not be the most ideal situation. You might need more resources than the island can provide…

 

 

“Hybrid Integration”

The first step towards integration with “On Premises” resources is typically done via “forced tunneling”. Here you don’t allow the systems to connect towards the internet via Azure, and setup a user defined route (UDR / static route) that sends all traffic to the OnPrem Gateway. Where this is a simple model, be aware that this way of thinking might have some odd side effects in terms of performance and management services that want to go “outside” (in terms of the VNET).

 

Another way to work with this model is to consider the Azure zone as “the Internet” (with all the bad guys out there). Ofcourse all the necessary measures will be taken to protect the Azure resources, though from the “On Prem” security perimeter’s point-of-view, Azure will be considered as “Unsafe Internet”.

 

Single VNET with DMZ : One NVA Pair

When the mass of resources in Azure grows, the investment into an NVA (Network Virtual Appliance, or “Firewalls”) becomes justified. Now we can setup a DMZ-alike structure.

Here you’ll be setting up UDRs on each subnet that will route all traffic to the NVAs. The NVA pair will be your central routing/firewall component to segregate/secure all traffic.

 

Single VNET with DMZ : Two NVA Pairs

An enhancement of this setup is having two NVA pairs, where one handles handling all the incoming internet traffic and the other one handles all other scenarios. This is typically called a “Northbound / Southbound”-deployment. The “Northbound” will handle all incoming internet connections (“DMZ Ext”), where the Southbound (“DMZ Int”) will handle all internal flows and also the connections that need to go to the outside world.

Where a minor variant of this might by using a WAF for the Northbound traffic.

 

“Hub & Spoke”

Over the period of time, you’ll see additional subscriptions being introduced into your landscape. Setting up a DMZ-alike setup on each of those will be a rather expensive venture. In order to optimize costs, and to tighten security/governance structures, you can opt for a “Hub & Spoke“-model.

 

Here you have a central “Hub”, where all the NVAs reside. You’ll be terminating all connectivity (ExpressRoute, VPN, Internet, etc) on this VNET. In the other subscriptions, you’ll create a VNET-peering between those VNETs and the central HUB. From these SPOKE-subscriptions/VNETs, you’ll drive all traffic back to the HUB via UDRs. In addition, you can setup policies that disallow the usage of public IP addresses in those subscriptions/VNETs.

 

Closing Thoughts

Moving to Azure? Thinking about networking will be inevitable. Though be aware that there is a kind of “growth”-model that will let you move from a more basic form to more advanced models.

Aside from that, several remarks / points of attention / advice I always provide during workshops ;

• When designing in Azure, think in terms of Layer 3 of the OSI model, and forget about Layer 2. Anything you want to do in Layer 2, here you’ll be leveraging the load balancer.
• Want to do advanced networking setups? You’ll end up using BGP.
• Be aware of the hierarchy of system routes, user defined routes & BGP.
• Discuss Azure integration with the NVA brands on your shortlist. Take not on how they handle user defined routes during failover scenario’s and if they can leverage Azure objects into their rulebase/set.

 

(Updated) Do I need an NVA/NGFW or not? Do I need to go for a “Hub & Spoke” or not?

A question that I was recently asked was if an NVA (NGFW) is mandatory for any of the deployment, or if a cloud-native approach can be taken? The answer is the most annoying consultancy answer you can get ; “It depends…”. So what is the tipping point? For me it bascially comes down to your security requirements. In a lot of cases, Enterprises require Deep Packet Inspection as part of their security requirements. And another requirement I do see popping up is the requirement to have a “Single Pane of Glass”. If those are the requirments, then yes, you need an NGFW in there.

In regards to the “Hub & Spoke”, where it’s similar to the previes question… “It depends”. The tipping point here is typically a cost considation and unified security requirement. The boundary of a virtual network is a region or a subscription. Thus if you cross those, then you’re going to breed virtual networks. Each virtual network might have a base infrastructure requirement (domain controller, backup, monitoring, jumpbox, firewall pair, etc)… So costs might arise in doing so. By leveraging a HUB, you can consolidate those costs.

Another reason to do so is from a network routing perspective. If you have a lot of VNETS linked into a kind of “mesh”, then routing may soon get very complex. By having one routing endpoint (from the viewpoint of the Spoke), the routing will become less complex than the aggregate of a distributed rulebase managed by various people/teams.

Though in the end, know that you can do A LOT with Azure. Though that does not mean you HAVE to do it… Always take your requirements into account and create the most (cost/operational) efficient architecture.