Partager via


Fiabilité dans Pare-feu Azure

Pare-feu Azure est un service de sécurité réseau managé basé sur le cloud qui protège les ressources Réseau virtuel Azure. Il s’agit d’un service de pare-feu entièrement avec état qui inclut une haute disponibilité intégrée et une scalabilité cloud illimitée.

Lorsque vous utilisez Azure, reliability est une responsabilité partagée. Microsoft fournit une gamme de fonctionnalités pour prendre en charge la résilience et la récupération. Vous êtes responsable de comprendre le fonctionnement de ces fonctionnalités dans tous les services que vous utilisez et de sélectionner les fonctionnalités dont vous avez besoin pour atteindre vos objectifs métier et vos objectifs de temps d’activité.

Cet article explique comment rendre Pare-feu Azure résilient à diverses pannes et problèmes potentiels, notamment les pannes temporaires, les pannes de zone de disponibilité et les pannes de région. Il décrit également la résilience pendant la maintenance du service et met en évidence certaines informations clés sur le contrat de niveau de service du pare-feu (SLA).

Recommandations concernant le déploiement de production

Pour en savoir plus sur le déploiement de Pare-feu Azure pour prendre en charge les exigences de fiabilité de votre solution et sur la façon dont la fiabilité affecte d'autres aspects de votre architecture, consultez les meilleures pratiques Architecture pour Pare-feu Azure dans le framework Azure Well-Architected.

Vue d’ensemble de l’architecture de fiabilité

Une instance fait référence à une unité au niveau de la machine virtuelle du pare-feu. Chaque instance représente l’infrastructure qui gère le trafic et effectue des vérifications de pare-feu.

Pour obtenir une haute disponibilité d’un pare-feu, Pare-feu Azure fournit automatiquement au moins deux instances, sans nécessiter votre intervention ou votre configuration. Le pare-feu s'adapte automatiquement lorsque le débit moyen, la consommation du CPU et l'utilisation de la connexion atteignent des seuils prédéfinis. Pour plus d’informations, consultez Pare-feu Azure performances. La plateforme gère automatiquement la création d’instances, la surveillance de l’intégrité et le remplacement d’instances non saines.

Pour vous protéger contre les défaillances de serveur et de rack de serveur, Pare-feu Azure distribue automatiquement des instances entre plusieurs domaines d’erreur au sein d’une région.

Le diagramme suivant illustre un pare-feu avec deux instances :

Diagram qui montre Pare-feu Azure avec deux instances.

Pour augmenter la redondance et la disponibilité pendant les défaillances du centre de données, Pare-feu Azure active automatiquement la redondance de zone dans les régions qui prennent en charge plusieurs zones de disponibilité, répartissant les instances entre au moins deux zones de disponibilité.

Résilience aux erreurs temporaires

Les erreurs temporaires sont des défaillances courtes et intermittentes dans les composants. Elles se produisent fréquemment dans un environnement distribué comme le cloud, et font partie intégrante des opérations ordinaires. Les erreurs temporaires se corrigent après une courte période de temps. Il est important que vos applications puissent gérer les erreurs temporaires, généralement en réessayant les requêtes affectées.

Toutes les applications hébergées dans le cloud doivent suivre les instructions de gestion des erreurs temporaires Azure lorsqu’elles communiquent avec les API, bases de données et autres composants hébergés dans le cloud. Pour plus d’informations, consultez Recommandations pour la gestion des erreurs temporaires.

Pour les applications qui se connectent via Pare-feu Azure, implémentez une logique de nouvelle tentative avec une interruption exponentielle pour gérer les problèmes de connexion temporaires potentiels. Le caractère avec état du « Pare-feu Azure » garantit que les connexions légitimes restent actives pendant de brèves interruptions réseau.

Pendant les opérations de mise à l’échelle, qui prennent cinq à sept minutes, le pare-feu conserve les connexions existantes alors qu’il ajoute de nouvelles instances de pare-feu pour gérer une charge accrue.

Résilience aux échecs de zone de disponibilité

Zones d’indisponibilité sont des groupes physiquement distincts de centres de données au sein d’une région Azure. Lorsqu'une zone tombe en panne, les services peuvent basculer vers l'une des zones restantes.

Pare-feu Azure est automatiquement déployé en tant que zone redondante dans les régions qui prennent en charge plusieurs zones de disponibilité. Un pare-feu est redondant interzone lorsque vous le déployez sur au moins deux zones de disponibilité.

Pare-feu Azure prend en charge les modèles de déploiement redondant interzone et zonal :

  • Zone redondante : Dans les régions qui prennent en charge les zones de disponibilité, Azure distribue automatiquement les instances de pare-feu entre au moins deux zones de disponibilité. Azure gère automatiquement l’équilibrage de charge et le basculement entre les zones. Ce modèle de déploiement est la valeur par défaut de tous les nouveaux pare-feu.

    Les pare-feu redondants interzone obtiennent le contrat de niveau de service (SLA) de durée de fonctionnement le plus élevé. Utilisez-les pour les charges de travail de production qui nécessitent une disponibilité maximale.

    Le diagramme suivant illustre un pare-feu redondant interzone avec trois instances réparties entre trois zones de disponibilité :

    Diagram qui montre Pare-feu Azure avec trois instances, chacune dans une zone de disponibilité distincte.

    Note

    Tous les déploiements de pare-feu dans des régions avec plusieurs zones de disponibilité sont automatiquement redondants interzone. Cette règle s’applique aux déploiements via le portail Azure et les déploiements basés sur l’API (Azure CLI, PowerShell, Bicep, modèles ARM, Terraform).

  • Zonal : Dans des scénarios spécifiques où des contraintes de capacité existent ou des exigences de latence sont essentielles, vous pouvez déployer des Pare-feu Azure dans une zone de disponibilité spécifique à l’aide d’outils basés sur l’API (Azure CLI, PowerShell, Bicep, modèles ARM, Terraform). Vous déployez toutes les instances d’un pare-feu zonal dans cette zone.

    Le diagramme suivant montre un pare-feu zonal avec trois instances déployées dans la même zone de disponibilité :

    Diagram montrant Pare-feu Azure avec trois instances, toutes dans la même zone de disponibilité.

    Important

    Vous pouvez uniquement créer des déploiements zonaux via des outils basés sur l’API. Vous ne pouvez pas les configurer via le portail Azure. Les déploiements de pare-feu zonaux existants seront migrés vers des déploiements redondants interzones à l’avenir. Utilisez des déploiements redondants interzone chaque fois que cela est possible pour obtenir le contrat SLA de disponibilité le plus élevé. Un pare-feu zonal seul ne fournit pas de résilience à une panne de zone de disponibilité.

Migration des déploiements existants

Auparavant, Pare-feu Azure déploiements qui ne sont pas configurés pour être redondants interzones ou zonaux sont nonzonal ou région. Tout au long de l’année civile 2026, Azure migre tous les déploiements de pare-feu nonzonaux existants vers des déploiements redondants interzones dans des régions qui prennent en charge plusieurs zones de disponibilité.

Spécifications

  • Support de région : Pare-feu Azure prend en charge les zones de disponibilité dans toutes les régions qui prennent en charge les zones de disponibilité, où le service Pare-feu Azure est disponible.
  • Tous les niveaux de Pare-feu Azure prennent en charge les zones de disponibilité.
  • Les pare-feu redondants interzone nécessitent des adresses IP publiques standard configurées pour être redondantes interzone.
  • Les pare-feu zonaux (déployés via des outils basés sur l’API) nécessitent des adresses IP publiques standard et peuvent être configurés pour être redondants interzones ou zonaux dans la même zone que le pare-feu.

Coûts

Il n’existe aucun coût supplémentaire pour les déploiements de pare-feu redondant interzone.

Configurez la prise en charge des zones de disponibilité

Cette section explique la configuration de la zone de disponibilité pour vos pare-feu.

  • Créer un nouveau pare-feu : Tous les nouveaux déploiements de Pare-feu Azure dans les régions avec plusieurs zones de disponibilité sont automatiquement redondants interzone par défaut. Cette règle s’applique aux déploiements basés sur le portail et aux API.

    • zone redondante (par défaut) : Lorsque vous déployez un nouveau pare-feu dans une région avec plusieurs zones de disponibilité, Azure distribue automatiquement les instances entre au moins deux zones de disponibilité. Aucune configuration supplémentaire n’est requise. Pour plus d’informations, consultez Deploy Pare-feu Azure à l’aide du portail Azure.

      • Azure portal : déploie automatiquement des pare-feu redondants interzone. Vous ne pouvez pas sélectionner une zone de disponibilité spécifique via le portail.
      • outils API (Azure CLI, PowerShell, Bicep, modèles ARM, Terraform) : Déployez des pare-feu redondants interzone par défaut. Vous pouvez éventuellement spécifier des zones pour le déploiement.

      Pour plus d’informations sur le déploiement d’un pare-feu à zones redondantes, consultez Déployer un pare-feu Azure avec des zones de disponibilité.

    • Zonal (outils basés sur l’API uniquement) : Pour déployer un pare-feu dans une zone de disponibilité spécifique (par exemple, en raison de contraintes de capacité dans une région), utilisez des outils basés sur des API tels que Azure CLI, PowerShell, Bicep, des modèles ARM ou Terraform. Spécifiez une zone unique dans votre configuration de déploiement. Cette option n'est pas disponible via le portail Azure.

      Note

      Lorsque vous sélectionnez les zones de disponibilité à utiliser, vous sélectionnez en fait la zone de disponibilité logique. Si vous déployez d’autres composants de charge de travail dans un autre abonnement Azure, ils peuvent utiliser un autre numéro de zone de disponibilité logique pour accéder à la même zone de disponibilité physique. Pour plus d’informations, consultez Zones de disponibilité physiques et logiques.

  • Pare-feu existants : Tous les déploiements de pare-feu nonzonaux (régionaux) existants sont automatiquement migrés vers des déploiements redondants interzones dans des régions qui prennent en charge plusieurs zones de disponibilité. Les déploiements de pare-feu zonaux existants (épinglés à une zone spécifique) sont migrés vers des déploiements redondants interzone à une date ultérieure.

  • Contraintes de capacité : Si une région n’a pas de capacité pour un déploiement redondant interzone (nécessitant au moins deux zones de disponibilité), le déploiement échoue. Dans ce scénario, vous pouvez déployer un pare-feu zonal dans une zone de disponibilité spécifique à l’aide d’outils basés sur l’API.

Comportement lorsque toutes les zones sont saines

Cette section décrit ce qu’il faut attendre lorsque Pare-feu Azure est configuré avec la prise en charge des zones de disponibilité et que toutes les zones de disponibilité sont opérationnelles.

  • Routage du trafic entre les zones : Le comportement de routage du trafic dépend de la configuration de la zone de disponibilité utilisée par votre pare-feu.

    • À zone redondante : Pare-feu Azure distribue automatiquement les requêtes entrantes entre les instances dans toutes les zones que votre pare-feu utilise. Cette configuration active-active garantit des performances et une répartition de charge optimales dans des conditions de fonctionnement normales.

    • Zonal : Si vous déployez plusieurs instances zonales dans différentes zones, vous devez configurer le routage du trafic à l’aide de solutions d’équilibrage de charge externes comme Azure Load Balancer ou Azure Traffic Manager.

  • Gestion des instances : La plateforme gère automatiquement l’emplacement des instances dans les zones que votre pare-feu utilise. Il remplace les instances ayant échoué et gère le nombre d’instances configurées. La surveillance de l’état de santé garantit que seules les instances saines reçoivent du trafic.

  • la réplication des données entre les zones : Pare-feu Azure n'a pas besoin de synchroniser l'état de connexion à travers les zones de disponibilité. Instance qui traite la requête conserve l’état de chaque connexion.

Comportement lors d’une défaillance de zone

Cette section décrit ce qu’il faut attendre lorsque Pare-feu Azure est configuré avec la prise en charge des zones de disponibilité et qu’une ou plusieurs zones de disponibilité ne sont pas disponibles.

  • Détection et réponse : La responsabilité de la détection et de la réponse dépend de la configuration de la zone de disponibilité utilisée par votre pare-feu.

    • Zone redondante : Pour les instances configurées pour utiliser la redondance de zone, la plateforme Pare-feu Azure détecte et réagit à une défaillance dans une zone de disponibilité. Vous n’avez pas besoin de lancer un basculement de zone.

    • Zonal: Pour que les pare-feu configurés soient zonaux, vous devez détecter la perte d’une zone de disponibilité et lancer un basculement vers un pare-feu secondaire que vous créez dans une autre zone de disponibilité.

  • Notification: Microsoft ne vous avertit pas automatiquement lorsqu’une zone est en panne. Toutefois, vous pouvez utiliser Azure Service Health pour comprendre l’intégrité globale du service, y compris les défaillances de zone, et vous pouvez configurer des alertes d’intégrité Service Health pour vous avertir des problèmes.
  • Connexions actives : Lorsqu’une zone de disponibilité n’est pas disponible, les demandes en cours qui se connectent à une instance de pare-feu dans la zone de disponibilité défectueuse peuvent se terminer et nécessiter des nouvelles tentatives.

  • Expected data loss : Aucune perte de données n'est attendue pendant le basculement de zone, car Pare-feu Azure ne stocke pas de données client persistantes.

  • Temps d’arrêt attendu : Le temps d’arrêt dépend de la configuration de la zone de disponibilité utilisée par votre pare-feu.

    • Redondant interzone : Attendez un temps d’arrêt minimal (généralement quelques secondes) pendant une panne de zone de disponibilité. Les applications clientes doivent suivre les pratiques de gestion des erreurs temporaires, notamment l’implémentation de stratégies de nouvelle tentative avec une interruption exponentielle.

    • Zonal : Lorsqu’une zone n’est pas disponible, votre pare-feu reste indisponible jusqu’à ce que la zone de disponibilité récupère.

  • Réacheminement du trafic : Le comportement de réacheminement du trafic dépend de la configuration de la zone de disponibilité utilisée par votre pare-feu.

    • Redondant interzone : Le trafic redirige automatiquement vers des zones de disponibilité saines. Si nécessaire, la plateforme crée de nouvelles instances de pare-feu dans des zones saines.

    • Zonal : Lorsqu’une zone n’est pas disponible, votre pare-feu zonal n’est pas disponible. Si vous disposez d’un pare-feu secondaire dans une autre zone de disponibilité, vous êtes responsable de la réacheminement du trafic vers ce pare-feu.

Restauration automatique

Le comportement de restauration automatique dépend de la configuration de la zone de disponibilité utilisée par votre pare-feu.

  • Zone redondante : Après la récupération de la zone de disponibilité, Pare-feu Azure redistribue automatiquement des instances dans toutes les zones que votre pare-feu utilise et restaure l'équilibrage de charge normal entre les zones.

  • Zonal : Une fois la zone de disponibilité récupérée, vous êtes responsable de la réacheminement du trafic vers le pare-feu dans la zone de disponibilité d’origine.

Tester les pannes de zone

Les options de test des défaillances de zone dépendent de la configuration de la zone de disponibilité de votre pare-feu.

  • Zone redondante : La plateforme Pare-feu Azure gère le routage du trafic, le basculement et le rétablissement pour les ressources de pare-feu redondantes par zone. Cette fonctionnalité est entièrement gérée. Vous n’avez donc pas besoin de lancer ou de valider les processus d’échec de zone de disponibilité.

  • Zonal : Vous pouvez simuler des aspects de l’échec d’une zone de disponibilité en arrêtant un pare-feu. Utilisez cette approche pour tester la façon dont d’autres systèmes et équilibreurs de charge gèrent une panne dans le pare-feu. Pour plus d’informations, consultez Stop et démarrez Pare-feu Azure.

Résilience aux défaillances à l’échelle de la région

Pare-feu Azure est un service à région unique. Si la région n’est pas disponible, votre ressource de pare-feu n’est pas disponible.

Solutions multirégions personnalisées pour la résilience

Pour implémenter une architecture multirégionale, utilisez des pare-feu distincts. Cette approche vous oblige à déployer un pare-feu indépendant dans chaque région, à router le trafic vers le pare-feu régional approprié et à implémenter une logique de basculement personnalisée. Tenez compte des points suivants :

  • Utilisez Azure Firewall Manager pour la gestion centralisée des stratégies sur plusieurs pare-feu. Utilisez la méthode de stratégie de pare-feu pour la gestion centralisée des règles sur plusieurs instances de pare-feu.

  • Implement le routage du trafic à l’aide de Traffic Manager ou de Azure Front Door.

Pour obtenir un exemple d’architecture illustrant des architectures de sécurité réseau multirégions, consultez Équilibrage de charge multirégion à l’aide de Traffic Manager, de Pare-feu Azure et d’Application Gateway.

Résilience à la maintenance du service

Pare-feu Azure effectue régulièrement des mises à niveau de service et d’autres formes de maintenance.

Vous pouvez configurer des fenêtres de maintenance quotidienne pour aligner les planifications de mise à niveau avec vos besoins opérationnels. Pour plus d’informations, consultez Configurer la maintenance contrôlée par le client pour Pare-feu Azure.

Contrat de niveau de service

Le contrat de niveau de service (SLA) pour Azure services décrit la disponibilité attendue de chaque service et les conditions que votre solution doit respecter pour atteindre cette attente de disponibilité. Pour plus d’informations, consultez les SLA pour les services en ligne.

Pare-feu Azure fournit un contrat SLA de disponibilité plus élevé pour les pare-feu redondants interzone déployés sur deux zones de disponibilité ou plus.