URL Routing with Azure Application Gateway

Update (13-06-2017):  The POC of this article is available on GitHub here.

I have a scenario perfect for a Layer-7 Load Balancer / Reverse Proxy:

On paper, Azure Application Gateway can do all of those.  Let’s fine out in practice.

Azure Application Gateway Concepts

From the documentation:

Application Gateway is a layer-7 load balancer.  It provides failover, performance-routing HTTP requests between different servers, whether they are on the cloud or on-premises. Application Gateway provides many Application Delivery Controller (ADC) features including HTTP load balancing, cookie-based session affinity, Secure Sockets Layer (SSL) offload, custom health probes, support for multi-site, and many others.

Before we get into the meat of it, there are a bunch of concepts Application Gateway uses and we need to understand:

On top of those, we should probably add probes that are associated to a back-end pool to determine its health.

Proof of Concept

As a proof of concept, we’re going to implement the following:

image

We use Windows Virtual Machine Scale Sets (VMSS) for back-end servers.

In a production setup, we would go for exposing the port 443 on the web, but for a POC, this should be sufficient.

As of this writing, there are no feature to allow automatic redirection from port 80 to port 443.  Usually, for public web site, we want to redirect users to HTTPS.  This could be achieve by having one of the VM scale set implementing the redirection and routing HTTP traffic to it.

ARM Template

We’ve published the ARM template on GitHub.

First, let’s look at the visualization.

image

The template is split within 4 files:

We’ve configured the VMSS to have public IPs.  It is quite typical to want to connect directly to a back-end servers while testing.  We also optionally open the VMSS to RDP traffic ; this is controlled by the ARM template’s parameter RDP Rule (Allow, Deny).

Template parameters

Here are the following ARM template parameters.

Parameter Description
Public DNS Prefix The DNS suffix for each VMSS public IP. They are then suffixed by ‘a’, ‘b’ & ‘c’.
RDP Rule Switch allowing or not allowing RDP network traffic to reach VMSS from public IPs.
Cookie Based Affinity Switch enabling / disabling cookie based affinity on the Application Gateway.
VNET Name Name of the Virtual Network (default to VNet).
VNET IP Prefix Prefix of the IP range for the VNET (default to 10.0.0).
VM Admin Name Local user account for administrator on all the VMs in all VMSS (default to vmssadmin).
VM Admin Password Password for the VM Admin (same for all VMs of all VMSS).
Instance Count Number of VMs in each VMSS.
VM Size SKU of the VMs for the VMSS (default to Standard DS2-v2).

Routing

An important characteristic of URL-based routing is that requests are routed to back-end servers without alteration.

This is important.  It means that /a/ on the Application Gateway is mapped to /a/ on the Web Server.  It isn’t mapped to /, which seems more intuitive as that would seem like the root of the ‘a’ web servers.  This is because URL-base routing can be more general than just defining suffix.

Summary

This proof of concept gives a fully functional example of Azure Application Gateway using URL-based routing.

This is a great showcase for Application Gateway as it can then reverse proxy all traffic while keeping user affinity using cookies.


6 responses

  1. Lance 2017-05-08 at 15:00

    This looks familiar! :)

    >

  2. Turner Bass 2018-06-28 at 11:24

    This has been really helpful, but I think it is worth noting the “Override Backend Path” feature that is available now which allows the /a/ route to be / when it gets to the server.

    So for instance, using the Resource Manager, if I want my /a/ route to actually hit the default / route on the server it is pointed to, I would go to my Backend HTTP Settings and fill in the “Override Backend Path” with / then in the Rule I was using set the HTTP Setting for that path to be the HTTP Settings I made the override on. So the functionality is at least there if it is needed. This would make “mydomain.com/a/” still look like “mydomain.com/a/” but route to “mydomain.com” behind the scenes.

  3. Vincent-Philippe Lauzon 2018-06-28 at 13:20

    Interesting. I believe that didn’t exist when I wrote that blog.

    I can’t find it in the ARM template (https://docs.microsoft.com/en-ca/azure/templates/microsoft.network/applicationgateways). Could you please point me to the property you are referring to?

  4. Turner Bass 2018-07-03 at 10:06

    Yes definitely! It gets a little confusing because in the GUI Resource manager it is called “Override Backend Path” but in the template you are referencing it is just called “path” as part of the BackendHttpSettings object. It’s located at

    backendHttpSettingsCollection:properties:path

    However, I’d like to point out about it is that when overriding the backend path. I thought I could use it like “mydomain.com/a” without the trailing “/” but currently to get the request to be routed properly you have to have the trailing “/” like “mydomain.com/a/” or it won’t go through.

  5. Vincent-Philippe Lauzon 2018-07-20 at 10:53

    Thank you!

    You just helped me & a colleague since a customer wanted to do just that.

    My colleague found a quickstart template documenting it here: https://github.com/Azure/azure-quickstart-templates/tree/master/201-application-gateway-path-override.

  6. Turner Bass 2018-07-26 at 17:46

    That’s awesome! I’m glad to help and glad that you were able to solve a problem for someone.

Leave a comment