Lorsque vous concevez votre zone de destination, vous devez choisir une conception de réseau adaptée à votre organisation. Ce document décrit quatre conceptions de réseau courantes et vous aide à choisir l'option qui répond le mieux aux exigences de votre entreprise, ainsi que ses préférences pour un contrôle centralisé ou décentralisé. Il est destiné aux ingénieurs réseau, architectes et professionnels techniques qui sont impliqués dans la création de la conception du réseau pour la zone de destination de votre organisation.
Cet article fait partie d'une série de documents consacrés aux zones de destination.
Choisir la conception de votre réseau
La conception du réseau que vous choisissez dépend principalement des facteurs suivants :
- Contrôle centralisé ou décentralisé : en fonction des préférences de votre organisation, vous devez choisir l'une des options suivantes :
- Centraliser le contrôle sur le réseau, y compris l'adressage IP, le routage et le pare-feu entre différentes charges de travail.
- Donner à vos équipes plus d'autonomie pour gérer leurs propres environnements et créer des éléments réseau au sein de leur environnement.
- Options de connectivité cloud sur site ou hybride : toutes les conceptions de réseau décrites dans ce document permettent d'accéder depuis des environnements sur site à des environnements cloud via Cloud VPN ou Cloud Interconnect. Toutefois, certaines conceptions nécessitent la configuration de plusieurs connexions en parallèle, tandis que d'autres utilisent la même connexion pour toutes les charges de travail.
- Exigences de sécurité : votre organisation peut exiger que le trafic entre différentes charges de travail dans Google Cloud passe par des dispositifs réseau centralisés tels que les pare-feu nouvelle génération (NGFW). Cette contrainte influence la conception de votre réseau cloud privé virtuel (VPC).
- Évolutivité : certaines conceptions peuvent mieux convenir à votre organisation, en fonction du nombre de charges de travail que vous souhaitez déployer, du nombre de machines virtuelles (VM), des équilibreurs de charge internes et d'autres ressources qui seront consommées.
Points de décision pour la conception du réseau
L'organigramme ci-dessous montre les décisions que vous devez prendre pour choisir la meilleure conception de réseau pour votre organisation.
Le schéma précédent vous aide à répondre aux questions suivantes :
- Avez-vous besoin d'inspecter la couche 7 en utilisant des dispositifs réseau entre différentes charges de travail dans Google Cloud ?
- Si oui, consultez la section Topologie en étoile avec serveurs centralisés.
- Si ce n'est pas le cas, passez à la question suivante.
- De nombreuses charges de travail nécessitent-elles une connectivité sur site ?
- Si oui, passez au point de décision 4.
- Si ce n'est pas le cas, passez à la question suivante.
- Vos charges de travail peuvent-elles communiquer à l'aide de points de terminaison privés dans un producteur de services et un modèle grand public ?
- Si oui, consultez la section Exposer les services dans un modèle de producteur grand public avec Private Service Connect.
- Si ce n'est pas le cas, passez à la question suivante.
- Voulez-vous administrer le pare-feu et le routage de manière centralisée?
- Si oui, consultez la section Réseau VPC partagé pour chaque environnement.
- Si ce n'est pas le cas, consultez la section Topologie en étoile sans dispositifs.
Ce graphique est conçu pour vous aider à prendre une décision. Toutefois, plusieurs conceptions peuvent être adaptées à votre organisation, comme c'est souvent le cas. Nous vous recommandons alors de choisir la conception qui correspond le mieux à votre cas d'utilisation.
Options de conception du réseau
Les sections suivantes décrivent quatre options de conception courantes. Nous recommandons l'option 1 pour la plupart des cas d'utilisation. Les autres conceptions décrites dans cette section sont des alternatives qui s'appliquent à des exigences organisationnelles spécifiques.
Le meilleur cas d'utilisation peut aussi être un réseau qui combine les éléments de plusieurs options de conception décrites dans cette section. Par exemple, vous pouvez utiliser des réseaux VPC partagés dans des topologies en étoile pour une meilleure collaboration, un contrôle centralisé et un nombre limité de spokes VPC. Vous pouvez également concevoir la plupart des charges de travail dans une topologie de VPC partagé, mais isoler un petit nombre de charges de travail dans des réseaux VPC distincts qui n'exposent que les services via quelques points de terminaison définis à l'aide dePrivate Service Connect.
Option 1 : Réseau VPC partagé pour chaque environnement
Nous recommandons cette conception de réseau pour la plupart des cas d'utilisation. Cette conception utilise des réseaux VPC partagés distincts pour chaque environnement de déploiement disponible dans Google Cloud (développement, test et production). Cette conception vous permet de gérer de manière centralisée les ressources réseau d'un réseau commun et d'isoler les réseaux entre les différents environnements.
Utilisez cette conception lorsque les conditions suivantes sont remplies :
- Vous souhaitez contrôler de manière centralisée les règles de pare-feu et de routage.
- Vous avez besoin d'une infrastructure simple et évolutive.
- Vous avez besoin d'une gestion centralisée de l'espace d'adressage IP.
Évitez cette conception lorsque les conditions suivantes sont remplies :
- Vous souhaitez que les équipes de développeurs disposent d'une autonomie totale, et qu'elles puissent gérer leurs propres règles de pare-feu, leur routage et leur appairage vers d'autres réseaux d'équipe.
- Vous avez besoin d'une inspection de couche 7 à l'aide des dispositifs NGFW.
Le schéma suivant illustre un exemple d'implémentation de cette conception.
Le schéma précédent montre les éléments suivants :
- Le réseau sur site est réparti sur deux emplacements géographiques.
- Il se connecte via des instances Cloud Interconnect redondantes à deux réseaux VPC partagés distincts, un pour la production et un pour le développement.
- Les environnements de production et de développement sont connectés aux deux instances Cloud Interconnect avec des rattachements VLAN différents.
- Chaque VPC partagé comporte des projets de service qui hébergent les charges de travail.
- Les règles de pare-feu sont gérées de manière centralisée dans le projet hôte.
- L'environnement de développement a la même structure de VPC que l'environnement de production.
De par sa conception, le trafic d'un environnement ne peut pas atteindre un autre environnement. Toutefois, si des charges de travail spécifiques doivent communiquer entre elles, vous pouvez autoriser le transfert de données via des canaux contrôlés sur site ou partager des données entre les applications avec des services Google Cloud tels que Cloud Storage ou Pub/Sub. Nous vous recommandons d'éviter de connecter directement des environnements séparés via l'appairage de réseaux VPC, car cela augmente le risque de mélanger accidentellement des données entre les environnements. L'utilisation de l'appairage de réseaux VPC entre environnements volumineux augmente également le risque d'atteindre les quotas VPC autour de l'appairage et des groupes d'appairage.
Pour en savoir plus, consultez les ressources suivantes :
- Présentation du VPC partagé
- Architecture de VPC partagé dans le guide sur les principes de base de l'entreprise
- Architecture de référence dans les bonnes pratiques de conception de VPC
- Étape de déploiement de Terraform : mise en réseau avec des environnements distincts dans le cadre du framework Fabric FAST
- Étape de réseau pour l'exemple de fondation Terraform à l'aide du kit Cloud Foundation
Pour implémenter cette option de conception, consultez la section Option de création 1 : Réseau VPC partagé pour chaque environnement.
Option 2 : Topologie en étoile avec des serveurs centralisés
Cette conception de réseau utilise la topologie en étoile. Un réseau VPC hub contient un ensemble de VM de dispositif réseau, tels que des NGFW, connectés aux réseaux VPC spoke contenant les charges de travail. Le trafic entre les charges de travail, les réseaux sur site ou le réseau Internet est acheminé via des VM de dispositif réseau pour l'inspection et le filtrage.
Utilisez cette conception lorsque les conditions suivantes sont remplies :
- Vous devez effectuer une inspection de couche 7 entre différentes charges de travail ou applications.
- Vous avez un mandat d'entreprise qui spécifie le dispositif de sécurité pour tout le trafic.
Évitez cette conception lorsque les conditions suivantes sont remplies :
- Vous n'avez pas besoin d'inspecter la couche 7 pour la plupart de vos charges de travail.
- Vous souhaitez que les charges de travail sur Google Cloud ne communiquent pas entre elles.
- Vous n'avez besoin que de l'inspection de couche 7 pour le trafic allant vers des réseaux sur site, comme décrit dans l'article Cas d'utilisation spécial avec un réseau VPC partagé sur Google Cloud.
Le schéma suivant illustre un exemple d'implémentation de ce modèle.
Le schéma précédent montre les éléments suivants :
- Environnement de production incluant un réseau VPC hub et plusieurs réseaux VPC spoke contenant les charges de travail.
- Les réseaux VPC spoke sont connectés au réseau VPC hub via l'appairage de réseaux VPC.
- Le réseau VPC hub dispose de plusieurs instances d'un dispositif virtuel dans un groupe d'instances géré. Le trafic vers le groupe d'instances géré passe par un équilibreur de charge réseau interne.
- Les réseaux VPC spoke communiquent entre eux via les dispositifs virtuels en utilisant des routes statiques avec l'équilibreur de charge interne comme saut suivant.
- Cloud Interconnect connecte les réseaux VPC de transit aux emplacements sur site.
- Les réseaux sur site sont connectés via les mêmes interconnexions Cloud Interconnect à l'aide de rattachements de VLAN distincts.
- Les réseaux VPC de transit sont connectés à une interface réseau distincte sur les dispositifs virtuels, ce qui vous permet d'inspecter et de filtrer tout le trafic vers et depuis ces réseaux à l'aide de votre dispositif.
- L'environnement de développement a la même structure de VPC que l'environnement de production.
- Cette configuration n'utilise pas la traduction d'adresse réseau source (SNAT). La traduction d'adresse réseau source n'est pas nécessaire, car Google Cloud utilise le hachage symétrique. Pour en savoir plus, consultez la section Hachage symétrique.
De par sa conception, le trafic d'un réseau spoke ne peut pas atteindre un autre réseau spoke. Toutefois, si des charges de travail spécifiques doivent communiquer entre elles, vous pouvez configurer un appairage direct entre les réseaux spokes à l'aide de l'appairage de réseaux VPC, ou vous pouvez partager des données entre des applications avec des services Google Cloud tels que Cloud Storage ou Pub/Sub
Pour maintenir une faible latence lorsque le dispositif communique entre les charges de travail, il doit se trouver dans la même région que les charges de travail. Si vous utilisez plusieurs régions dans votre déploiement cloud, vous pouvez avoir un ensemble de dispositifs et un VPC hub pour chaque environnement dans chaque région. Vous pouvez également utiliser des tags réseau avec des routes pour que toutes les instances communiquent avec le dispositif le plus proche.
Les règles de pare-feu peuvent limiter la connectivité au sein des réseaux VPC spoke contenant des charges de travail. Souvent, les équipes qui gèrent les charges de travail administrent également ces règles de pare-feu. Pour les stratégies centrales, vous pouvez utiliser des stratégies de pare-feu hiérarchiques. Si vous avez besoin qu'une équipe réseau centrale dispose d'un contrôle total sur les règles de pare-feu, envisagez de déployer ces règles de manière centralisée sur tous les réseaux VPC à l'aide d'une approche GitOps. Dans ce cas, limitez les autorisations IAM aux seuls administrateurs autorisés à modifier les règles de pare-feu. Les réseaux VPC spoke peuvent également être des réseaux VPC partagés si plusieurs équipes déploient dans les spokes.
Dans cette conception, nous vous recommandons d'utiliser l'appairage de réseaux VPC pour connecter le réseau VPC hub et les réseaux VPC spoke, car cela ajoute une complexité minimale. Toutefois, le nombre maximal de spokes présente les limites suivantes :
- Limite des connexions d'appairage de réseaux VPC à partir d'un seul réseau VPC
- Limites des groupes d'appairage telles que le nombre maximal de règles de transfert pour l'équilibrage de charge TCP/UDP interne pour chaque groupe d'appairage
Si vous prévoyez d'atteindre ces limites, vous pouvez connecter les réseaux spokes via Cloud VPN. L'utilisation de Cloud VPN augmente les coûts et la complexité, et chaque tunnel Cloud VPN comporte une limite de bande passante.
Pour en savoir plus, consultez les ressources suivantes :
- Dispositifs réseau centralisés sur Google Cloud
- Architecture de transitivité hub-and-spoke dans le guide sur les principes de base de l'entreprise
- Étape de déploiement de Terraform : mise en réseau avec un dispositif de réseau virtuel dans le cadre du framework Fabric FAST
- Module de transitivité en étoile dans le cadre de l'exemple de fondation
Pour implémenter cette option de conception, consultez la section option de création 2 : Topologie en étoile avec des serveurs centralisés.
Option 3 : Topologie en étoile sans dispositifs
Cette conception de réseau utilise également une topologie en étoile, avec un réseau VPC hub qui se connecte à des réseaux sur site et des réseaux VPC spoke contenant les charges de travail. L'appairage de réseaux VPC n'étant pas transitif, les réseaux spoke ne peuvent pas communiquer directement entre eux.
Utilisez cette conception lorsque les conditions suivantes sont remplies :
- Vous souhaitez que les charges de travail ou les environnements Google Cloud ne communiquent pas entre eux à l'aide d'adresses IP internes, mais qu'ils partagent une connectivité sur site.
- Vous souhaitez donner aux équipes l'autonomie nécessaire pour gérer leurs propres règles de pare-feu et de routage.
Évitez cette conception lorsque les conditions suivantes sont remplies :
- Vous avez besoin d'une inspection de couche 7 entre les charges de travail.
- Vous souhaitez gérer les règles de routage et de pare-feu de manière centralisée.
- Vous avez besoin de communications entre des services sur site et des services gérés qui sont connectés aux spokes via un autre appairage de réseaux VPC, car l'appairage de réseaux VPC est non transitif.
Le schéma suivant illustre un exemple d'implémentation de cette conception.
Le schéma précédent montre les éléments suivants :
- Environnement de production incluant un réseau VPC hub et plusieurs réseaux VPC spoke contenant les charges de travail.
- Les réseaux VPC spoke sont connectés au réseau VPC hub via l'appairage de réseaux VPC.
- La connectivité aux emplacements sur site passe par les connexions Cloud Interconnect dans le réseau VPC hub.
- Les réseaux sur site sont connectés via les instances Cloud Interconnect à l'aide de rattachements de VLAN distincts.
- L'environnement de développement a la même structure de VPC que l'environnement de production.
De par sa conception, le trafic d'un réseau spoke ne peut pas atteindre un autre réseau spoke. Toutefois, si des charges de travail spécifiques doivent communiquer entre elles, vous pouvez configurer un appairage direct entre les réseaux spokes à l'aide de l'appairage de réseaux VPC, ou vous pouvez partager des données entre des applications avec des services Google Cloud tels que Cloud Storage ou Pub/Sub
Cette conception de réseau est souvent utilisée dans les environnements où les équipes agissent de manière autonome et sans contrôle centralisé sur les règles de pare-feu et de routage. Cependant, l'échelle de cette conception présente les limites suivantes :
Limite des connexions d'appairage de réseaux VPC à partir d'un seul réseau VPC
Limites des groupes d'appairage telles que le nombre maximal de règles de transfert pour l'équilibrage de charge réseau interne à stratégie directe pour chaque groupe d'appairage.
Par conséquent, cette conception n'est généralement pas utilisée dans les grandes entreprises qui ont de nombreuses charges de travail distinctes sur Google Cloud.
Vous pouvez utiliser Cloud VPN au lieu de l'appairage de réseaux VPC comme variante de conception. Cloud VPN vous permet d'augmenter le nombre de spokes, mais ajoute une limite de bande passante pour chaque tunnel et augmente la complexité et les coûts. Lorsque vous utilisez des annonces de routage personnalisées, Cloud VPN permet également la transitivité entre les spokes sans que vous ayez besoin de connecter directement tous les réseaux spokes.
Pour en savoir plus, consultez les ressources suivantes :
- Architecture hub-and-spoke
- Architecture hub-and-spoke dans le guide sur les principes de base de l'entreprise
- Étape de déploiement de Terraform : mise en réseau avec appairage de réseau VPC dans le cadre du framework Fabric FAST
- Étape de déploiement de Terraform : mise en réseau avec Cloud VPN dans le cadre du framework Fabric FAST
Pour implémenter cette option de conception, consultez la section Option de création 3 : Topologie en étoile sans dispositifs.
Option 4 : Exposer les services dans un modèle de producteur grand public avec Private Service Connect
Dans cette conception de réseau, chaque équipe ou charge de travail obtient son propre réseau VPC, qui peut également être un réseau VPC partagé. Chaque réseau VPC est géré indépendamment et utilise Private Service Connect pour exposer tous les services devant être accessibles depuis l'extérieur du réseau VPC.
Utilisez cette conception lorsque les conditions suivantes sont remplies :
- Les charges de travail ne communiquent qu'entre elles et avec l'environnement sur site via des points de terminaison définis.
- Vous souhaitez que les équipes soient indépendantes les unes des autres, et qu'elles gèrent leur propre espace d'adresses IP, leurs pare-feu et leurs règles de routage.
Évitez cette conception lorsque les conditions suivantes sont remplies :
- La communication entre les services et les applications utilise de nombreux ports ou canaux différents, ou les ports et les canaux changent fréquemment.
- La communication entre les charges de travail utilise des protocoles autres que TCP ou UDP.
- Vous avez besoin d'une inspection de couche 7 entre les charges de travail.
Le schéma suivant illustre un exemple d'implémentation de ce modèle.
Le schéma précédent montre les éléments suivants :
- Les charges de travail distinctes sont situées dans des projets et des réseaux VPC distincts.
- Une VM cliente d'un réseau VPC peut se connecter à une charge de travail d'un autre réseau VPC via un point de terminaison Private Service Connect.
- Le point de terminaison est associé à un rattachement de service dans le réseau VPC où se trouve le service. Le rattachement de service peut se trouver dans une région différente de celle du point de terminaison, si le point de terminaison est configuré pour l'accès mondial.
- Le rattachement de service se connecte à la charge de travail via Cloud Load Balancing.
- Les clients dans le VPC de charge de travail peuvent atteindre les charges de travail situées sur site comme suit :
- Le point de terminaison est connecté à un rattachement de service dans un réseau VPC de transit.
- Le rattachement de service est connecté au réseau sur site à l'aide de Cloud Interconnect.
- Un équilibreur de charge d'application interne est associé au rattachement de service et utilise un groupe de points de terminaison du réseau hybride pour équilibrer la charge de trafic entre les points de terminaison situés sur site.
- Les clients sur site peuvent également atteindre des points de terminaison dans le réseau VPC de transit qui se connectent aux rattachements de service dans les réseaux VPC de charge de travail.
Pour en savoir plus, consultez les ressources suivantes :
- Publier des services gérés à l'aide de Private Service Connect
- Accéder aux services publiés via des points de terminaison
Pour implémenter cette option de conception, consultez la section Option de création 4 : Exposer les services dans un modèle de producteur grand public avec Private Service Connect.
Bonnes pratiques pour le déploiement réseau
Une fois que vous avez choisi la meilleure conception de réseau pour votre cas d'utilisation, nous vous recommandons de mettre en œuvre les bonnes pratiques suivantes :
- Utilisez les réseaux VPC en mode personnalisé et supprimez le réseau par défaut pour mieux contrôler les adresses IP de votre réseau.
Limitez l'accès externe en utilisant Cloud NAT pour les ressources nécessitant un accès Internet et en réduisant l'utilisation des adresses IP publiques aux ressources accessibles via Cloud Load Balancing. Pour plus d'informations, consultez la page Créer une connectivité Internet pour les VM privées.
Si vous utilisez Cloud Interconnect, assurez-vous de suivre les topologies recommandées pour les applications non critiques ou en production. Utilisez des connexions redondantes pour respecter le contrat de niveau de service du service. Vous pouvez également connecter Google Cloud à des réseaux sur site via Cloud VPN.
Appliquez les règles introduites dans la section Limiter l'accès externe à l'aide de règles d'administration pour limiter l'accès direct à Internet depuis votre VPC.
Utilisez des stratégies de pare-feu hiérarchiques pour que les stratégies de pare-feu soient héritées de manière cohérente dans votre organisation ou vos dossiers.
Suivez les bonnes pratiques DNS pour la configuration DNS hybride entre votre réseau sur site et Google Cloud.
Pour plus d'informations, consultez les bonnes pratiques et architectures de référence pour la conception de VPC.
Étapes suivantes
- Implémentez votre conception de réseau de zone de destination Google Cloud
- Décidez de la sécurité de votre zone de destination Google Cloud (document suivant de cette série).
- Consultez les Bonnes pratiques pour la conception de réseaux VPC.
- Apprenez à utiliser les dispositifs réseau centralisés sur Google Cloud.
- Apprenez-en plus sur Private Service Connect.