In the previous blog post I covered an overview of Azure Application Gateway and a design scenario with Azure App Service (without App Service Environment). This blog post will go through an overview of the key configuration settings of this design.

High level steps and key configuration settings

1. App Service Plan
2. App Service within the existing plan
   1. Deploy your app
3. Azure SQL Server
   1. Firewall Settings
      Set Allow access to Azure Services to ON
      
      Restrict traffic from the public internet to only within Azure network.
4. Azure SQL
   1. Add to the existing Azure SQL Server
   2. Deploy your application’s database
5. Virtual Network
   1. Subnet for App Gateway
6. Public IP
   Used for the App Gateway – Frontend IP Configuration
7. Application Gateway
   1. Configuration
      
   2. Web Application Firewall
      Enabled
      
      You have the ability to disable any specific rule. This comes in handy when a rule provides false flags.
   3. Front End IP Configuration
      
   4. Listeners
      (Multi-site)
      
      Recommend multi-site, that is, with hostnames to support multiple applications. Note: Listeners go by order of the listing. To reorder, need to delete and add new. Learned from experience.
   5. Backend Pool
      
      Set the FQDN of your azure app service web app.
   6. Http Setting
      
   7. The appserviceCertrkim is the public certificate I pulled from the browser when accessing the site.
      
      More set of instructions here
   8. Rules
      Rule1
      
      Rule 2
      
      This 2nd rule is configured to do Http 302 redirects to the Https listener (i.e. https://rkim.ca). You can’t notice the redirection configuration as it was done through PowerShell. For more info click here.
8. Azure App Service
   1. Set IP Restriction
      
      Only allow the Public IP of the App Gateway

9. A DNS record in the public DNS server (e.g. GoDaddy) of the domain to points to the Public IP that is set in the App Gateway Frontend IP Configuration

Verify

1. App Gateway Backend Health
   Go to blade 
   
   This confirms the custom probe from App Gateway to the Azure App service is healthy. And not traffic from the end user.

2. In command prompt, ping the public domain/dns so that the DNS server is resolving the expected IP. Otherwise the web app can show as being timed out in the browser.
3. Visit http://<name>.azurewebsites.net and https://<name>.azurewebsites.net so that you see
   
4. Go to web app’s URL and test http to https redirect to see the site load.
5. Finally, go to the web app’s https URL to see the site load.

 Conclusion

This design is useful in scenarios where many web applications and virtual machines need to be protected and network traffic managed by a single app gateway and firewall. And also don’t have the security and budget needs of an App Service Environment. I favour the web application firewall to protect against vulnerabilities where a typical development team may not have the full security expertise. And so this is a great start for those starting out with a PaaS design pattern.