Topologie de réseau plat à charge de travail unique

Un réseau plat est la topologie de réseau la plus simple Azure : un réseau virtuel avec plusieurs sous-réseaux hébergeant une seule charge de travail. Cet article explique quand utiliser ce modèle et comment l’implémenter.

Présentation de cet article

Cet article décrit la topologie de réseau Azure la plus simple : un seul réseau virtuel avec plusieurs sous-réseaux qui héberge une charge de travail. Utilisez ce modèle lorsque vous disposez d’une seule application gérée par une équipe et que vous n’avez pas besoin de services partagés comme un pare-feu central ou une passerelle VPN.

Qui a besoin de cet article

Lisez cet article si :

  • Vous déployez votre première charge de travail dans Azure.
  • Une seule équipe possède et exploite toutes les ressources.
  • Vous n’avez pas besoin de services réseau partagés (pare-feu, Bastion, passerelle) sur plusieurs charges de travail.
  • Vous souhaitez le réseau le plus simple qui fournit toujours l’isolation et la sécurité au niveau du sous-réseau.

Objectif de la migration lift-and-shift : un réseau virtuel plat unique avec un sous-réseau par composant constitue souvent la première étape idéale pour réhéberger une charge de travail dans une seule région.

Moderniser le focus : Utilisez un réseau plat pour un pilote PaaS précoce ou une charge de travail modernisée unique et concevez ses sous-réseaux afin qu’il puisse passer de manière propre au hub-and-spoke lorsque vous ajoutez des services partagés ou une deuxième région.

Priorité au multicloud : Utilisez un réseau virtuel plat comme point d’ancrage unique dans Azure lors d’une migration multicloud : déployez d’abord la charge de travail, puis planifiez son espace d’adressage et sa segmentation afin qu’elle puisse être intégrée à un hub ou à Virtual WAN à mesure que l’architecture gagne en maturité.

Azure services et fonctionnalités

La topologie de réseau plat utilise ces services de base Azure :

Service Rôle dans cette topologie
Réseau virtuel Azure Fournit un espace d’adressage privé et isolé pour votre charge de travail. Un réseau virtuel est étendu à une seule région Azure.
Sous-réseaux + groupes de sécurité réseau (NSG) Les sous-réseaux séparent les niveaux d’application. Les NSG filtrent le trafic entrant et sortant au niveau de chaque limite de sous-réseau. Les NSG sont avec état : le trafic de retour des connexions autorisées est automatiquement autorisé.
zone DNS privée Azure Fournit une résolution de noms interne pour les ressources au sein du réseau virtuel. Liez la zone avec l’inscription automatique activée afin que les machines virtuelles obtiennent automatiquement des enregistrements DNS.
Sous-réseau de passerelle(facultatif) Héberge une passerelle VPN ou ExpressRoute si vous avez besoin d’une connexion unique à un réseau local.

Comment choisir : rester sur un réseau plat ou passer à une architecture hub-and-spoke ?

Utilisez le tableau de décision suivant pour déterminer si la topologie plate est appropriée pour votre environnement ou si vous devez adopter une topologie hub-and-spoke à la place.

Pathologie Recommendation
Charge de travail unique, équipe unique, aucun service partagé Rester sur un réseau plat : cet article s'applique.
Une deuxième charge de travail indépendante a besoin de son propre isolement réseau Passer à une topologie hub-and-spoke
Vous avez besoin d’un pare-feu partagé, d’une passerelle VPN ou d’une Azure Bastion entre les charges de travail Passer à une topologie hub-and-spoke
Les stratégies de sécurité doivent être gérées de manière centralisée sur plusieurs charges de travail Passer à une topologie hub-and-spoke

Tip

Si vous prévoyez d’ajouter une deuxième charge de travail d’ici six à douze mois, envisagez d’opter dès le premier jour pour une architecture hub-and-spoke. La surcharge est minimale, car vous n’ajoutez qu’un seul réseau virtuel supplémentaire et une connexion de peering. Cette approche évite une migration perturbatrice ultérieurement.

Considérations relatives à la conception

Objectif de conception d'un réseau plat pour la migration lift-and-shift

  • Utilisez un réseau virtuel avec un sous-réseau pour chaque composant d’application (web, application, données) pour mettre en miroir une disposition classique à trois niveaux locale avec une nouvelle conception minimale.
  • Appliquez des NSG entre vos sous-réseaux pour recréer votre segmentation existante, et maintenez l’espace d’adressage aligné sur les plages d’adresses sur site afin d’éviter tout chevauchement.
  • Restez à plat pendant qu’une seule équipe possède la charge de travail et que vous n’avez pas besoin de pare-feu partagé, de passerelle ou de services Bastion.
  • Planifiez la transition vers une architecture hub-and-spoke avant d’ajouter une deuxième charge de travail, afin que les services partagés soient hébergés dans un hub au lieu d’y être intégrés après coup.

Moderniser le focus de conception de réseau plat

  • Utilisez un réseau plat pour un pilote PaaS précoce ou une charge de travail modernisée unique : placez les niveaux d’application dans les sous-réseaux et atteignez Azure PaaS via des points de terminaison privés dans un sous-réseau dédié.
  • Réservez dès le départ des sous-réseaux dédiés aux services de la plateforme que vous ajouterez, comme Application Gateway et les points de terminaison privés, afin que le réseau puisse évoluer sans réadressage.
  • Appliquez des NSG et des groupes de sécurité d'application par niveau afin que votre segmentation soit déjà en place si la charge de travail devient par la suite un spoke dans une architecture hub-and-spoke.
  • Veillez à ce que l'espace d'adressage ne chevauche pas ceux de vos autres régions et réseaux virtuels afin de pouvoir établir un peering ou évoluer vers un hub ultérieurement sans renumérotation des adresses.

Focus sur la conception de réseau plat multicloud

  • Utilisez un réseau virtuel plat comme point d’ancrage unique dans Azure lors d’une migration intercloud : déployez d’abord la charge de travail, puis rattachez-y la connectivité depuis un hub à mesure que l’architecture évolue.
  • Planifiez l’espace d’adressage du réseau virtuel plat afin d’éviter le chevauchement avec les VPN AWS et les réseaux Google Cloud afin qu’il puisse rejoindre le routage IPsec ou interconnecter ultérieurement sans traduction.
  • Conservez la segmentation par niveau avec les NSG afin que la posture de sécurité de la charge de travail soit préservée lorsqu'elle deviendra un spoke derrière un hub Virtual WAN sécurisé.
  • Normaliser le nommage et le balisage de sous-réseau pour qu’ils correspondent à vos autres clouds afin que la charge de travail reste facile à mettre en corrélation pendant et après la migration.

Prerequisites

Avant d’implémenter cette topologie :

  • Un abonnement Azure avec des autorisations pour créer des réseaux virtuels et des groupes de sécurité réseau.
  • Espace d’adressage IP planifié. Un espace d’adressage /16 fournit 65 536 adresses, qui est un point de départ commun pour une charge de travail unique. Azure réserve 5 adresses par sous-réseau pour une utilisation interne. Pour obtenir des instructions détaillées, consultez Planifier l’adressage IP.
  • Compréhension des niveaux de votre application (par exemple, web, application et données) afin de pouvoir les mapper aux sous-réseaux. Pour obtenir des conseils de conception de sous-réseau, consultez Concevoir des réseaux virtuels et des sous-réseaux.

Configuration réseau

Diagramme montrant une topologie de réseau plat avec des sous-réseaux de couche web, d’application et de couche données, chacun protégé par un groupe de sécurité réseau, au sein d’un même réseau virtuel.

Une topologie de réseau plat suit cette structure :

  • Un réseau virtuel avec un espace d’adressage unique (par exemple, 10.0.0.0/16).
  • Plusieurs sous-réseaux : un par niveau d’application ou composant :
    • Sous-réseau de couche Web (par exemple, 10.0.1.0/24).
    • Sous-réseau du niveau application (par exemple, 10.0.2.0/24).
    • Sous-réseau de la couche de données (par exemple, 10.0.3.0/24).
    • Sous-réseau de passerelle (facultatif, par exemple, 10.0.255.0/27).
  • Des groupes de sécurité réseau associés à chaque sous-réseau comprenant des règles n’autorisant que le trafic nécessaire à chaque couche.
  • Une zone DNS privé liée au réseau virtuel avec l’inscription automatique activée.

Note

Planifiez soigneusement vos plages d’adresses IP. Si vous migrez ultérieurement vers une topologie hub-and-spoke, les réseaux virtuels spoke doivent avoir des plages CIDR qui ne se chevauchent pas avec le hub. Le choix d’un schéma d’adresse bien structuré empêche désormais les conflits pendant la migration.

Considérations relatives à la sécurité

Appliquez ces pratiques de sécurité à votre réseau plat :

  • Des groupes de sécurité réseau (NSG) sur chaque sous-réseau. Commencez par une stratégie par défaut bloquant tout le trafic entrant, puis ajoutez des règles d’autorisation spécifiques pour le trafic légitime entre les couches. Par exemple, autorisez HTTPS de la couche Web vers la couche Application et autorisez SQL de la couche Application à la couche Données.
  • Aucune adresse IP publique directement sur les machines virtuelles. Exposer des services via un équilibreur de charge ou Application Gateway. Utilisez Azure Bastion pour l’accès administratif.
  • DNS privé pour la résolution interne. DNS privé zones empêchent l’exposition des noms d’hôte internes par le biais de requêtes DNS publiques.
  • Isolation du sous-réseau de passerelle. Si vous ajoutez une passerelle VPN ou ExpressRoute, placez-la dans un sous-réseau dédié (nommé GatewaySubnet). Les NSG sur le sous-réseau de passerelle ne sont pas pris en charge. L’association d’un groupe de sécurité réseau à ce sous-réseau pourrait faire en sorte que votre passerelle de réseau virtuel ne fonctionne pas comme prévu.

Important

Lorsque vous supprimez une règle de groupe de sécurité réseau qui autorise une connexion, les connexions actives existantes continuent sans interruption. Seules les nouvelles connexions qui correspondent à la règle supprimée sont bloquées.

Les articles suivants fournissent des conseils plus approfondis sur les sujets connexes :

Learn more

Pour plus d’informations sur les services Azure utilisés dans cette topologie, consultez :

Étapes suivantes

Tip

Vous explorez vous-même ? Revenez au navigateur de vue d’ensemble pour trouver votre prochain article par fonctionnalité.

Étape suivante de votre parcours lift-and-shift :

Concevoir votre topologie hub-and-spoke : la plupart des migrations lift-and-shift dépassent rapidement les limites d'un réseau plat. Planifiez les services partagés centralisés à partir du début.

Ensuite, dans votre parcours de modernisation :

Concevoir votre topologie hub-and-spoke : les charges de travail modernisées comportant plusieurs services, contrôles de sécurité et équipes nécessitent une architecture hub-and-spoke dès le premier jour.

Prochaine étape de votre parcours multi-cloud :

Planifiez votre architecture de connectivité intercloud : les patrimoines multiclouds ont besoin d’une architecture de transit, et non de réseaux plats. Concevez votre modèle de connectivité multicloud.

  • Last updated on