Azure API Management – What are my networking options?

Introduction

A very common discussion to have with enterprises around Azure API Management (“APIM”) is the aspect of network integration. At the end of the day, the response to that is very simple… Only the developer & premium SKU allow VNET integration. The integration is achieved by doing “injection”, which means that the service is “dedicated” to you and “the machines” are placed directly in your VNET. Azure APIM does not leverage private link (yet?)… Which then opens the next discussion, as the premium SKU is about 3,42 Euro per hour, where the basic SKU floats at about 20 Eurocent per hour. At this point, for most organizations, the cost impact will take priority over the most optimal design. Where today’s post will take a look at the various options at hand.

Update (March 2022)

Since the initial post, the ability to leverage private endpoints have been made available ; https://docs.microsoft.com/en-us/azure/api-management/private-endpoint. This concept will probably be more interesting to you than the approaches mentioned in this post!

Flavors / Tiers

When taking a look at the pricing info, you will notice there are multiple flavors you can choose from ;

• The consumption tier is the one where you are charged for the amount of calls you make. It is an awesome model in terms of linking your business outcome to the cost model at hand. The downside is, that is does not offer a developer portal or any typical enterprise features (like VNET integration or a self-hosted gateway).
• The basic and standard tiers are economic tiers at both about 45 and 130 Euros per month. They do include a developer portal.
• The developer and premium tiers are the ones typically picked by enterprises due to their VNET integration, HA/DR options (for Premium) and the self-hosted gateway.

Azure Networking ; Service endpoints, Private links and VNET Injection

Introduction

Today’s post is inspired by the combination of a twitter thread from earlier today… and having had the same conversation with a customer earlier today too! Truth be told, there are a variety of networking options when integration Azure Services with your VNET (Virtual Network). So let us go over them!

 

The different options

When you want to integrate PaaS services, you have several options on how to integrate them into your VNET ;

• Service Endpoints
• Private Link
• Deploy inside of a VNET (“VNET Injection”)

 

Now lets us take a look at the differences by using the following schematic ;

 

You will see that both the “SQL Managed Instance” and “Azure Kubernetes” service reside inside of the virtual network. This is what used to be called “VNET injection”, and where you deploy the service directly into the VNET. Typically you give each of those services their own subnet, without any other things inside of it to avoid interoperability issues. Though from then on you can leverage private traffic within your VNET and have hybrid integration scenarios (aka “Connect to On Premises”).

When looking towards the “Azure Storage”, you can see two colors ;

• Purple indicates a “Private Link” & “Private Endpoint”. The private link is the line from the service to the dot. Where the dot is actually the private endpoint, which will have a private ip belonging to the range of the subnet (within the VNET) it belongs too. This means that the service will be able to connects you privately and securely to a service powered by Azure Private Link. The nuance difference between “VNET injection” and “Private Link” is that the first is used for resources dedicated to you (AKS Workers, SQL Managed Instance, …) and the latter is used for services that share resources underneath (AKS Master Nodes, Azure SQL DB, Azure Storage, …). This will also allow you to connect to services in a hybrid integration scenario.
• The orange link depicts the concept of a service endpoint. It extends your virtual network private address space to a shared service. The endpoints also extend the identity of your VNet to the Azure services over a direct connection. Endpoints allow you to secure your critical Azure service resources to only your virtual networks. Traffic from your VNet to the Azure service always remains on the Microsoft Azure backbone network. If you want to understand more of the mechanics underneath, check the following post from when I took my first glance at them. Important to know is that the service will still have its public IP, and that you will leverage that to connect to it. It is used to connect from inside of the VNET to a public endpoint, while you can configure the firewall of the public service to filter on your private range. It cannot be used to connect to a service in a hybrid integration scenario.

 

Not all options work for all services!

Though be aware that not all services have all options available… Check the documentation of the services at hand and the above options. I know this makes it a bit complex at times. Though the capabilities are constantly evolving! And sometimes network integration is also only unlocked in premium editions of a service. For example, in the past you could only get a fully private scenario for App Service by leveraging the Isolated edition (or “App Service Environment”). This made it possible to inject the service into your VNET. Though it had a starting cost of about 1k USD… With the arrival of Private Link/Endpoint, this is not a requirement anymore. Where the API Management does still require either the Premium (Production) or Developer (Non-Production) variants of the service to unlock VNET integration.

 

Closing Thoughts

Things might be confusing at times. Though I hope this brief post helps you position the different options you have in terms of network integration.

• Service Endpoints ; Connect in a hardened way from a VNET to a shared service
• Private Link ; Give a shared service a private endpoint in your VNET
• Deploy inside of a VNET (“VNET Injection”) ; Deploy a service privately for you into your VNET

What the proxy?!? How to use a proxy with the typical Azure tools…

Introduction

Proxy servers are a very common thing in a lot of enterprises. They are used so that people cannot directly access the internet, and additional management capabilities to the flow (logging, authentication, …). Now that sounds very dandy, though what about those non-browser-based tools? How can we ensure that tools like Azure CLI, Azure Powershell & AzCopy work with our “beloved” enterprise proxy? That’ll be the topic for today!

Test Setup

What will we be doing today? I’ve setup a proxy server in my own lab… Basically deployed a Squid proxy by means of a container.

Next up, I’m going to use the three earlier mentioned tools on both Linux (WSL) & Windows, and see what needs to be done to get things working. In the following screenshots you’ll typically see a “split screen”, where left is a “tcpdump” on the box running the proxy server and right will be the commands on the box running the tools. If you see a lot of mumbo jumbo (network packets) on the left, that’ll mean that the proxy server was being used. Ready?!? Cool, let’s go!

Hardening your Azure Storage Account by using Service Endpoints

Introduction

Earlier this week I received a two folded question ; “Does a service endpoint go over internet? As when I block the storage account tags with a NSG, my connection towards the storage account stops.” Let’s look at the following illustration ;

 

The first thing to mention here is that the storage account (at this time) always listens to a public IP address. The funky thing is, that in Azure, you’ll have a capability called “Service Endpoint“, which I already covered briefly in the past. For argument’s sake, I’ve made a distinction in the above illustration between the “Azure Backbone” and the “Azure SDN”. A more correct representation might have been to have said “internal” & “external” Azure Backbone in terms of the IP address space used. So see the “Azure Backbone” in the above drawing as the public IP address space. Here all public addresses reside. Where the “Azure SDN” is the one that covers the internal flows. Also be aware that an Azure VNET can only have address spaces as described by RFC1918. So why did I depict it like this? To indicate that there are different flows;

• Connections from outside of Azure (“internet”)
• Connections from within the Microsoft backbone (“Azure Backbone”)
• Connections by leveraging a service endpoint

So how does the service endpoint work?

So to answer the question stated above ;

• Q: Does a service endpoint go over “the internet”?
• A : Define “internet”…
  • If you mean that it uses a public ip address instead of an internal one? Then yes.
  • If you mean that it leaves the Microsoft backbone? Then no.
  • If you mean that the service is accessible from the internet? Unless you open up the firewall, it won’t (by default, when having a service endpoint configured).

 

• Q: When I block the storage tag in my network security group (“NSG”), then the traffic stops. How come?
• A: The NSG is active on NIC level. The storage account, even when using a service endpoint, will still use the public IP. As this public IP is listed in the ranges that are configured in the service tag, you’ll be effectively blocking the service. This might be your objective… Though if you do this to “lock down the internet flow”, then you won’t achieve the requested you wanted. You should leverage the firewall functionality from the service for which the service endpoint was used.

 

Deep Dive

As always, let’s do a deep dive to experience this flow! So I did set up the above drawing in my personal lab ;

Trying out the Azure Firewall in a Hub & Spoke deployment model

Introduction

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.

 

Architecture

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.

 

Taking a look at Azure Service Endpoints

Introduction

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.

 

Scenario

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!

Azure API Management : What about Multi-Region & VNET Integration?

Introduction

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.

Understanding the budget impact of Azure Networking on your architecture

Introduction

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!

 

Cost Drivers

When looking towards the costs, there are several pricing pages you should visit to know the cost drivers of your architecture…

• Azure Bandwidth : https://azure.microsoft.com/en-us/pricing/details/bandwidth/
• Azure Virtual Network Peering : https://azure.microsoft.com/en-us/pricing/details/virtual-network/
• Azure VPN Gateway : https://azure.microsoft.com/en-us/pricing/details/vpn-gateway/
• Azure Express Route : https://azure.microsoft.com/en-us/pricing/details/expressroute/

Though I can feel you… It’s not always easy to understand when what is triggered.

 

Updates (!)

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

Azure : Is it possible to do a cross subscription network peering?

Introduction

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?!?

Azure Star / Any Load Balancer or … like we would like to call it “HA Ports”

Introduction

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.