Azure Application Gateway Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking

1. Introduction

Azure Application Gateway is Azure’s managed, Layer 7 (HTTP/HTTPS) load balancer designed for modern web applications. It helps you publish web workloads securely and reliably by routing incoming HTTP(S) traffic to the right backend targets based on hostnames, paths, headers, and other request attributes.

In simple terms: Azure Application Gateway sits in front of your web apps and APIs, provides a single entry point (public or private), and forwards requests to backend services while handling capabilities like TLS termination, health probes, cookie-based affinity, and (optionally) a Web Application Firewall (WAF).

Technically, Azure Application Gateway is deployed into your virtual network (VNet) within a dedicated subnet and acts as a reverse proxy. It evaluates listeners and routing rules, performs health probing, supports autoscaling (v2 SKUs), can do end-to-end TLS to backends, and emits rich diagnostics to Azure Monitor. It integrates with Azure networking primitives like public/private IPs, subnets, network security groups (NSGs), Private Link patterns (where applicable), Azure Key Vault for certificates, and Azure Monitor for logs and metrics.

The core problem it solves is secure, scalable, application-aware traffic management for HTTP(S) workloads. It helps teams avoid building and operating their own reverse proxy tier while meeting requirements such as path-based routing, multi-site hosting, TLS policy enforcement, and WAF protection.

2. What is Azure Application Gateway?

Official purpose (what it is):
Azure Application Gateway is a managed web traffic load balancer (reverse proxy) that enables you to manage and secure HTTP(S) traffic to your web applications.

Core capabilities (what it can do): – Layer 7 load balancing for HTTP/HTTPS. – URL/path-based routing and multi-site (host-based) routing. – TLS termination (SSL offload) and end-to-end TLS to backends. – Web Application Firewall (WAF) capability with WAF SKUs. – Autoscaling and zone redundancy (on supported SKUs/regions; verify current regional support in official docs). – Health probes, connection draining, session affinity (cookie-based), redirects, and header/URL rewrite.

Major components (conceptual building blocks): – Frontend IP configuration: Public IP and/or private IP used by clients to reach the gateway. – Listener: Defines protocol/port (HTTP/HTTPS), hostname (optional), and certificate (for HTTPS). – Backend pool: A set of backend targets (VMs, VMSS, private IPs, FQDNs, App Service via FQDN, etc.; suitability depends on networking and DNS reachability). – HTTP settings: How the gateway connects to backends (port, protocol, timeout, cookie affinity, trusted root certificates for TLS to backend, etc.). – Routing rule: Binds a listener to a backend pool and HTTP settings, optionally using path maps. – Health probe: Determines backend health and removes unhealthy instances from rotation. – (Optional) WAF policy: Managed rules + custom rules + exclusions for application-layer threat protection.

Service type: – Managed Azure networking service (reverse proxy / L7 load balancer). – Deployed inside your VNet (unlike global edge services such as Azure Front Door).

Scope and placement: – Regional service: Deployed into a specific Azure region. – VNet/subnet-scoped deployment: Requires a dedicated subnet in a VNet. – Subscription/resource group managed: You create and manage it as an Azure resource with Azure RBAC, policies, tags, and diagnostics.

How it fits into the Azure ecosystem: – Often paired with: – Azure Virtual Machine Scale Sets (VMSS) for scalable backends. – Azure Kubernetes Service (AKS) via Application Gateway Ingress Controller (AGIC) (integration approach—confirm current guidance; Microsoft also offers “Application Gateway for Containers” as a separate product). – Azure Key Vault for TLS certificates and centralized secret management. – Azure Monitor / Log Analytics for access logs, performance logs, and WAF logs. – Azure Firewall / NSGs / DDoS Protection for layered network security.

3. Why use Azure Application Gateway?

Business reasons

Faster delivery: You avoid building a custom reverse proxy tier and focus on application features.
Reduced operational burden: Managed scaling and built-in health monitoring reduce toil.
Risk reduction: WAF (when used) can reduce exposure to common web attacks.

Technical reasons

Application-aware routing: Route by hostname and URL path to separate services (e.g., /api vs /app).
TLS termination and policy: Enforce modern TLS policies at the edge of your VNet.
End-to-end encryption: Support HTTPS from client to gateway and gateway to backend.
HTTP features: Redirects, rewrites, cookie-based affinity, and WebSocket support (verify specific protocol support details in official docs for your SKU and region).

Operational reasons

Centralized ingress: Standardize how traffic enters your application network.
Observability: Access, performance, and WAF logs can be streamed to Azure Monitor destinations.
Controlled deployments: Update backends independently; the gateway routes to healthy instances.

Security/compliance reasons

WAF protections: Managed rules (OWASP Core Rule Set alignment) and custom rules help meet baseline web security expectations.
Certificate governance: Integrate with Azure Key Vault and automate certificate rotation patterns.
Network isolation: Private frontend IP allows internal-only apps without public exposure.

Scalability/performance reasons

Autoscaling (v2 SKUs): Adjust capacity to traffic demand (subject to SKU behavior and configured limits).
Zone redundancy: Improve resiliency within a region using Availability Zones (where supported).

When teams should choose it

Choose Azure Application Gateway when you need: – HTTP/HTTPS load balancing inside a region and inside a VNet. – Path-based and host-based routing to multiple backends. – TLS termination and/or end-to-end TLS. – WAF protection at the application ingress inside your Azure network.

When teams should not choose it

Consider alternatives when: – You need global, edge-based routing and acceleration across continents: consider Azure Front Door. – You only need Layer 4 TCP/UDP load balancing: consider Azure Load Balancer. – You need API gateway features (auth, rate limiting, developer portal): consider Azure API Management. – You require extreme custom proxy behavior or modules: consider self-managed NGINX/Envoy/HAProxy (with the operational cost tradeoff).

4. Where is Azure Application Gateway used?

Industries

SaaS and ISVs hosting multi-tenant web apps.
Financial services and healthcare needing tighter ingress security and audit logs.
Retail and media handling traffic bursts and requiring predictable routing and TLS controls.
Government and regulated sectors implementing layered network security.

Team types

Platform engineering teams standardizing ingress for multiple product teams.
DevOps/SRE teams needing strong observability and repeatable deployments.
Security engineering teams implementing WAF and TLS policy requirements.
Application teams consolidating routing for microservices.

Workloads

Web applications (monoliths or microservices frontends).
REST APIs (often combined with API Management for full API governance).
Internal line-of-business apps (private frontends).
AKS ingress patterns (via integration controller patterns).

Architectures

Hub-and-spoke VNets with a centralized ingress in a shared services spoke.
Multi-tier applications with backend pools per tier.
Blue/green or canary deployments using separate backend pools and weighted strategies (note: Azure Application Gateway routing is rule-based; advanced traffic shaping is typically better handled by Front Door or service mesh—verify your exact approach).

Real-world deployment contexts

Production: Usually zone-redundant v2 SKUs, WAF enabled where required, diagnostics enabled, Key Vault integration for certs, and strict NSG rules.
Dev/test: Smaller SKUs, fewer listeners/rules, and sometimes disabled WAF to reduce cost (with security risk acceptance).

5. Top Use Cases and Scenarios

Below are realistic scenarios where Azure Application Gateway is commonly used.

Path-based routing for microservices – Problem: Multiple services need one domain entry point. – Why it fits: URL path maps route /api/* to an API backend and /app/* to a web frontend. – Example: contoso.com/app goes to frontend pool; contoso.com/api goes to API pool.
Multi-site hosting (host-based routing) – Problem: Host multiple domains/apps behind one gateway. – Why it fits: Listeners can match hostnames and route to different backend pools. – Example: shop.contoso.com and blog.contoso.com share a gateway but route to separate backends.
TLS termination for simplified backend management – Problem: Managing certificates on dozens of backends is error-prone. – Why it fits: Terminate HTTPS on the gateway and use HTTP to backends (or re-encrypt with a single backend certificate policy). – Example: Rotate certificates centrally via Key Vault without touching backend VM configurations.
End-to-end TLS (gateway to backend HTTPS) – Problem: Compliance requires encryption in transit across internal networks. – Why it fits: Configure HTTPS to backends and validate backend certificates using trusted roots. – Example: PCI-adjacent workloads requiring encrypted hops even inside VNets.
WAF protection for internet-facing apps – Problem: Apps are exposed to OWASP-style attacks (SQLi, XSS, etc.). – Why it fits: WAF policies with managed rules and custom rules can block or detect malicious requests. – Example: Block suspicious query strings and enforce request size limits (confirm exact WAF controls in current docs).
Internal-only application publishing – Problem: Provide a central internal URL for corporate users without internet exposure. – Why it fits: Use a private frontend IP in the VNet; access via VPN/ExpressRoute. – Example: HR portal accessible only from corporate network.
Zero-downtime maintenance with connection draining – Problem: Draining user sessions during deployments is hard. – Why it fits: Connection draining helps reduce user impact while removing instances. – Example: Roll backend VM updates while minimizing active connection disruption.
Session affinity for legacy apps – Problem: Some apps require sticky sessions. – Why it fits: Cookie-based affinity can keep a client pinned to the same backend instance. – Example: Legacy ASP.NET app storing session state in memory.
Rewrite and redirect for clean URL management – Problem: Migrate URL structures without rewriting application code. – Why it fits: Rewrite/redirect rules can modify paths/headers. – Example: Redirect / to /app/ or rewrite /api/v1/* to /api/*.
Centralized ingress for VMSS backends – Problem: Need scalable compute with predictable ingress. – Why it fits: Backend pool points to VMSS; gateway health probes control routing. – Example: Autoscale VMSS for seasonal traffic; gateway routes only to healthy instances.
AKS ingress with existing networking constraints – Problem: Standard Kubernetes ingress controllers don’t meet enterprise network/WAF requirements. – Why it fits: Application Gateway can serve as the ingress point (often via AGIC). – Example: AKS cluster in a spoke VNet uses Application Gateway in a shared services spoke.
Controlled exposure with layered security – Problem: Need network and application security layers. – Why it fits: Combine NSGs, DDoS Protection (where applicable), and WAF policy at the gateway. – Example: Internet-facing app with strict allowlists and WAF in prevention mode.

6. Core Features

This section focuses on widely used, current capabilities. For SKU-specific or preview features, verify in the official docs for your selected SKU and region.

Layer 7 HTTP/HTTPS load balancing

What it does: Distributes HTTP(S) requests across backend targets.
Why it matters: Enables horizontal scaling and high availability.
Practical benefit: Backends can be added/removed without changing client endpoints.
Caveats: Backend targets must be reachable from the gateway subnet; DNS and NSG rules must allow it.

URL path-based routing

What it does: Routes requests based on URL path patterns.
Why it matters: Consolidates multiple services behind one domain/IP.
Practical benefit: Reduce public endpoints and simplify DNS/TLS.
Caveats: Path matching behavior and precedence rules matter; test thoroughly.

Multi-site (host-based) routing

What it does: Routes by HTTP Host header / SNI hostname for HTTPS.
Why it matters: Host multiple apps/domains behind one gateway.
Practical benefit: Consolidate ingress infrastructure and reduce cost/complexity.
Caveats: Requires careful certificate/SNI configuration for HTTPS.

TLS termination (SSL offload) and TLS policy

What it does: Handles HTTPS handshakes and encryption at the gateway, optionally forwarding to backends over HTTP or HTTPS.
Why it matters: Centralizes certificate and cipher/TLS policy management.
Practical benefit: Reduce certificate sprawl and enforce minimum TLS versions.
Caveats: If you terminate TLS and forward HTTP, internal traffic is unencrypted (may violate compliance requirements).

End-to-end TLS (re-encryption to backend)

What it does: Keeps HTTPS from client to gateway and gateway to backend.
Why it matters: Encrypts traffic in transit on internal networks.
Practical benefit: Supports stricter security controls and compliance.
Caveats: You must manage backend certificates and configure trusted roots/validation appropriately.

Web Application Firewall (WAF) (WAF SKUs)

What it does: Detects and blocks common web attacks using managed rules and custom rules.
Why it matters: Reduces risk from OWASP Top 10-style attacks.
Practical benefit: Security baseline without deploying separate WAF appliances.
Caveats: Tuning is required to reduce false positives; run in detection mode first in many environments.

Autoscaling (v2 SKUs)

What it does: Scales gateway capacity based on traffic demand.
Why it matters: Helps handle bursts without manual scaling.
Practical benefit: Operational simplicity.
Caveats: Autoscaling affects cost; define capacity boundaries per your reliability and budget targets (verify exact scaling parameters in current docs).

Zone redundancy (supported regions/SKUs)

What it does: Spreads gateway instances across Availability Zones.
Why it matters: Better resilience to zone-level failures.
Practical benefit: Higher availability without multi-region design.
Caveats: Not all regions support zones; verify availability.

Health probes

What it does: Periodically checks backend health via HTTP(S).
Why it matters: Prevents routing traffic to unhealthy instances.
Practical benefit: Faster recovery from partial failures.
Caveats: Probe path, host header, and expected status codes must match app behavior.

Connection draining

What it does: Allows existing connections to complete when a backend is removed.
Why it matters: Reduces user disruption during deployments/maintenance.
Practical benefit: Smoother rolling updates.
Caveats: Not a substitute for application-level graceful shutdown; verify timeouts.

Cookie-based affinity (session stickiness)

What it does: Pins a client to a backend instance using a cookie.
Why it matters: Supports stateful legacy apps.
Practical benefit: Avoids session loss when session state isn’t shared.
Caveats: Can reduce load distribution efficiency; prefer stateless patterns if possible.

Redirects and rewrites

What it does: Redirect HTTP to HTTPS, or rewrite URLs/headers.
Why it matters: Supports migration, canonical URLs, and security patterns.
Practical benefit: Avoid app code changes for some routing needs.
Caveats: Overuse can complicate debugging; document rewrite rules carefully.

Private frontend

What it does: Uses a private IP so the gateway is reachable only within private networks.
Why it matters: Internal-only applications and private APIs.
Practical benefit: Reduced external attack surface.
Caveats: Requires private connectivity (VPN/ExpressRoute/peering) to reach it.

Diagnostics and monitoring integration

What it does: Publishes metrics and logs to Azure Monitor; can stream logs to Log Analytics, Storage, or Event Hubs.
Why it matters: Operational insight and security auditing.
Practical benefit: Build dashboards, alerts, and incident runbooks.
Caveats: Logging can add cost (Log Analytics ingestion/retention).

7. Architecture and How It Works

High-level service architecture

Azure Application Gateway is deployed into a dedicated subnet within your VNet. Clients connect to its frontend IP (public or private). The gateway selects a listener (based on IP/port/protocol/hostname), evaluates routing rules (basic or path-based), optionally applies WAF inspection (for WAF SKUs / WAF policies), and forwards the request to a backend target in a backend pool according to the configured HTTP settings and probe health.

Request/data/control flow (conceptual)

Data plane (runtime traffic): 1. Client resolves DNS to the gateway frontend IP. 2. Client connects (HTTP/HTTPS) to the listener. 3. (Optional) WAF evaluates request against policies. 4. Routing rules choose backend pool and HTTP settings. 5. Gateway sends request to a healthy backend. 6. Backend response returns through the gateway to client.
Control plane (management):
Azure Resource Manager (ARM) manages configuration updates.
Azure Monitor collects metrics/logs and sends to configured destinations.
Azure RBAC controls who can modify configurations.

Integrations with related Azure services

Azure Key Vault: Store TLS certificates; gateway can reference Key Vault secrets (requires appropriate identity and permissions).
Azure Monitor / Log Analytics: Collect access logs, performance logs, and WAF logs.
Network Security Groups (NSGs): Control allowed flows between gateway subnet, backend subnet, and other networks.
Azure DDoS Protection: Often applied at the VNet level for internet-facing workloads (where appropriate).
AKS: Application Gateway can be used as an ingress point through controller-based integration patterns (verify current recommended architecture).

Dependency services

Virtual network and dedicated subnet.
Frontend IP resource (public IP for internet-facing).
Backend compute (VM/VMSS/containers/App Service endpoints reachable from gateway).
DNS zone/records (public or private) for friendly names.

Security/authentication model

Management uses Azure AD + Azure RBAC.
Data plane is HTTP/HTTPS; application auth is handled by your app (OIDC, cookies, tokens) unless you add a separate identity-aware proxy service. Application Gateway is not an identity provider.

Networking model

Gateway lives inside your VNet.
You must plan IP addressing carefully:
Dedicated subnet for the gateway.
Sufficient IPs for scaling (especially important for v2 autoscaling; verify guidance in official docs).
NSGs and user-defined routes (UDRs) must be designed carefully to avoid breaking required flows (verify required ports and health probe behavior).

Monitoring/logging/governance considerations

Enable diagnostic settings early:
Access logs (who called what).
Performance logs (latency/throughput signals).
WAF logs (blocked/detected rule matches).
Use Azure Policy to enforce:
Diagnostics enabled.
Allowed SKUs.
Required tags.
TLS minimum version policies (where enforceable).

Simple architecture diagram

flowchart LR
  User[Client / Browser] --> DNS[DNS Record]
  DNS --> FE[App Gateway Frontend IP]
  FE --> L[Listener : HTTP/HTTPS]
  L --> R[Routing Rule]
  R --> B[Backend Pool]
  B --> VM1[Backend 1]
  B --> VM2[Backend 2]

Production-style architecture diagram

flowchart TB
  subgraph Internet[Internet]
    U1[Users]
  end

  subgraph AzureRegion[Azure Region]
    DNSP[Public DNS]
    PIP[Public IP]
    subgraph VNet[VNet (Hub/Spoke or Single VNet)]
      subgraph AGSubnet[Dedicated subnet: appgw-subnet]
        AGW[Azure Application Gateway (Standard_v2 or WAF_v2)]
      end

      subgraph BackendSubnet[backend-subnet]
        VMSS[VM Scale Set / VMs]
        AKS[AKS / Internal Services]
      end

      NSG1[NSG: AppGW subnet rules]
      NSG2[NSG: Backend subnet rules]
    end

    KV[Azure Key Vault (certificates)]
    MON[Azure Monitor / Log Analytics]
  end

  U1 --> DNSP --> PIP --> AGW
  AGW -->|HTTP/HTTPS| VMSS
  AGW -->|HTTP/HTTPS| AKS
  AGW --> KV
  AGW --> MON
  NSG1 -. controls .- AGW
  NSG2 -. controls .- VMSS

8. Prerequisites

Azure account/subscription requirements

An active Azure subscription with billing enabled.
Ability to create:
Resource groups
VNets and subnets
Public IPs
Azure Application Gateway
Virtual Machines (for the lab)

Permissions / IAM roles

Minimum recommended roles for the lab: – Contributor on a resource group (or broader scope) to create and manage resources. – If using Key Vault for certificates: – Appropriate Key Vault permissions (RBAC or access policies) for certificate/secret retrieval by the gateway’s managed identity.

Billing requirements

Application Gateway (especially WAF and v2) is not free.
VM costs, public IP costs, and log ingestion costs may apply.

Tools needed

Azure CLI (current version) and an authenticated session:
Install: https://learn.microsoft.com/cli/azure/install-azure-cli
Sign in: az login
Optional:
Azure PowerShell
A shell environment (bash, Cloud Shell, WSL)
curl for validation

Region availability

Azure Application Gateway is regional. SKU features (zones, WAF features) may vary by region.
Verify region/SKU availability in official docs before production rollout:
https://learn.microsoft.com/azure/application-gateway/overview

Quotas/limits

Azure Application Gateway has limits (listeners, rules, backend pools, etc.) that vary by SKU. Always validate against current limits documentation before design: – Verify in official docs: https://learn.microsoft.com/azure/application-gateway/application-gateway-autoscaling-zone-redundant (and related “limits” pages referenced there)

Prerequisite services

For the hands-on lab: – VNet with at least two subnets: – Dedicated subnet for Application Gateway (appgw-subnet) – Backend subnet for VMs (backend-subnet) – Two small Linux VMs (or one VMSS) hosting a simple HTTP service

9. Pricing / Cost

Azure Application Gateway pricing is usage-based and depends on SKU (for example, Standard_v2 vs WAF_v2), region, and consumption.

Official pricing sources

Pricing page: https://azure.microsoft.com/pricing/details/application-gateway/
Pricing calculator: https://azure.microsoft.com/pricing/calculator/

Pricing dimensions (how you’re billed)

Common pricing dimensions include (verify exact names/units for your SKU on the official pricing page): – Gateway hours: Time the gateway runs (and for v2, this can relate to deployed capacity). – Capacity units / instance consumption: v2 SKUs scale based on traffic; billing reflects usage characteristics (autoscaling affects cost). – Data processed: Typically billed per GB processed through the gateway. – WAF costs (WAF SKU/policy usage): WAF-enabled gateways have additional cost components compared to Standard.

Free tier

Azure Application Gateway does not have a general free tier. You may use Azure credits or free account credits, but the service itself is billable.

Primary cost drivers

Running hours: Always-on gateways run 24/7 in most production environments.
Traffic volume: More GB processed increases cost.
Autoscaling behavior: Traffic spikes can increase effective capacity usage.
WAF vs Standard: WAF SKUs cost more than Standard.
Diagnostics retention and queries: Log Analytics ingestion and retention can become significant in high-traffic environments.

Hidden/indirect costs to plan for

Public IP: Public IP resources may have associated costs (pricing depends on SKU/type/region).
Backend compute: VMs/VMSS/AKS nodes cost far more than the gateway in many architectures.
Data transfer:
Inbound data to Azure is often free; outbound data is commonly billable (verify current Azure bandwidth pricing for your scenario).
Cross-zone and cross-region architectures can add network charges.
Certificates/Key Vault:
Key Vault operations and certificate management may incur costs (depending on tier and usage).
Monitoring:
Diagnostic logs to Log Analytics: ingestion/retention and query costs.

How to optimize cost (practical)

Choose Standard_v2 if you don’t need WAF.
Right-size diagnostics:
Send logs to Log Analytics only if you actively use them; consider Storage for long-term archival.
Set retention policies intentionally.
Consolidate ingress where appropriate:
Multi-site hosting can reduce the number of gateways needed (balanced against blast radius concerns).
Reduce data processed through the gateway when possible:
Offload large downloads to CDN/Front Door where appropriate.
Use autoscaling carefully:
Understand baseline traffic; avoid over-provisioning.
Load test to predict capacity behavior.

Example low-cost starter estimate (how to think about it)

A dev/test setup often includes: – One Standard_v2 gateway running continuously – Low traffic volume – Minimal diagnostics

Because prices vary by region and Microsoft periodically updates pricing, use the official pricing calculator with: – Region – SKU (Standard_v2 or WAF_v2) – Expected monthly data processed (GB) – Expected running hours (typically ~730 hours/month)

Example production cost considerations

In production, you should budget for: – WAF_v2 if required – Zone redundancy (where supported) – Higher data processed (GB/TB scale) – Log Analytics ingestion for access + WAF logs – Additional public IPs and possibly multiple gateways for isolation (e.g., separate gateways for critical apps)

10. Step-by-Step Hands-On Tutorial

This lab deploys a real Azure Application Gateway (Standard_v2) with path-based routing to two backend Linux VMs running NGINX. It’s designed to be executable and low-risk, but it is still billable—clean up afterward.

Objective

Deploy Azure Application Gateway in a dedicated subnet, publish a public frontend, and route: – /app1/* to backend VM1 – /app2/* to backend VM2

Lab Overview

You will create: 1. Resource group + VNet with two subnets (App Gateway subnet and backend subnet) 2. Two Ubuntu VMs with NGINX serving unique pages 3. Azure Application Gateway (Standard_v2) with: – Public frontend IP – Listener on HTTP/80 – Backend pools for each VM – Health probe – Path-based routing rule 4. Validation with curl 5. Cleanup

Notes: – This lab uses HTTP to keep it simple. In production, prefer HTTPS with Key Vault-backed certs. – Commands are written for Azure CLI. Run in Azure Cloud Shell (bash) or any terminal with Azure CLI installed.

Step 1: Set variables and select a subscription

# Optional: set your subscription
az account show --output table
# az account set --subscription "<SUBSCRIPTION_ID>"

# Variables (edit REGION if needed)
REGION="eastus"
RG="rg-appgw-lab"
VNET="vnet-appgw-lab"
APPGW_SUBNET="appgw-subnet"
BACKEND_SUBNET="backend-subnet"
APPGW_PIP="pip-appgw-lab"
APPGW_NAME="appgw-lab"
ADMIN_USER="azureuser"

# Use a strong password or SSH keys; this lab uses SSH keys by default.

Expected outcome: You have chosen a region and named your resources.

Step 2: Create a resource group

az group create \
  --name "$RG" \
  --location "$REGION"

Expected outcome: Resource group is created.

Verify:

az group show -n "$RG" --query "{name:name, location:location}" -o table

Step 3: Create a VNet with dedicated subnets

Azure Application Gateway requires a dedicated subnet.

az network vnet create \
  --resource-group "$RG" \
  --name "$VNET" \
  --location "$REGION" \
  --address-prefixes 10.10.0.0/16 \
  --subnet-name "$APPGW_SUBNET" \
  --subnet-prefixes 10.10.1.0/24

az network vnet subnet create \
  --resource-group "$RG" \
  --vnet-name "$VNET" \
  --name "$BACKEND_SUBNET" \
  --address-prefixes 10.10.2.0/24

Expected outcome: VNet exists with: – 10.10.1.0/24 for Application Gateway – 10.10.2.0/24 for backends

Verify:

az network vnet subnet list -g "$RG" --vnet-name "$VNET" -o table

Step 4: Create NSG rules for backend VMs

We will: – Allow HTTP/80 from the App Gateway subnet to backend VMs – Allow SSH/22 only from your current public IP (optional but helpful)

Get your public IP:

MYIP="$(curl -s https://ifconfig.me)/32"
echo "$MYIP"

Create NSG:

NSG_BACKEND="nsg-backend-lab"

az network nsg create \
  -g "$RG" \
  -n "$NSG_BACKEND" \
  -l "$REGION"

# Allow HTTP from AppGW subnet
az network nsg rule create \
  -g "$RG" \
  --nsg-name "$NSG_BACKEND" \
  -n "Allow-HTTP-from-AppGW" \
  --priority 100 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes 10.10.1.0/24 \
  --source-port-ranges "*" \
  --destination-address-prefixes "*" \
  --destination-port-ranges 80

# Allow SSH from your IP (optional)
az network nsg rule create \
  -g "$RG" \
  --nsg-name "$NSG_BACKEND" \
  -n "Allow-SSH-from-MyIP" \
  --priority 110 \
  --direction Inbound \
  --access Allow \
  --protocol Tcp \
  --source-address-prefixes "$MYIP" \
  --source-port-ranges "*" \
  --destination-address-prefixes "*" \
  --destination-port-ranges 22

# Associate NSG to backend subnet
az network vnet subnet update \
  -g "$RG" \
  --vnet-name "$VNET" \
  -n "$BACKEND_SUBNET" \
  --network-security-group "$NSG_BACKEND"

Expected outcome: Backend subnet only accepts HTTP from the gateway subnet and SSH from your IP.

Step 5: Create two backend Ubuntu VMs with NGINX

We will use cloud-init to install NGINX and serve unique content.

Create cloud-init files:

cat > cloud-init-vm1.txt <<'EOF'
#cloud-config
package_update: true
packages:
  - nginx
write_files:
  - path: /var/www/html/index.html
    content: |
      <html><body><h1>Backend VM1 - app1</h1></body></html>
runcmd:
  - systemctl enable nginx
  - systemctl restart nginx
EOF

cat > cloud-init-vm2.txt <<'EOF'
#cloud-config
package_update: true
packages:
  - nginx
write_files:
  - path: /var/www/html/index.html
    content: |
      <html><body><h1>Backend VM2 - app2</h1></body></html>
runcmd:
  - systemctl enable nginx
  - systemctl restart nginx
EOF

Create the VMs (no public IPs; they’ll be reached via the gateway only):

# VM1
az vm create \
  -g "$RG" \
  -n "vm-backend-1" \
  -l "$REGION" \
  --image "Ubuntu2204" \
  --size "Standard_B1s" \
  --admin-username "$ADMIN_USER" \
  --generate-ssh-keys \
  --vnet-name "$VNET" \
  --subnet "$BACKEND_SUBNET" \
  --public-ip-address "" \
  --custom-data cloud-init-vm1.txt

# VM2
az vm create \
  -g "$RG" \
  -n "vm-backend-2" \
  -l "$REGION" \
  --image "Ubuntu2204" \
  --size "Standard_B1s" \
  --admin-username "$ADMIN_USER" \
  --generate-ssh-keys \
  --vnet-name "$VNET" \
  --subnet "$BACKEND_SUBNET" \
  --public-ip-address "" \
  --custom-data cloud-init-vm2.txt

Expected outcome: Two private VMs are provisioned in the backend subnet.

Get their private IPs:

IP1=$(az vm list-ip-addresses -g "$RG" -n vm-backend-1 --query "[0].virtualMachine.network.privateIpAddresses[0]" -o tsv)
IP2=$(az vm list-ip-addresses -g "$RG" -n vm-backend-2 --query "[0].virtualMachine.network.privateIpAddresses[0]" -o tsv)
echo "VM1: $IP1"
echo "VM2: $IP2"

Step 6: Create a public IP for the Application Gateway

az network public-ip create \
  -g "$RG" \
  -n "$APPGW_PIP" \
  -l "$REGION" \
  --sku Standard \
  --allocation-method Static

Expected outcome: A static public IP exists for the gateway frontend.

Verify:

az network public-ip show -g "$RG" -n "$APPGW_PIP" --query "{ip:ipAddress, sku:sku.name}" -o table

Step 7: Create the Azure Application Gateway (Standard_v2)

This creates the gateway, frontend, and default configs. We’ll then customize routing.

az network application-gateway create \
  -g "$RG" \
  -n "$APPGW_NAME" \
  -l "$REGION" \
  --sku Standard_v2 \
  --capacity 1 \
  --vnet-name "$VNET" \
  --subnet "$APPGW_SUBNET" \
  --public-ip-address "$APPGW_PIP" \
  --http-settings-protocol Http \
  --http-settings-port 80 \
  --frontend-port 80

Expected outcome: Application Gateway is provisioned with a public frontend listening on port 80.

Check provisioning state:

az network application-gateway show -g "$RG" -n "$APPGW_NAME" --query "provisioningState" -o tsv

Step 8: Configure backend pools (VM1 and VM2)

Create two backend pools using the VMs’ private IPs:

az network application-gateway address-pool create \
  -g "$RG" \
  --gateway-name "$APPGW_NAME" \
  -n "pool-app1" \
  --servers "$IP1"

az network application-gateway address-pool create \
  -g "$RG" \
  --gateway-name "$APPGW_NAME" \
  -n "pool-app2" \
  --servers "$IP2"

Expected outcome: Two backend pools exist.

Verify:

az network application-gateway address-pool list \
  -g "$RG" --gateway-name "$APPGW_NAME" -o table

Step 9: Create a health probe (recommended for predictable routing)

Create a probe that checks / on port 80:

az network application-gateway probe create \
  -g "$RG" \
  --gateway-name "$APPGW_NAME" \
  -n "probe-http" \
  --protocol Http \
  --host "127.0.0.1" \
  --path "/" \
  --interval 30 \
  --timeout 30 \
  --threshold 3

Expected outcome: Probe exists and will mark NGINX backends healthy.

Why host is 127.0.0.1: for IP backends, the host header can be set explicitly. For name-based virtual hosting, you’d set it to your expected hostname.

Step 10: Create HTTP settings that use the probe

az network application-gateway http-settings create \
  -g "$RG" \
  --gateway-name "$APPGW_NAME" \
  -n "http-settings-app" \
  --protocol Http \
  --port 80 \
  --probe "probe-http" \
  --timeout 30

Expected outcome: Gateway now has an HTTP settings object that includes the probe.

Step 11: Create a URL path map and routing rule

We’ll route: – /app1/* → pool-app1 – /app2/* → pool-app2

Create the URL path map:

az network application-gateway url-path-map create \
  -g "$RG" \
  --gateway-name "$APPGW_NAME" \
  -n "pathmap-lab" \
  --default-address-pool "pool-app1" \
  --default-http-settings "http-settings-app" \
  --rule-name "rule-app1" \
  --paths "/app1/*" \
  --address-pool "pool-app1" \
  --http-settings "http-settings-app"

Add /app2/* rule to the same map:

az network application-gateway url-path-map rule create \
  -g "$RG" \
  --gateway-name "$APPGW_NAME" \
  --path-map-name "pathmap-lab" \
  -n "rule-app2" \
  --paths "/app2/*" \
  --address-pool "pool-app2" \
  --http-settings "http-settings-app"

Now create a request routing rule that binds the listener to the URL path map. First, find the default listener name (often appGatewayHttpListener):

LISTENER=$(az network application-gateway http-listener list \
  -g "$RG" --gateway-name "$APPGW_NAME" --query "[0].name" -o tsv)
echo "$LISTENER"

Create a path-based rule:

az network application-gateway rule create \
  -g "$RG" \
  --gateway-name "$APPGW_NAME" \
  -n "rule-pathbased" \
  --rule-type PathBasedRouting \
  --http-listener "$LISTENER" \
  --url-path-map "pathmap-lab" \
  --priority 100

Expected outcome: Path-based routing rule exists.

If you receive an error about rule priority or conflicts with an existing basic rule created by default, list existing rules and delete the default basic rule before creating the new one: – List: az network application-gateway rule list -g "$RG" --gateway-name "$APPGW_NAME" -o table – Delete: az network application-gateway rule delete ... Then retry creating rule-pathbased.

Step 12: Validation

Get the public IP:

APPGW_IP=$(az network public-ip show -g "$RG" -n "$APPGW_PIP" --query ipAddress -o tsv)
echo "Application Gateway Public IP: $APPGW_IP"

Test routing:

curl -s "http://$APPGW_IP/app1/" | head
curl -s "http://$APPGW_IP/app2/" | head

Expected outcome: – /app1/ returns a page containing Backend VM1 - app1 – /app2/ returns a page containing Backend VM2 - app2

If you get a 502: – Wait 2–5 minutes for backends to become healthy, then re-test. – See Troubleshooting below.

Optional: Check backend health (very useful):

az network application-gateway show-backend-health \
  -g "$RG" -n "$APPGW_NAME" -o jsonc

Troubleshooting

Common issues and realistic fixes:

502 Bad Gateway – Cause: Backend marked unhealthy (probe failing) or NSG blocking. – Fix:
- Check backend health: bash az network application-gateway show-backend-health -g "$RG" -n "$APPGW_NAME" -o jsonc
- Ensure backend subnet NSG allows inbound TCP/80 from 10.10.1.0/24.
- Ensure NGINX is installed and running (if SSH enabled, connect via a jump host; otherwise redeploy VM or use Run Command).
Path routes work but return the same backend – Cause: URL path map misconfigured or rule priority conflict. – Fix:
- List URL path map: bash az network application-gateway url-path-map show -g "$RG" --gateway-name "$APPGW_NAME" -n pathmap-lab -o jsonc
- Ensure /app2/* points to pool-app2.
Cannot create path-based rule due to existing basic rule – Cause: Default rule created during application-gateway create. – Fix: Delete the default rule and recreate your path-based rule.
Long provisioning times – Cause: Application Gateway provisioning can take several minutes. – Fix: Wait and recheck provisioningState. Avoid repeated updates during provisioning.

Cleanup

To avoid ongoing charges, delete the resource group:

az group delete -n "$RG" --yes --no-wait

Expected outcome: All lab resources will be deleted (gateway, VMs, public IP, VNet, NSGs, etc.).

11. Best Practices

Architecture best practices

Use v2 SKUs for new deployments when possible; they provide autoscaling and improved architecture compared to v1 SKUs (verify Microsoft’s current recommendation in docs).
Separate concerns:
Consider separate gateways for different environments (prod vs non-prod) and/or different risk domains to reduce blast radius.
Design subnets carefully:
Use a dedicated subnet for the gateway.
Allocate enough IP space for scaling (follow official subnet sizing guidance; verify current recommendations).
Plan for multi-region if required:
Application Gateway is regional; for multi-region active-active, combine with DNS-based routing (Traffic Manager) or an edge service (Front Door), depending on requirements.

IAM/security best practices

Use least privilege Azure RBAC:
Operators: read-only + diagnostics readers
Network admins: limited write permissions
If using Key Vault:
Prefer managed identity for the gateway to retrieve certs.
Limit permissions to only required secrets/certificates.

Cost best practices

Consolidate with multi-site routing where appropriate, but balance against blast radius.
Enable diagnostics intentionally (avoid “log everything forever”).
Review data processed and autoscaling patterns monthly; cost often correlates with traffic growth.

Performance best practices

Use health probes aligned with application endpoints that truly represent readiness.
Keep backends in the same region/VNet to reduce latency.
Avoid excessive rewrite rules unless necessary; document and test them.

Reliability best practices

Prefer zone redundancy where supported and required.
Configure multiple backend instances for each pool to avoid single points of failure.
Use connection draining during deployments.

Operations best practices

Standardize naming and tagging:
env, owner, costCenter, app, dataClassification
Automate deployments via IaC:
Bicep/ARM/Terraform, plus CI/CD validation.
Implement alerting:
Backend unhealthy count
5xx rates
WAF blocks spikes
Capacity-related metrics (verify metric names in Azure Monitor)

Governance best practices

Use Azure Policy to enforce:
Diagnostic settings enabled
Allowed SKUs
Required tags
Use resource locks carefully (read-only locks can prevent emergency updates).

12. Security Considerations

Identity and access model

Management plane access is controlled by Azure AD and Azure RBAC.
Use separate roles for:
Readers (view config)
Operators (rotate certs, adjust backends)
Admins (create/modify routing/WAF policies)
Audit changes with Azure Activity Log.

Encryption

Client-to-gateway: Use HTTPS listeners with strong TLS policies.
Gateway-to-backend:
Use HTTPS to backends for end-to-end encryption.
Configure trusted root certificates / backend validation properly (verify exact configuration steps for your SKU).

Network exposure

Prefer private frontends for internal apps.
For internet-facing apps:
Lock down backend subnet to accept traffic only from the gateway subnet.
Consider VNet-level DDoS protection options where appropriate.
Avoid exposing backend VMs publicly unless required (use Bastion or jump hosts if admin access is needed).

Secrets handling

Prefer Key Vault for TLS cert storage and rotation.
Minimize certificate copies:
Avoid storing certs in local scripts, wikis, or source repos.
Restrict Key Vault access and monitor Key Vault audit logs.

Audit/logging

Enable diagnostic logs:
Access logs for traffic analysis
WAF logs for security operations
Send logs to Log Analytics or SIEM via Event Hubs.
Ensure log retention aligns with compliance requirements.

Compliance considerations

WAF can support baseline controls, but it is not a complete compliance solution by itself.
If you have regulatory requirements:
Document TLS policies
Log retention and access controls
Change management controls for routing/WAF policy updates

Common security mistakes

Leaving HTTP enabled for internet-facing endpoints without redirect to HTTPS.
Using broad NSG rules on backend subnet (e.g., 0.0.0.0/0 to port 80).
Enabling WAF in prevention mode without tuning (causing false positives and outages).
Not enabling diagnostics and then lacking evidence during an incident.

Secure deployment recommendations

Start WAF in detection mode, analyze logs, then move to prevention mode with exceptions.
Use HTTPS-only listeners; redirect HTTP to HTTPS if needed.
Use private endpoints and private DNS patterns where they make sense for supporting services (Key Vault, monitoring ingestion endpoints, etc.—verify exact availability).

13. Limitations and Gotchas

Always validate the latest official limits and SKU capabilities before finalizing designs.

Dedicated subnet requirement: Application Gateway must be deployed into its own subnet.
Regional scope: It is not a global anycast edge service; global routing requires additional services.
Limits vary by SKU: Listeners, rules, backend pools, and other objects have SKU-specific maximums.
Subnet sizing matters: Too small a subnet can constrain scaling and future changes (verify official sizing guidance).
502 errors often trace to NSGs/probes:
Misconfigured health probes, blocked ports, or wrong host headers can mark backends unhealthy.
Backend TLS validation complexity:
End-to-end TLS is powerful but requires careful certificate trust configuration.
WAF tuning overhead:
Managed rules can block legitimate traffic; expect tuning time and change control.
Log Analytics cost surprises:
High traffic + verbose logging can increase ingestion costs significantly.
Rule conflicts and priorities:
Complex routing setups can become hard to reason about; document precedence and test.
AKS ingress integration nuances:
Controller-based integration has versioning and permissions considerations; confirm current guidance and supported versions.

14. Comparison with Alternatives

Azure Application Gateway sits in a specific place in Azure Networking: regional L7 reverse proxy and WAF. Here’s how it compares.

Option	Best For	Strengths	Weaknesses	When to Choose
Azure Application Gateway	Regional HTTP(S) ingress inside a VNet	Path/host routing, TLS termination, WAF option, deep VNet integration	Not global; requires subnet/IP planning; WAF tuning overhead	Need L7 load balancing and optional WAF in-region, inside VNet
Azure Front Door	Global HTTP(S) entry point	Global anycast, CDN-like edge, global WAF, acceleration	Not deployed inside your VNet in the same way; different private origin patterns	Need global routing, edge caching/acceleration, multi-region failover
Azure Load Balancer	L4 TCP/UDP load balancing	High performance L4, simple, cost-effective	No L7 routing/WAF/TLS termination	Non-HTTP workloads or basic TCP/UDP balancing
Azure Traffic Manager	DNS-based global routing	Simple global failover via DNS, multi-region	DNS TTL-based; not application-layer proxy	Multi-region endpoint selection without proxy features
Azure API Management	API gateway + governance	Auth, rate limits, transforms, dev portal, analytics	Not a general-purpose L7 load balancer; may still need ingress	Need API lifecycle management and policy-based API control
NGINX/HAProxy/Envoy (self-managed)	Maximum customization	Full control, plugins, custom logic	You operate scaling, patching, HA, monitoring	Specialized requirements or hybrid/on-prem consistency
AWS ALB (other cloud)	L7 load balancing on AWS	Strong L7 features integrated with AWS	Different cloud; not applicable inside Azure VNets	Only if your workload is on AWS
GCP External HTTPS Load Balancer (other cloud)	Global L7 on GCP	Global L7	Different cloud	Only if your workload is on GCP

15. Real-World Example

Enterprise example: regulated internal + external apps with centralized ingress

Problem: A regulated enterprise hosts multiple business apps: some internet-facing, some internal-only. Security requires centralized TLS policy, WAF for external apps, and detailed logs for audits.
Proposed architecture:
Hub-and-spoke VNets.
Azure Application Gateway WAF_v2 in a shared services spoke.
Public frontend for internet-facing apps; private frontend for internal apps.
Backend pools pointing to VMSS and internal services.
Azure Key Vault for certificates; managed identity for retrieval.
Azure Monitor + Log Analytics for access/WAF logs; alerts integrated with SOC workflows.
Why Azure Application Gateway was chosen:
Regional VNet-native ingress with L7 routing and WAF.
Centralized TLS termination + optional end-to-end TLS to backends.
Strong integration with Azure monitoring and Key Vault.
Expected outcomes:
Standardized ingress patterns and reduced per-app proxy maintenance.
Improved security posture and auditability.
Faster onboarding of new apps via repeatable routing templates.

Startup/small-team example: single gateway for multiple services

Problem: A startup runs a web frontend and an API, wants one domain and simple routing, and needs to avoid operating custom proxy fleets.
Proposed architecture:
One Azure Application Gateway Standard_v2 with path-based routing:
- / → frontend service
- /api/* → API service
Backends on VMSS or managed services reachable from the VNet.
Basic access logs enabled for troubleshooting.
Why Azure Application Gateway was chosen:
Simpler than self-managed NGINX, more app-aware than L4 load balancer.
Easy path-based routing without application changes.
Expected outcomes:
Reduced operational overhead.
Clean URL structure and easier deployments.
Straightforward scaling path by scaling backends and allowing the gateway to autoscale (SKU-dependent).

16. FAQ

Is Azure Application Gateway global or regional?
Regional. You deploy it into a specific Azure region and VNet subnet.
Is Azure Application Gateway a Layer 7 load balancer?
Yes. It’s designed for HTTP/HTTPS and provides application-aware routing.
Do I need a dedicated subnet for Azure Application Gateway?
Yes. A dedicated subnet is required.
Can Azure Application Gateway be private (internal-only)?
Yes. You can use a private frontend IP to make it reachable only inside private networks.
Does Azure Application Gateway support TLS termination?
Yes. It can terminate HTTPS at the gateway and forward to backends via HTTP or HTTPS.
Can I encrypt traffic from the gateway to the backend?
Yes, using HTTPS backend settings (end-to-end TLS). You must manage backend certificate trust correctly.
What’s the difference between Standard_v2 and WAF_v2?
WAF_v2 includes Web Application Firewall capabilities; Standard_v2 does not. Pricing and operational tuning differ.
Do I always need WAF?
No. Use WAF when you need application-layer threat protection. For internal-only or low-risk apps, Standard_v2 may be sufficient (subject to your security requirements).
How do I route multiple apps behind one gateway?
Use multi-site listeners (host-based routing) and/or URL path maps (path-based routing).
Why am I getting 502 Bad Gateway?
Typically because backends are unhealthy or unreachable (probe failing, NSG blocking, wrong ports, misconfigured HTTP settings).
Can Azure Application Gateway send logs to Log Analytics?
Yes, via Diagnostic settings. You can also send logs to Storage or Event Hubs.
Does Azure Application Gateway replace Azure Front Door?
No. They serve different scopes. Front Door is global edge; Application Gateway is regional and VNet-based.
Can I use Azure Application Gateway in front of AKS?
Yes, commonly via controller-based integration (AGIC). Confirm current Microsoft recommendations and supported versions for your cluster.
How do I manage certificates safely?
Prefer Azure Key Vault and managed identity rather than uploading certificates manually.
What are the most common operational tasks?
Updating routing rules, rotating certificates, tuning probes/timeouts, reviewing WAF logs, and monitoring backend health and 5xx error rates.
Is Azure Application Gateway suitable for non-HTTP traffic?
No. It’s for HTTP/HTTPS. Use Azure Load Balancer or other services for non-HTTP protocols.
Can I do blue/green deployments with Azure Application Gateway?
You can model environments using separate backend pools and routing rules. For more advanced weighted traffic shifting, consider complementary services or patterns (verify best-fit service for your needs).

17. Top Online Resources to Learn Azure Application Gateway

Resource Type	Name	Why It Is Useful
Official documentation	Azure Application Gateway documentation – Overview https://learn.microsoft.com/azure/application-gateway/overview	Canonical concepts, SKUs, features, and configuration guidance
Official documentation	Application Gateway WAF documentation https://learn.microsoft.com/azure/web-application-firewall/ag/ag-overview	WAF concepts, policies, managed/custom rules, logging
Official pricing	Azure Application Gateway pricing https://azure.microsoft.com/pricing/details/application-gateway/	Current pricing dimensions by SKU and region
Official calculator	Azure Pricing Calculator https://azure.microsoft.com/pricing/calculator/	Build region-specific estimates based on usage
Official tutorials	Application Gateway tutorials (docs index) https://learn.microsoft.com/azure/application-gateway/	Step-by-step guides for common configurations
Official monitoring docs	Azure Monitor metrics & diagnostics settings https://learn.microsoft.com/azure/azure-monitor/	How to emit logs/metrics and build alerts
Architecture guidance	Azure Architecture Center https://learn.microsoft.com/azure/architecture/	Reference architectures and best practices for Azure networking designs
Learning modules	Microsoft Learn (search: Application Gateway) https://learn.microsoft.com/training/	Guided learning paths and labs (quality varies; choose updated modules)
Release updates	Azure Updates (search: Application Gateway) https://azure.microsoft.com/updates/	Track new features, previews, and GA announcements
GitHub samples	Microsoft / Azure samples on GitHub (search) https://github.com/Azure	IaC templates and examples (verify recency and support status)

18. Training and Certification Providers

Institute	Suitable Audience	Likely Learning Focus	Mode	Website URL
DevOpsSchool.com	DevOps engineers, SREs, platform teams	Azure networking, DevOps practices, ingress patterns, operational skills	Check website	https://www.devopsschool.com/
ScmGalaxy.com	Beginners to intermediate engineers	DevOps, CI/CD, cloud fundamentals, tooling	Check website	https://www.scmgalaxy.com/
CLoudOpsNow.in	Cloud operations teams	Cloud ops practices, monitoring, reliability, governance	Check website	https://www.cloudopsnow.in/
SreSchool.com	SREs and operations engineers	SRE principles, incident response, monitoring, performance	Check website	https://www.sreschool.com/
AiOpsSchool.com	Ops teams exploring AIOps	Observability, automation, AIOps concepts and tools	Check website	https://www.aiopsschool.com/

19. Top Trainers

Platform/Site	Likely Specialization	Suitable Audience	Website URL
RajeshKumar.xyz	DevOps/cloud training content (verify offerings)	Beginners to intermediate practitioners	https://rajeshkumar.xyz/
devopstrainer.in	DevOps and cloud training (verify course catalog)	DevOps engineers and students	https://www.devopstrainer.in/
devopsfreelancer.com	Freelance DevOps guidance/services (verify scope)	Teams needing practical DevOps help	https://www.devopsfreelancer.com/
devopssupport.in	DevOps support/training resources (verify scope)	Ops/DevOps teams	https://www.devopssupport.in/

20. Top Consulting Companies

Company Name	Likely Service Area	Where They May Help	Consulting Use Case Examples	Website URL
cotocus.com	Cloud/DevOps consulting (verify specific offerings)	Architecture, implementation, migration planning	Designing Azure ingress, WAF rollout, monitoring and operations setup	https://cotocus.com/
DevOpsSchool.com	DevOps and cloud consulting/training	Platform engineering, DevOps automation, operational readiness	Implementing Azure Application Gateway + WAF with IaC and CI/CD	https://www.devopsschool.com/
DEVOPSCONSULTING.IN	DevOps consulting (verify service details)	DevOps transformation, cloud operations, automation	Building repeatable networking patterns and operational dashboards	https://www.devopsconsulting.in/

21. Career and Learning Roadmap

What to learn before Azure Application Gateway

Networking fundamentals:
IP addressing, CIDR, routing
DNS basics (A records, CNAMEs, TTL)
TLS/HTTPS fundamentals (certificates, SNI, cipher suites)
Azure fundamentals:
Resource groups, subscriptions, Azure RBAC
Virtual networks, subnets, NSGs
Web fundamentals:
HTTP methods, headers, status codes
Reverse proxies and load balancing concepts

What to learn after Azure Application Gateway

Advanced Azure networking:
Azure Front Door vs Application Gateway design patterns
Private connectivity (VPN/ExpressRoute)
Hub/spoke network topology
Security:
WAF tuning and operationalization
SIEM integration (Microsoft Sentinel patterns)
Automation:
Bicep/Terraform for repeatable deployments
CI/CD pipelines with staged rollouts and validation
Reliability:
Load testing, capacity planning
Multi-region disaster recovery patterns

Job roles that use it

Cloud Engineer / Cloud Administrator
Network Cloud Engineer
DevOps Engineer / Platform Engineer
Site Reliability Engineer (SRE)
Security Engineer (WAF/TLS governance)
Solutions Architect

Certification path (Azure)

Microsoft certification offerings evolve. A practical path often includes: – Azure Fundamentals (AZ-900) – Azure Administrator (AZ-104) – Azure Network Engineer Associate (AZ-700) (highly relevant) – Azure Solutions Architect Expert (AZ-305) Verify current certification details on Microsoft Learn: – https://learn.microsoft.com/credentials/

Project ideas for practice

Build a secure HTTPS-only Application Gateway with Key Vault certificates and automatic rotation runbook.
Deploy WAF in detection mode, analyze false positives, and move to prevention with documented exclusions.
Implement multi-site routing for three apps and automate the whole deployment with Bicep or Terraform.
Create Azure Monitor alerts for backend health, 5xx spikes, and WAF blocks, and write an incident runbook.

22. Glossary

Application Gateway: Azure-managed Layer 7 reverse proxy and load balancer for HTTP/HTTPS traffic.
Listener: Configuration that defines how the gateway receives traffic (IP, port, protocol, hostname, certificate).
Backend pool: A group of backend targets that receive traffic from the gateway.
HTTP settings: Defines how the gateway connects to backends (protocol, port, timeout, affinity, probes).
Health probe: Periodic check used to determine whether a backend is healthy.
Routing rule: Connects a listener to a backend pool and HTTP settings; can be basic or path-based.
Path-based routing: Routing decisions based on URL path patterns (e.g., /api/*).
Multi-site hosting: Routing decisions based on hostname (e.g., app1.contoso.com vs app2.contoso.com).
TLS termination (SSL offload): Decrypting HTTPS at the gateway and forwarding to backends.
End-to-end TLS: HTTPS between client↔gateway and gateway↔backend.
WAF (Web Application Firewall): Application-layer security controls to detect/block web attacks.
Managed rules: Predefined WAF rule sets maintained by Microsoft based on common vulnerabilities.
Custom rules: User-defined WAF rules (match conditions and actions).
NSG (Network Security Group): Azure firewall rules for subnets/NICs controlling traffic flows.
VNet: Azure Virtual Network; isolated network boundary for Azure resources.
Availability Zones: Physically separate datacenters within a region for resiliency.
Diagnostic settings: Azure configuration that exports resource logs/metrics to monitoring destinations.

23. Summary

Azure Application Gateway is Azure’s regional, VNet-integrated Layer 7 load balancer and reverse proxy for HTTP/HTTPS workloads. It matters because it gives teams a managed, scalable, and security-capable ingress point with features like path-based routing, host-based routing, TLS termination, health probes, and optional WAF.

It fits best when you need application-aware routing inside a region and inside a VNet, especially when you want centralized TLS policy and WAF controls close to your backends. Key cost drivers include gateway running time, autoscaling behavior, data processed, WAF SKU selection, and monitoring log ingestion. Key security considerations include HTTPS everywhere, strict NSGs between gateway and backends, Key Vault-based certificate handling, and WAF tuning to avoid false positives.

Use Azure Application Gateway when you need regional L7 ingress and optional WAF; consider Azure Front Door for global edge scenarios and Azure Load Balancer for non-HTTP or pure L4 needs. Next, deepen your skills by enabling diagnostics, practicing WAF policy tuning, and deploying repeatable configurations using Bicep or Terraform.

Category

1. Introduction

2. What is Azure Application Gateway?

3. Why use Azure Application Gateway?

Business reasons

Technical reasons

Operational reasons

Security/compliance reasons

Scalability/performance reasons

When teams should choose it

When teams should not choose it

4. Where is Azure Application Gateway used?

Industries

Team types

Workloads

Architectures

Real-world deployment contexts

5. Top Use Cases and Scenarios

6. Core Features

Layer 7 HTTP/HTTPS load balancing

URL path-based routing

Multi-site (host-based) routing

TLS termination (SSL offload) and TLS policy

End-to-end TLS (re-encryption to backend)

Web Application Firewall (WAF) (WAF SKUs)

Autoscaling (v2 SKUs)

Zone redundancy (supported regions/SKUs)

Health probes

Connection draining

Cookie-based affinity (session stickiness)

Redirects and rewrites

Private frontend

Diagnostics and monitoring integration

7. Architecture and How It Works

High-level service architecture

Request/data/control flow (conceptual)

Integrations with related Azure services

Dependency services

Security/authentication model

Networking model

Monitoring/logging/governance considerations

Simple architecture diagram

Production-style architecture diagram

8. Prerequisites

Azure account/subscription requirements

Permissions / IAM roles

Billing requirements

Tools needed

Region availability

Quotas/limits

Prerequisite services

9. Pricing / Cost

Official pricing sources

Pricing dimensions (how you’re billed)

Free tier

Primary cost drivers

Hidden/indirect costs to plan for

How to optimize cost (practical)

Example low-cost starter estimate (how to think about it)

Example production cost considerations

10. Step-by-Step Hands-On Tutorial

Objective

Lab Overview

Step 1: Set variables and select a subscription

Step 2: Create a resource group

Step 3: Create a VNet with dedicated subnets

Step 4: Create NSG rules for backend VMs

Step 5: Create two backend Ubuntu VMs with NGINX

Step 6: Create a public IP for the Application Gateway

Step 7: Create the Azure Application Gateway (Standard_v2)

Step 8: Configure backend pools (VM1 and VM2)

Step 9: Create a health probe (recommended for predictable routing)

Step 10: Create HTTP settings that use the probe

Step 11: Create a URL path map and routing rule

Step 12: Validation

Troubleshooting

Cleanup

11. Best Practices

Architecture best practices

IAM/security best practices