Azure Networking : Blueprint patterns for enterprises


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…


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. “Forced Tunneling” : The first step towards integration is “forced tunneling”. 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). 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.
  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…


“Forced Tunneling”

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).


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 all internal traffic (inside VNET and towards OnPrem) and another one handling all the external/internet 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.



2 thoughts on “Azure Networking : Blueprint patterns for enterprises

    1. Technically possible, though bare in mind that the most optimal situation (in terms of performance) is obtained when you have one hub per region.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s