Azure Application Gateway with Terraform: WAF, Path-Based Routing, and Production Patterns

Terraform makes it possible to define, preview, and deploy Azure Application Gateway infrastructure as code using HCL syntax. Configuration files specify the cloud provider and the elements that make up the cloud infrastructure. After creating configuration files, an execution plan can be created to preview infrastructure changes before they are deployed. Once verified, the execution plan is applied to deploy the infrastructure.

Application Gateway is a web traffic load balancer that helps manage traffic to web applications. Routing decisions can be based on factors that include round-robin, cookie-based sessions, and more. As a Layer 7 load balancer service provided by Microsoft Azure, Application Gateway enables management and optimization of traffic to web applications. It is like the traffic cop of web applications, acting as a central point for managing and optimizing traffic to ensure they are secure, highly available, and performant.

Core Architecture and Features

Application Gateway is a Layer 7 load balancer that lets you route HTTP and HTTPS traffic based on URL paths, hostnames, and other request attributes. Path-based routing is one of its most useful features. Requests such as /api/* can be sent to an API backend and /* to a web frontend, all through a single public IP and SSL certificate.

Key capabilities include:

Load Balancing: It distributes incoming network traffic across multiple servers to ensure even utilization and prevent overloading any single server. This results in better performance and fault tolerance.
Web Application Firewall: Azure Application Gateway comes with a built-in web application firewall that helps protect web applications from common web exploits and vulnerabilities.
SSL termination, URL routing, and auto-scaling.
Diagnostic logging integration with Azure Monitor and Log Analytics for comprehensive cloud observability.

The quickstart workflow for a WAF enabled deployment creates a resource group, virtual network, subnet within the virtual network, public IP address, and a WAF policy with custom rules to block traffic from a specific IP address. The Standard v2 SKU is used in this example.

Application Gateway frontend now supports dual-stack IP addresses. This capability is in Preview.

WAF v2 Policy with Terraform

Creating an Azure Application Gateway with an Azure Web Application Firewall v2 policy via Terraform requires coordinated resources.

Resource	Purpose
Resource Group	Container for all resources
Virtual Network	Network isolation for Application Gateway
Subnet	Application Gateway deployment subnet
Public IP Address	Frontend public endpoint
Web Application Firewall Policy	WAF v2 policy with custom rules
Application Gateway	Layer 7 load balancer with WAF

A typical quickstart creates the WAF policy first, then references it in the Application Gateway configuration. Custom rules can block traffic from a specific IP address. The Application Gateway can pull certificates directly from Key Vault, which simplifies rotation.

Example HCL pattern for provider and resource group:

```hcl
terraform {
required_providers {
azurerm = {
source = "hashicorp/azurerm"
version = "~> 4.0"
}
}
}

provider "azurerm" {
features {}
}

resource "azurermresourcegroup" "example" {
name = "rg-appgw-waf"
location = "eastus"
}
```

Always review the plan before applying. Check that only the expected resources will be created. Terraform will create all resources in the correct order, handling dependencies automatically.

Path-Based Routing Configuration

Deploying Application Gateway through the portal is a maze of blades and dropdowns. Terraform gives you a declarative way to define the whole thing - listeners, backend pools, routing rules, health probes, and path maps - in code that you can review and version.

Architecture overview for path-based routing:

A[Client] --> B[Application Gateway] B --> C{Path-Based Rules} C -->|/api/*| D[API Backend Pool] C -->|/static/*| E[Static Content Pool] C -->|Default| F[Web App Pool] D --> G[API App Service] E --> H[Storage Account] F --> I[Web App Service]

The Full Terraform Configuration includes nested blocks for listeners, backend pools, routing rules, health probes, and path maps. Application Gateway has a lot of nested configuration blocks.

Key settings for backend integration:

Set the pickhostnamefrombackend_address setting to true when your backends are App Services. App Services require the correct Host header to route traffic to the right app.
Size your subnet appropriately. Application Gateway v2 can scale to many instances, and each instance needs IP addresses from the subnet.

Enable diagnostic logging to Log Analytics. Application Gateway access logs are invaluable for debugging routing issues and analyzing traffic patterns.

Terraform Module Usage and AVM Guidance

When using Terraform to deploy Azure resources, you can make use of a Terraform module to define and configure the Azure Application Gateway.

Important guidance for the Azure Verified Modules framework applies:

As the overall AVM framework is not GA yet - the CI framework and test automation is not fully functional and implemented across all supported languages yet - breaking changes are expected, and additional customer feedback is yet to be gathered and incorporated.
Hence, modules MUST NOT be published at version 1.0.0 or higher at this time.
All module MUST be published as a pre-release version e.g., 0.1.0, 0.1.1, 0.2.0, etc. until the AVM framework becomes GA.

It is important to note that this DOES NOT mean that the modules cannot be consumed and utilized. They CAN be leveraged in all types of environments dev, test, prod etc. Consumers can treat them just like any other IaC module and raise issues or feature requests against them as they learn from the usage of the module. Consumers should also read the release notes for each version, if considering updating to a more recent version of a module to see if there are any considerations or breaking changes etc.

Production Best Practices and Validation

Set up monitoring from day one:

Configure Azure Monitor, Log Analytics, and alerts with Terraform for comprehensive cloud observability.
Configure diagnostic settings to ensure robust monitoring and troubleshooting.

After applying, verify your resources are running correctly:

Validate resources within the Azure portal to confirm that everything is functioning as expected.
Test the application gateway to make sure it works correctly.

Terraform enables the definition, preview, and deployment of cloud infrastructure. Using Terraform, you create configuration files using HCL syntax. The HCL syntax allows you to specify the cloud provider - such as Azure - and the elements that make up your cloud infrastructure. After you create your configuration files, you create an execution plan that allows you to preview your infrastructure changes before they're deployed.

Managing Azure resources with Terraform brings consistency, version control, and automation to your infrastructure. The configurations follow production best practices and can be extended to match specific requirements. Start with these foundations and iterate as infrastructure needs evolve.

Conclusion

Azure Application Gateway with path-based routing gives fine-grained control over how traffic reaches backends. By defining it all in Terraform - the networking, backend pools, path maps, probes, and routing rules - you get a repeatable and reviewable infrastructure definition. The configuration is verbose, but each section has a clear purpose, and once it is in place, adding new paths and backends is a straightforward extension of the existing pattern.

A production-ready deployment combines a Standard v2 SKU Application Gateway, WAF v2 policy with custom blocking rules, path-based routing rules, Key Vault certificate integration, and diagnostic logging to Log Analytics. Proper subnet sizing and Host header handling for App Service backends ensure reliable routing. Using Terraform modules, with awareness of AVM pre-release versioning, allows safe reuse while maintaining version control and preview capability for all changes.