Skip to content
Learni
Voir tous les tutoriels
Azure

Comment déployer Azure Application Gateway en 2026

14 minINTERMEDIATE
AzureAzure CLIApplication GatewayLoad BalancerWAF
Read in English

Introduction

Azure Application Gateway est un load balancer de couche 7 (L7) managé par Microsoft Azure, idéal pour router intelligemment le trafic HTTP/HTTPS vers plusieurs backends. Contrairement à Azure Load Balancer (L4), il gère les URL paths, host headers, et intègre nativement un Web Application Firewall (WAF) pour bloquer les attaques OWASP. En 2026, avec l'essor des microservices et API gateways, il est essentiel pour les architectures scalables.

Ce tutoriel intermédiaire vous guide pas à pas pour déployer une Gateway v2 complète via Azure CLI, incluant subnet dédié, backend pools multi-VMs, listeners HTTPS avec certificats, et règles basées sur URL. Vous apprendrez à configurer le WAF OWASP 3.2 pour une sécurité proactive. À la fin, vous aurez une infra production-ready, testable en 30 minutes. Pourquoi c'est crucial ? Il supporte jusqu'à 100 Gbps/s, autoscaling, et zone redundancy pour 99.99% SLA. Parfait pour AKS, VMs ou App Services.

Prérequis

  • Compte Azure actif avec permissions Contributor.
  • Azure CLI 2.65+ installé (télécharger).
  • 2-3 VMs ou IPs backend existantes pour tests (ex: dans un VNet séparé).
  • Connaissances de base en networking Azure (VNet, NSG) et TypeScript/CLI.

1. Créer le Resource Group et variables

01-setup-rg.sh
#!/bin/bash

# Variables globales (adaptez à votre environnement)
RG_NAME="appgw-rg-$RANDOM"
LOCATION="francecentral"
VNET_NAME="appgw-vnet"
SUBNET_NAME="appgw-subnet"
APPGW_NAME="myAppGateway"

# Login et sélection subscription (exécutez az login avant)
az account set --subscription "VotreSubscriptionID"

# Créer Resource Group
echo "Création du RG: $RG_NAME"
az group create \
  --name $RG_NAME \
  --location $LOCATION \
  --tags 'project=appgw-tutorial' 'env=dev'

echo "RG créé: $RG_NAME"

Ce script initialise les variables et crée un Resource Group dédié avec tags pour traçabilité. Utilisez un ID subscription valide après az login. Évitez les RG partagés pour isoler les coûts ; le suffixe $RANDOM évite les conflits.

2. Préparer le réseau virtuel

Application Gateway nécessite un subnet dédié (minimum /27 pour v1, /26 pour v2 avec WAF). Ce subnet doit être vide et tagué appGatewaySubnet. Le VNet principal peut héberger d'autres ressources, mais séparez pour sécurité.

2. Créer VNet et subnet dédié

02-vnet-subnet.sh
#!/bin/bash

# Variables (suite du script précédent)
ADDRESS_PREFIX_VNET="10.0.0.0/16"
ADDRESS_PREFIX_SUBNET="10.0.1.0/26"

# Créer VNet
echo "Création VNet: $VNET_NAME"
az network vnet create \
  --resource-group $RG_NAME \
  --name $VNET_NAME \
  --address-prefixes $ADDRESS_PREFIX_VNET \
  --subnet-name default \
  --subnet-prefixes "10.0.0.0/24" \
  --location $LOCATION

# Créer subnet dédié pour AppGw (taille /26 obligatoire pour WAF/ZR)
echo "Création subnet: $SUBNET_NAME"
az network vnet subnet create \
  --resource-group $RG_NAME \
  --vnet-name $VNET_NAME \
  --name $SUBNET_NAME \
  --address-prefixes $ADDRESS_PREFIX_SUBNET \
  --delegations Microsoft.Network/applicationGateways

# Tagger le subnet
echo "Taggage subnet"
az network vnet subnet update \
  --resource-group $RG_NAME \
  --vnet-name $VNET_NAME \
  --name $SUBNET_NAME \
  --tags 'purpose=appgw-subnet'

Crée un VNet avec subnet par défaut et un subnet dédié délégué à ApplicationGateway. La délégation évite les conflits ; /26 supporte jusqu'à 64 instances. Vérifiez avec az network vnet subnet list pour confirmer.

3. Déployer Application Gateway basique

03-appgw-create.sh
#!/bin/bash

# IPs backend fictives (remplacez par vos VMs réelles, ex: 10.0.2.4 10.0.2.5)
BACKEND_IPS="10.0.2.4 10.0.2.5"

# Créer AppGw v2 Standard (public, capacity 2, zone-redundant)
echo "Déploiement AppGw: $APPGW_NAME (5-10min)"
az network application-gateway create \
  --resource-group $RG_NAME \
  --name $APPGW_NAME \
  --location $LOCATION \
  --sku Standard_v2 \
  --public-ip-address myPublicIP \
  --vnet-name $VNET_NAME \
  --subnet $SUBNET_NAME \
  --priority 100 \
  --capacity 2 \
  --tags 'project=appgw' 'tier=standard_v2'

# Ajouter backend pool
az network application-gateway backend-pool create \
  --resource-group $RG_NAME \
  --gateway-name $APPGW_NAME \
  --name backendPool1 \
  --servers $BACKEND_IPS

Déploie une Gateway v2 publique avec autoscaling (2 instances min). Fournit des IPs backend ; adaptez à vos VMs/scale sets. Le SKU Standard_v2 inclut WAF optionnel ; attendez 5-10min pour Succeeded.

3. Configurer les settings backend et health probes

Les backend HTTP settings définissent le port (80/443), probe path (/health), et timeouts. Un health probe HTTP vérifie périodiquement les backends pour routage intelligent.

4. Ajouter HTTP settings et health probe

04-http-settings-probe.sh
#!/bin/bash

# Créer health probe (vérifie /healthz toutes 30s, unhealthy si >2 échecs)
az network application-gateway probe create \
  --resource-group $RG_NAME \
  --gateway-name $APPGW_NAME \
  --probe-name healthProbeBackend \
  --protocol Http \
  --host "127.0.0.1" \
  --path "/healthz" \
  --interval 30 \
  --timeout 120 \
  --threshold 3 \
  --pick-host-name-from-backend-http-settings

# Créer backend HTTP settings (port 80, probe attaché, cookie affinity)
az network application-gateway http-settings create \
  --resource-group $RG_NAME \
  --gateway-name $APPGW_NAME \
  --name httpSettingsBackend \
  --protocol Http \
  --port 80 \
  --probe healthProbeBackend \
  --cookie-based-affinity Enabled \
  --request-timeout 120

Configure un probe pour détecter les backends sains (imaginez un endpoint /healthz sur vos serveurs). Les settings attachent ce probe et activent l'affinité session via cookies. Testez avec curl post-déploiement.

5. Créer listener HTTPS et règle routing

05-listener-rule.sh
#!/bin/bash

# Récup IP publique (pour listener)
PUBLIC_IP=$(az network public-ip show --resource-group $RG_NAME --name myPublicIP --query ipAddress --output tsv)

# Créer listener HTTPS (port 443, nécessite certificat self-signed ou PFX uploadé)
az network application-gateway listener create \
  --resource-group $RG_NAME \
  --gateway-name $APPGW_NAME \
  --name listenerHttps \
  --frontend-ip public \
  --frontend-port 443 \
  --protocol Https \
  --ssl-certificate myCert  # Upload cert via portal/CLI avant

# Créer rule basique (multi-site ou path-based)
az network application-gateway rule create \
  --resource-group $RG_NAME \
  --gateway-name $APPGW_NAME \
  --name rule1 \
  --listener listenerHttps \
  --rule-type Basic \
  --backend-pool backendPool1 \
  --backend-http-settings httpSettingsBackend

Ajoute un listener HTTPS (uploadez un cert PFX via az network application-gateway ssl-cert create avant). La règle Basic route tout trafic vers le pool. Pour path-based, utilisez --rule-type PathBasedRouting avec patterns comme /api/*.

6. Activer WAF v2 et tester

06-waf-test.sh
#!/bin/bash

# Activer WAF Policy OWASP 3.2 (Detection/Prevention mode)
az network application-gateway waf-policy create \
  --resource-group $RG_NAME \
  --name wafPolicy1 \
  --location $LOCATION

az network application-gateway ssl-policy update \
  --resource-group $RG_NAME \
  --gateway-name $APPGW_NAME \
  --name AppGwSslPolicy1 \
  --policy-type Predefined \
  --policy-name AppGwSslPolicy2025

# Associer WAF au listener (update rule)
az network application-gateway rule update \
  --resource-group $RG_NAME \
  --gateway-name $APPGW_NAME \
  --name rule1 \
  --firewall-policy wafPolicy1

# Tester (remplacez $PUBLIC_IP)
echo "Testez: curl -k https://$PUBLIC_IP/healthz"
az network application-gateway show --resource-group $RG_NAME --name $APPGW_NAME

Active le WAF pour bloquer SQLi/XSS (mode Prevention). Associe à la rule. SSL policy 2025 force TLS 1.2+. Testez avec curl ; logs WAF via az monitor diagnostic-settings create. Évitez mode Prevention en dev sans tuning.

Bonnes pratiques

  • Subnet dédié et délégué : Toujours /26+ pour WAF/ZR, avec NSG restrictif (ports 65200-65535 pour probes).
  • WAF en Prevention : Commencez Detection, tunez exclusions (ex: --exclusion sql-injection=RequestArgNames|user-agent).
  • Zone redundancy : Ajoutez --zones 1 2 3 au create pour HA.
  • Monitoring : Activez Application Insights et diagnostic logs vers Log Analytics.
  • Scaling : Utilisez autoscale min 10/max 100 basé sur CPU/connections.

Erreurs courantes à éviter

  • Subnet trop petit : /27 échoue avec WAF ; utilisez /26 minimum.
  • Pas de health probe : Backends marqués unhealthy → 502 errors ; toujours /healthz valide.
  • Certificat manquant : Listener HTTPS ko ; uploadez PFX/keyvault ref.
  • Public IP non associé : Pas d'accès externe ; vérifiez az network public-ip create si omis.

Pour aller plus loin