In the last article, we looked at load balancing traffic in Azure with the new Standard Load Balancer. That all happens at Open Systems Interconnection (OSI) layer 4 for TCP and UDP traffic, but what if you want to look at application traffic at layer 7 (HTTP and HTTPS)? That's when the Application Gateway (AG) and the Web Application Firewall (WAF) come into play. In this article we'll look at their uses and how to set them up.

Application Gateway

AG is an umbrella term for a virtual appliance that provides application delivery control (ADC) as a platform service (PaaS) in Azure. It has the following features:

  • WAF as an option
  • HTTP(S) round-robin load balancing
  • cookie-based session affinity
  • SSL (TLS really) offloading with optional TLS re-encryption to the backend
  • URL-based and multi-site routing, diagnostics, and monitoring
  • HTTP to HTTPS redirection
  • WebSocket support
  • SSL policies

AG supports multi-tenant PaaS services such as Azure Web Apps and API gateway. AG can work with the Standard or Basic load balancer we looked at in the last article.

AG comes in three sizes: small, medium, and large. Here's a comparison of approximate throughput figures, based on page response sizes. Pricing is available here.

Backend page response Small Medium Large
6K 7.5 Mbps 13 Mbps 50 Mbps
100K 35 Mbps 100 Mbps 200 Mbps

(Table courtesy of Microsoft)

If you're expecting larger traffic volumes, you can deploy multiple AGs to share the load. Note that there's no automatic scaling as load increases. However, you can set alerts, and when reaching a threshold, you can add instances or change the AG size, neither of which affects existing traffic.

AG supports HTTP/2 for the front-end connection only (traffic to your backend endpoints is over HTTP 1.1), but it's not enabled by default. Here's the PowerShell code to enable it:

$gw = Get-AzureRmApplicationGateway -Name yourAG -ResourceGroupName RGName$gw.EnableHttp2 = $trueSet-AzureRmApplicationGateway -ApplicationGateway $gw

You must deploy AG in a vNet, into its own subnet, which can only house other AGs and no other resources. You can have up to 20 sites behind a single AG, and your backend pool can comprise NICs, VM scale sets, public IPs (one per AG), internal IPs (one per AG), Azure Web Apps, and fully qualified domain names (FQDNs). You can add members from different clusters, data centers, or even outside of Azure as long as they have IP connectivity. You can use AG to direct traffic for different URLs to different backend resources (/videos to a different pool for instance). AG supports redirection for HTTP to HTTPS; you can also redirect based on a path (/cart/) or even redirect to an external site.

AG monitors the health of your backend resources to avoid directing traffic to unhealthy nodes. You can either use the default health probe monitoring or customize it. Like all PaaS services, AG has some scaling limits.

Security options

Using SSL policies, you can control the minimum TLS level (1.0, 1.1, 1.2, or 1.3). SSL 2.0 and 3.0 are disabled and cannot be re-enabled. Recently, Microsoft added the ability to pick individual cipher suites either allowed or denied. There are three pre-defined templates:

  • AppGwSslPolicy20170401S
  • AppGwSslPolicy20170401
  • AppGwSslPolicy20150501

The first is the most restrictive. You can also create your own, specifying a minimum protocol version, which cipher suites to support, and in which order to process them.

If you need to demonstrate full encryption end to end, you can set up AG to re-encrypt your traffic on a per-backend pool basis.

The Open Web Application Security Project (OWASP) publishes a list of common attacks on websites to help developers and operations protect their web properties better. The WAF part of AG supports the core rule sets 2.2.9 or 3.0. They've recently added the ability to disable groups of rules (if you don't have a backend database, SQL injection doesn't apply for instance) or individual rules that might trigger false positives for your particular websites.

You can run the WAF in detection mode where it logs all threat alerts to a log file but doesn't interfere with your traffic. This is useful to make sure rules don't accidentally interfere with a valid function of your site. You can also run it in prevention mode where rules triggered will block intrusions (as well as logging the attack). Note that WAF is only available in the medium and large sizes of AG. The WAF logs to Azure Monitor, and you can also integrate it with Azure Security Center.

Customizing WAF rules

Customizing WAF rules

Deploy an Application Gateway

You can use PowerShell, the command-line interface (CLI), or the portal to deploy an AG. Here, I'll use the portal. Click on New resource > Networking > Application Gateway. Give it a name and create a new resource group (RG). If you're continuing from the last article, you can use the same RG and vNet. You just need to create a new subnet in the vNet for the AG.

Creating an Application Gateway Step 1

Creating an Application Gateway Step 1

In the second stage of the wizard, pick your vNet and empty subnet (or create new ones), and pick a DNS name for your public endpoint. If you select HTTPS, you'll need to upload your SSL certificate to the AG. You can also enable the WAF.

Creating an Application Gateway Step 2

Creating an Application Gateway Step 2

The last step summarizes your choices before you hit Create to deploy the AG. This can take some time (Microsoft mentions 20 minutes—mine took about 22 minutes).

After deploying it, you'll need backend resources. Again, if you followed along in the Azure Load Balancer article, you'll already have two VMs with IIS. Otherwise, you'll need to create these (in the same vNet as the AG, but not in the same subnet). In the settings for the AG, pick backend pool (there's already one by default) and add your two VMs.

Adding your VMs to the backend pool

Adding your VMs to the backend pool

A rule (rule1) will also already exist, which you can customize. The final test is going to the overview tab for the AG, finding your public IP address, and pasting it into a new browser tab. The default IIS page should appear.

Options, options

If I had to use a single sentence to describe networking in Azure, I'd say it's very flexible and has a lot of options. How do you pick the right solution for your scenario from the services we covered in the last article and this one?

If you're looking to route OSI layer-4 traffic (TCP/UDP) to Azure infrastructure-as-a-service (IaaS) VMs or Cloud Services, the Basic/Standard load balancer is your friend. It gives you full 5-tuple (source IP, source port, destination IP, destination port, protocol type) load balancing control. If you need to balance OSI layer-7 (HTTP/HTTPS/WebSocket) traffic for Azure IaaS VMs, Cloud Services, or public/internal IP address endpoints using round-robin or URL routing with optional cookie-based affinity, AG is the best solution. If you have a presence in multiple Azure regions, use Traffic Manager to distribute the traffic to the nearest location. And if your needs overlap, you can combine two or three of these services.

It's also worth noting that the Azure marketplace has hundreds of third-party network virtual appliances (NVAs) for application gateway, WAF, and load-balancing functionality. They often come with more functionality than the platform services, and of course you can select them to match devices you're already using on premises. In general, they're also much more expensive to run than the built-in services.

Subscribe to 4sysops newsletter!

Rounding off this series of articles covering different aspects of Azure networking, the upcoming last article will look at ExpressRoute, what's new, and how you can monitor it.

Articles in seriesAzure networking

Leave a reply

Please enclose code in pre tags

Your email address will not be published.


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account