A few weeks ago the Azure Firewall went into public preview. Today’s post will be around taking it for a spin in a hub & spoke deployment.
First off, what will the architecture of our deployment look like?
- A central hub, where we’ll deploy the Azure Firewall. This will consist of the address space 172.16.0.0/12.
- Two spokes, each with their own address space (10.[1/2].0.0/16) where a UDR will send all traffic to the Azure Firewall (172.16.254.4).
- In each VNET, we’ll deploy a “SUBNET000” in which we’ll setup a vm to do our basic connectivity testing.
- Each spoke is connected with a bidirectional VNET peering with the spokes. Both spokes can only talk to each other over the HUB.
- The Azure firewall will be configured to allow traffic within the 10.0.0.0/8 range.
Continue reading “Trying out the Azure Firewall in a Hub & Spoke deployment model”
The concept of Service Endpoints has been around for a while now. Though for today’s post I would like to guide you through the typical process. Here we’ll take a glance of how they work and so that you know what to expect.
For this post we’ll be connecting the Azure PostgreSQL Service to a VNET by leveraging a Service Endpoint. Afterwards we’ll make a connection from a VM within that VNET, and see what route is being taken!
Continue reading “Taking a look at Azure Service Endpoints”
Yesterday I received a question whether the combination of Multi-Region & VNET Integration is supported for Azure API Management. My gut feeling told me yes… Though it seems our documentation wasn’t 100% clear on the matter. So I did a quick test to see if it was possible.
Continue reading “Azure API Management : What about Multi-Region & VNET Integration?”
Today’s post will be about “demystifying” the possible network costs you might incur when using Azure services. Once you understand the basics behind the billing model, you’ll soon find that you can tweak these to your advantage!
When looking towards the costs, there are several pricing pages you should visit to know the cost drivers of your architecture…
Though I can feel you… It’s not always easy to understand when what is triggered.
- 23/08 – Updated HL overview to v2.0 to include costs due to zone architecture
- 23/08 – Source files for the drawing can be found here.
High Level Overview
Underneath you can find an overview of the possible cost drivers. We’ll go into depth on the individual flows in this post.
Continue reading “Understanding the budget impact of Azure Networking on your architecture”
Today I received a question if it was possible to do a cross subscription peering… with one big catch; that it was between the subscription of a service provider and their customer(s). So let’s see what is possible?
Update : Oct 2018
At Ignite 2018 it was announced that peering will also be able to work cross tenants.
Public Preview Announcement
When we take a look at the announcement, we see the following statement ;
Note that you can peer virtual networks that exist in two different subscriptions as long as a privileged user of both subscriptions authorizes the peering and the subscriptions are associated with the same Active Directory tenant.
Now the from this we can already see that it is possible to doe cross subscription peering. As a requirement, we need a user that is authorized on both subscriptions AND that the subscriptions are associated with the same AAD tenant.
The latter caused a bit of confusion on the requestor part, where the statement was made if a B2B invite would solve this issue. The answer to this is “no”. The B2B invite lies on the authorized user part, and is not related to the tenant of the subscription!
Let’s try it out?!?
Continue reading “Azure : Is it possible to do a cross subscription network peering?”
A few weeks ago the “HA Ports” (finally) saw the light (in public preview)! I’m truly excited about this one, as it had become a “unicorn” for me over the last years.
Why am I so excited about this one? This unlocks of advanced networking patterns, starting with a truly HA setup for the Network Virtual Appliances (NVAs). In the past, we needed to rely on “workarounds” that would switch the UDR to point to the surviving node. That was great for the time, but let’s be honest… It shouldn’t have been like that.
Another use case is the scenario where an application needs to connect to a certain dynamic port ranges (like with SQL). I’ve seen several deployments annoyed by this requirement, which then forced people to create a lot of rules. This can now be avoided by allowing the entire port range, and just hardening it with a “Network Security Group” or Firewall rule base.
Continue reading “Azure Star / Any Load Balancer or … like we would like to call it “HA Ports””
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 ;
- “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.
- “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;
- “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.
- “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”.
- “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.
- “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.
Continue reading “Azure Networking : Blueprint patterns for enterprises”