Skip to main content

Subnet delegation and API Management

When updating some network related ARM templates I stumbled on the concept of subnet delegation.

What is subnet delegation?

Subnet delegation enables you to designate a specific subnet for an Azure PaaS service of your choice that needs to be injected into your virtual network. When you delegate a subnet to an Azure service, you allow that service to establish some basic network configuration rules for that subnet, which help the Azure service operate their instances in a stable manner. One of the advantages is that the service can configure for example routing policies or network security groups. 

Subnet delegation and API Management

When I was updating our virtual network/subnet templates I stumbled on the delegation section.

"delegations": [
    "id": "string",
    "properties": {
      "serviceName": "string"
    "name": "string"

After doing some research about the concept I opened the subnet configuration in the Azure portal I noticed that I can select API Management from the pulldown. In the online documentation I cannot find any information about the benefits for selecting this option. 

If you integrate an API Management service in an internal network and you route the internet traffic through an Azure Firewall you will have to make quit what adjustments in the terms of route tables and NSGs. These are documented in the common network configuration issues section of the page which describes How to use Azure API Management with virtual networks. So using subnet delegation whould be nice if it solves this common issues.

Microsoft support

Because I could not find any information in the Microsoft documentation and I had not the time to do R&D with this setting I opened a support call. The conclusion of the communication with the support engineer is as follows:

  • The subnet delegation setting is doing anything currently (November 2020).
  • The idea is that when Microsoft have the implementation backing it you would delegate the subnet to the service and Microsoft will enforce the policies as defined in the Common Network Configuration Issues so the API Management service will stay operating.


Popular posts from this blog

CS8357: The specified version string contains wildcards, which are not compatible with determinism.

Today I was busy with creating a WCF service solution in Visual Studio Enterprise 2017 (15.9.2). In this solution I use a few C# class libraries based on .NET 4.7.2. When I compiled the solution I got this error message: Error CS8357: The specified version string contains wildcards, which are not compatible with determinism. Either remove wildcards from the version string, or disable determinism for this compilation The error message is linking to my AssemblyInfo.cs file of the Class library projects. In all the projects of this solution I use the wildcard notation for generating build and revision numbers. // Version information for an assembly consists of the following four values: // // Major Version // Minor Version // Build Number // Revision // // You can specify all the values or you can default the Build and Revision Numbers // by using the '*' as shown below: // [assembly: AssemblyVersion("1.0.*")] [assembly: AssemblyVersion("1.0.

Fixing HTTP Error 401.2 unauthorized on local IIS

Sometimes the Windows Authentication got broken on IIS servers so you cannot log in locally on the server. In that case you get the dreadfully error message HTTP Error 401.2 - Unauthorized You are not authorized to view this page due to invalid authentication headers. To fix this issue you can repair the Windows Authentication feature with the following PowerShell commands: Remove-WindowsFeature Web-Windows-Auth Add-WindowsFeature Web-Windows-Auth

Assign an existing certificate to your IIS website with WiX

Recently I had to change the bindings of existing IIS hosted websites and APIs from HTTP to HTTPS. They are installed with a MSI file created with the WiX Toolset . Because I have to use an already on the server installed certificate I cannot use the Certificate element from the IIS Extension because this element only supports installing and uninstalling certificates based on PFX files. After doing some research I found the blog article Assign Certificate (Set HTTPS Binding certificate) to IIS website from Wix Installer which described the usage of Custom Actions for this purpose. I adopted this approach and rewrote the code for my scenario. With WiX I still create the website. <iis:WebSite Id="WebSite" ConfigureIfExists="yes" AutoStart="yes" Description="MyWebsite" Directory="IISROOT" StartOnInstall="yes"> <iis:WebAddress Id="WebSite"