Why (and what) to plan in Application Gateway?
If you maintain one or two applications things are relatively simple. Though believe some planning would be useful there too. But if you need to support dozens of applications planning becomes critical...
A different post Azure Application Gateway - Sharing is Good discusses how and why you may decide to share Azure Application Gateway between multiple applications. This post will discuss what planning is needed to make sure those deployments are consistent, support automation and maintainable. Unfortunately I did not find Microsoft documentation that would advise on this (it may exist but I simply did not see it) so I had to come up with my own.
Believe following items require planning in enterprise Application Gateway deployment:
Supported scenarios: For example we always split public flows from intranet and therefore never provision Application Gateway with both Public and Private IP. Understanding scenarios and required configurations we need to support defines our scope and allows to reduce complexity of our design and automation.
Automation approach: How different configurations are deployed? For example initial deployment may always include one listener and rule and additional listeners and rules are added one at a time by subsequent automation. This reduces number of different scenarios your automation needs to support.
Naming conventions: What naming conventions to you need to use to ensure the sharing of Application Gateway by multiple applications is viable and supportable?
Scalability and Infrastructure: What size should you allocate for gateway subnet?
I am sure there is more to consider and this section will expand but this is where I stand atm. :)
Ports
This day and age we always start with https. That is our initial provision of any application into Application Gateway will always start with https protocol. Ideally we leverage https end-to-end but to support older applications back-end protocol can be selected http. But front-end protocol is always https - for every initial provision.
It still happens that some older clients require http. Therefore we will include this into the list of supported scenarios. But consider this an add-on to initial standard https frond-end configuration.
Deployment Approach
We have many options to automatically provision and configure resources in Azure. In my case we use mostly Azure Resource Manager templates, PowerShell with some Azure CLI and Ansible in the mix.
The following approach works the best for us
Azure Resource Manager templates for initial deployment (e.g. initial provision of Application Gateway and the first application)
PowerShell (or Azure CLI scripts) for subsequent maintenance (adding application or adding ports to existing applications published via Azure application Gateway)
Components and Naming Conventions
Naming conventions ensure your deployments can be automated so that shared components are automatically discovered/re-used by the code and the names of non-shared components do not conflict within the same namespace.
The problem as I see it is that the namespace in Application Gateway is flat. There is no notion of "application-specific" configuration items vs "global/shared" configuration items. As it stands today for example I consider listener "application-specific" while front-end port "global/shared"a and therefore my listener naming convention is
"Listener_${appName}_${frontendPort}" whereas the port naming convention is "FrontendPort_$frontendPort" (where $frontendPort is port number (e.g. 443,80))
Microsoft published very useful documentation including diagrams that shows relationships between components of Application Gateway.
But the issue of single shared flat namespace shared by all Application Gateway components remains. The scope levels and the resulting naming convention that works for me currently are below. All names are automatically generated and designed to avoid collisions and facilitate further automation (e.g. automation of removing applications from Application Gateway)
For simplicity I have put FQDN or certificateSubject name as the part of Listener or Rule name. In reality those are converted to fit the naming constraints (e.g. periods (".") in FQDN are replaced with underscores("_"))
Global Names
$frontEndIPConfigName="appGatewayFrontendIP"
$frontEndPortName="frontendPort_$frontendPort"
Front-End Configuration
$httpsRuleName = "Rule_${appname}_${frontendPort}"
$httpsRuleName="Rule_${appname}_${frontendPort}"
Back-End Configuration $appGwHttpsListenerName = "Listener_${appName}_${frontendPort}" $appHealthProbeName = "healthProbe_${appname}_${backendPort}"
$backendPoolName = "backEndPool_${appname}_${backendPort}"
$HttpSettingsName = "HttpSettings_${appname}_${backendPort}"
Scalability, Sizing
The limitations of Application Gateway are documented in
For sizing of Application gateway subnets worth to take into account the actual number of ip addresses required by Application Gateway.
"Application Gateway consumes one private IP address per instance, plus another private IP address if a private frontend IP configuration is configured. "
If you have 27 instances and an IP address for the private frontend IP configuration, then Application Gateway will require 28 IP addresses - 27 IP addresses for the 27 instances of the application gateway, one IP address for private frontend IP.
Microsoft documentation Azure virtual network and dedicated subnet provides examples of Application Gateway ip address requirements and respective subnet sizing.
Limitations
Monitoring
As far as I observed and confirmed from Microsoft support currently there is no way to monitor traffic destined to Application Gateway front-end IPs in Network Watcher Flow logs. Application Gateway instance IPs will show up but not the front-end IPs.
Application Gateway logs can be helpful but not in case when traffic is blocked by NSG rules.
Code
The functions as they stand today are still being worked on can be found in GitHub : azure-arm-application-templates/avl-appgw-01 and Azure-automation/ApplicationGateway . As usual use at your own risk. :)
Comments