When to use Azure Application Gateway

Is Application Gateway the right load balancing solution for your project?

Photo by Camylla Battani on Unsplash

Azure Application Gateway is an application layer (OSI layer 7) load balancer. It offers a range of functionalities such as routing based on various attributes of HTTP requests, HTTP header rewrites, Azure Web Application Firewall (WAF) and SSL termination. However, it does come at a price and it can be a bit daunting to configure.

The aim of this article is to help you decide if Application Gateway is the right solution for you and how you can configure it. It’s based on my experience with setting up an Application Gateway that routes traffic to a Service Fabric cluster and highlights some issues that may occur with this configuration. It took me a while to figure it out so I decided to write this up in order to help others who might face similar struggles.

What Application Gateway has to offer

1. Load balancing. Application Gateway performs load balancing on the application layer. Similar functionality can be achieved using the Azure Load Balancer. The main difference is that Load Balancer performs load balancing on the transport layer (TCP or UDP) which means it can’t offer the same additional possibilities as Application Gateway. It’s also good to note that both of these components perform load balancing within one Azure region. If you need load balancing across multiple regions, you should consider Azure Traffic Manager.
2. You can enable autoscaling. It means you don’t have to choose a deployment size or instance count when provisioning your resources. Application gateway can scale up or down based on traffic patterns.
3. Routing. Application Gateway offers custom routing possibilities. It can route requests to different backend pools you have or any external URLs. The routing can be based on port number, host name, path or other HTTP headers. Most of these possibilities aren’t available through Azure Load Balancer since it operates on the transport layer and doesn’t access HTTP headers. For routing options beyond Application Gateway, you can look into Azure API Management.
4. Header and URL rewrites. Application Gateway offers pretty useful header rewrite possibilities for both requests and responses. It can set or modify both common and custom HTTP headers as well as URLs. Rewrites can be conditional (for instance, based on the content or presence of some header) and applied to specific routing rules.
5. Azure Web Application Firewall. You can choose Application Gateway with WAF that protects your web applications from common vulnerabilities.

If you’re aiming to use Application Gateway to route traffic to a Service Fabric cluster, it will also enable you to direct traffic directly to Service Fabric’s reverse proxy. That means you won’t have to deploy all your services to every node as the reverse proxy will be able to appropriately distribute traffic to other nodes. This is a great advantage over using Azure Load Balancer which operates on TCP and won’t be able to approach your services through the reverse proxy. This often calls for the use of API gateway pattern (which includes writing a custom service).

There’s a number of other functionalities that might come in handy, such as connection draining or zone redundancy. You can find more about these in the official documentation.

Things you should know before you decide to use Application Gateway

1. It comes at a price. Make sure to check out the pricing of this resource before committing to use it. And don’t forget to scroll all the way down to the bottom of the pricing page where a table for monthly prices of the Standard_v2 Application Gateway.. It’s quite likely you’ll need this tier of Application Gateway as it seems to be the only one that offers a static IP address. Monthly cost of this instalment could amount to a few hundred dollars a month so it’s good to assess this is within your budget before you begin. You can find official documentation with pricing specifications here: https://azure.microsoft.com/en-us/pricing/details/application-gateway/
2. It can’t route traffic to non-HTTP endpoints. If you’re hoping to route traffic to your TCP or UDP endpoint using Application Gateway, you might want to rethink. Application Gateway can only route traffic to endpoints for which it can perform successful health probes. And it can only perform health probes using HTTP/HTTPS. Any endpoints that don’t accept traffic via these protocols will be inaccessible through Application Gateway.
3. If you’re trying to connect Application Gateway to your Service Fabric cluster, bear in mind that the cluster has a client connection endpoint which is a TCP endpoint. If you need to use this endpoint, you will have to connect an additional (layer 4) Load Balancer to your cluster in order to use it.
4. It doesn’t offer mutual SSL. Application Gateway offers both SSL termination at the gateway and end-to-end SSL communication to your backend pool. But it has no support for mutual SSL, which means you’re going to have to authenticate your callers in a different way. Perhaps you can leverage using JSON web tokens that can be passed through HTTP headers and validated in your service. But Application Gateway currently doesn’t offer help on this end.

It’s also good to keep in mind that Application Gateway doesn’t offer a limitless number of listeners, routing rules, authentication certificates, etc. So it’s worth going through the list of limitations in the official documentation to watch for possible issues before selecting this component. I imagine these limits won’t present an issue for most use cases, but it’s worth double-checking before you commit to this component.

I hope this article was helpful for getting a better understanding of the various capabilities and possible issues with Application Gateway. This article is based on my experience with Application Gateway — for the exact information and most recent updates on this component, be sure to check out the official documentation.

Thank you for reading!