Réseaux VPC

Un réseau cloud privé virtuel (VPC) est une version virtuelle d'un réseau physique implémentée au sein du réseau de production de Google à l'aide d'Andromeda.

Un réseau VPC effectue les opérations suivantes :

• Il fournit une connectivité à vos instances de machines virtuelles (VM) Compute Engine.
• Il propose des équilibreurs de charge réseau internes à stratégie directe natifs et des systèmes proxy pour les équilibreurs de charge d'application internes.
• Il se connecte aux réseaux sur site à l'aide de tunnels Cloud VPN et de rattachements de VLAN pour Cloud Interconnect.
• Il distribue le trafic des équilibreurs de charge externes Google Cloud aux backends.

Les projets peuvent contenir plusieurs réseaux VPC. Sauf si vous créez une règle d'administration qui l'interdit, les nouveaux projets démarrent avec un réseau par défaut (un réseau VPC en mode automatique) qui possède un sous-réseau dans chaque région.

Important : Cette page décrit les réseaux VPC, qui sont différents des anciens réseaux. Les anciens réseaux ne peuvent plus être créés. Ils ne sont pas recommandés pour la production, car ils ne sont pas compatibles avec les fonctionnalités de mise en réseau avancées. Vous pouvez convertir un ancien réseau en réseau VPC. Pour afficher le type d'un réseau existant, consultez la section Afficher des réseaux.

Réseaux et sous-réseaux

Les termes subnet et subnetwork faisant référence au sous-réseau sont synonymes. Ils sont interchangeables dans Google Cloud Console, les commandes gcloud et la documentation de l'API.

Un sous-réseau et un réseau (VPC) sont deux entités distinctes. Les réseaux et les sous-réseaux sont des types de ressources différents dans Google Cloud.

Pour en savoir plus, consultez la section Sous-réseaux.

Instances de machines virtuelles

Une instance de machine virtuelle (VM) Compute Engine est une machine virtuelle hébergée sur l'infrastructure de Google. Les termes instance Compute Engine, instance de VM et VM sont synonymes. Ils sont utilisés de manière interchangeable dans la console Google Cloud, la documentation de référence de Google Cloud CLI et la documentation de l'API.

Les instances de VM incluent des clusters Google Kubernetes Engine (GKE), des instances de l'environnement flexible App Engine et d'autres produits Google Cloud basés sur des VM Compute Engine.

Pour en savoir plus, consultez la page Instances de machines virtuelles de la documentation Compute Engine.

Spécifications

Les réseaux VPC ont les propriétés suivantes :

• Les réseaux VPC, y compris leurs routes et règles de pare-feu associées, sont des ressources mondiales. Ils ne sont associés à aucune région ou zone particulière.

• Les sous-réseaux sont des ressources régionales.

• Chaque sous-réseau définit une plage d'adresses IPv4. Les sous-réseaux des réseaux VPC en mode personnalisé peuvent également avoir une plage d'adresses IPv6.

• Le trafic à destination et en provenance des instances peut être contrôlé à l'aide de règles de pare-feu de réseau. Les règles sont mises en œuvre sur les VM elles-mêmes, de sorte que le trafic ne puisse être contrôlé et consigné que lorsqu'il quitte ou atteint une VM.

• Les ressources d'un réseau VPC peuvent communiquer entre elles à l'aide d'adresses IPv4 internes, d'adresses IPv6 internes ou d'adresses IPv6 externes, sous réserve des règles de pare-feu de réseau applicables. Pour en savoir plus, consultez la section Communication au sein du réseau.

• Les instances dotées d'adresses IPv4 ou IPv6 internes peuvent communiquer avec les API et services Google. Pour en savoir plus, consultez la page Options d'accès privé pour les services.

• L'administration réseau peut être sécurisée à l'aide de rôles Identity and Access Management (IAM).

• Une organisation peut utiliser un VPC partagé pour conserver un réseau VPC dans un projet hôte commun. Les entités principales IAM autorisées d'autres projets dans la même organisation peuvent créer des ressources utilisant des sous-réseaux du réseau VPC partagé.

• Les réseaux VPC peuvent être connectés à d'autres réseaux VPC dans différents projets ou différentes organisations à l'aide de l'appairage de réseaux VPC.

• Les réseaux VPC peuvent être connectés en toute sécurité dans des environnements hybrides à l'aide de Cloud VPN ou de Cloud Interconnect.

• Les réseaux VPC sont compatibles avec le trafic GRE, y compris le trafic sur Cloud VPN et Cloud Interconnect. Les réseaux VPC ne sont pas compatibles avec GRE pour Cloud NAT, ni pour les règles de transfert pour l'équilibrage de charge et le transfert de protocole. Grâce à la compatibilité GRE, vous pouvez interrompre le trafic GRE sur une VM depuis Internet (adresse IP externe), et Cloud VPN ou Cloud Interconnect (adresse IP interne). Le trafic déchiffré peut alors être transmis à une destination accessible. GRE vous permet d'utiliser des services tels que SASE (Secure Service Access Edge) et SD-WAN.

  Remarque : La compatibilité de GRE avec les réseaux VPN et Interconnect a été testée uniquement avec GRE version 0. De plus, la compatibilité du trafic GRE ne comprend pas l'assistance de Google Cloud pour le dépannage de votre réseau superposé.

• Les réseaux VPC acceptent les adresses monodiffusion IPv4 et IPv6. Les réseaux VPC ne sont pas compatibles avec les adresses de diffusion ou de multidiffusion au sein du réseau.

  Pour en savoir plus sur les plages de sous-réseaux IPv6, consultez la section Sous-réseaux.

Exemple de réseau VPC

L'exemple suivant illustre un réseau VPC en mode personnalisé avec trois sous-réseaux dans deux régions :

Exemple de réseau VPC (cliquez pour agrandir)

• Le sous-réseau Subnet1 est défini sur 10.240.0.0/24 dans la région us-west1.
  • Deux instances de VM dans la zone us-west1-a se trouvent dans ce sous-réseau. Leurs adresses IP proviennent de la plage d'adresses disponible dans le sous-réseau subnet1.
• Le sous-réseau Subnet2 est défini sur 192.168.1.0/24 dans la région us-east1.
  • Deux instances de VM dans la zone us-east1-b se trouvent dans ce sous-réseau. Leurs adresses IP proviennent de la plage d'adresses disponible dans le sous-réseau subnet2.
• Le sous-réseau Subnet3 est défini sur 10.2.0.0/16, également dans la région us-east1.
  • Une instance de VM dans la zone us-east1-b et une deuxième instance dans la zone us-east1-c appartiennent au sous-réseau subnet3, chacune recevant une adresse IP de sa plage disponible. Les sous-réseaux étant des ressources régionales, leurs interfaces réseau peuvent être associées à tout sous-réseau de la même région que leurs zones.

Contraintes liées aux règles d'administration

• Chaque nouveau projet démarre avec un réseau VPC par défaut. Vous pouvez désactiver la création de réseaux par défaut en créant une règle d'administration avec la contrainte compute.skipDefaultNetworkCreation. Les projets qui héritent de cette règle n'ont pas de réseau par défaut.

• Vous pouvez contrôler les configurations IPv6 suivantes à l'aide de règles d'administration :

  • Désactiver l'utilisation d'IPv6 à l'extérieur du VPC : si cette option est définie sur "true", la contrainte constraints/compute.disableVpcExternalIpv6 vous empêche de configurer des sous-réseaux à double pile avec des plages IPv6 externes.

  • Désactiver l'utilisation d'IPv6 à l'intérieur du VPC : si cette option est définie sur "true", la contrainte constraints/compute.disableVpcInternalIpv6 vous empêche de configurer des sous-réseaux à double pile avec des plages IPv6 internes.

  • Désactiver toute utilisation d'IPv6 : si cette option est définie sur "true", la contrainte constraints/compute.disableAllIpv6 désactive la création ou la mise à jour de toutes les ressources impliquées dans l'utilisation d'IPv6.

Pour en savoir plus sur les contraintes, consultez la section Contraintes liées aux règles d'administration.

Mode de création du sous-réseau

Google Cloud propose deux types de réseaux VPC, déterminés par leur mode de création de sous-réseau :

• Lorsqu'un réseau VPC en mode automatique est créé, un sous-réseau de chaque région y est automatiquement créé. Ces sous-réseaux créés automatiquement utilisent un ensemble de plages d'adresses IPv4 prédéfinies qui correspondent au bloc CIDR 10.128.0.0/9. À mesure que de nouvelles régions Google Cloud deviennent disponibles, de nouveaux sous-réseaux dans ces régions sont automatiquement ajoutés aux réseaux VPC en mode automatique à l'aide d'une plage d'adresses IP de ce bloc. Outre les sous-réseaux créés automatiquement, vous pouvez ajouter manuellement d'autres sous-réseaux aux réseaux VPC en mode automatique dans les régions de votre choix, en utilisant des plages d'adresses IP autres que 10.128.0.0/9.

• Lorsqu'un réseau VPC en mode personnalisé est créé, aucun sous-réseau n'est créé automatiquement. Ce type de réseau vous offre un contrôle total sur ses sous-réseaux et ses plages d'adresses IP. Vous créez des sous-réseaux dans les régions de votre choix et en utilisant les plages d'adresses IP que vous spécifiez.

Vous pouvez basculer un réseau VPC en mode automatique vers le mode personnalisé. Il s'agit d'une conversion à sens unique : les réseaux VPC en mode personnalisé ne peuvent pas être basculés en mode automatique. Pour savoir quel type de réseau répond à vos besoins, consultez les remarques concernant les réseaux VPC en mode automatique.

Réseau par défaut

Sauf si vous choisissez de désactiver cette fonction, chaque nouveau projet démarre avec un réseau par défaut. Le réseau par défaut est un VPC en mode automatique avec des règles de pare-feu IPv4 préremplies. Le réseau par défaut ne comporte aucune règle de pare-feu IPv6 préremplie.

Remarques sur les réseaux VPC en mode automatique

Les réseaux VPC en mode automatique sont faciles à configurer et à utiliser, et ils sont parfaitement adaptés aux cas d'utilisation présentant les attributs suivants :

• La création automatique de sous-réseaux dans chaque région vous est utile.

• Les plages d'adresses IP prédéfinies des sous-réseaux ne chevauchent pas les plages d'adresses IP que vous utilisez à des fins différentes (par exemple, les connexions Cloud VPN aux ressources sur site).

Cependant, les réseaux VPC en mode personnalisé sont plus flexibles et conviennent mieux à la production. Les attributs suivants mettent en évidence les cas d'utilisation où des réseaux VPC en mode personnalisé sont recommandés ou requis :

• La création automatique de sous-réseaux dans chaque région ne vous est pas nécessaire.

• Si des sous-réseaux sont créés automatiquement à mesure que de nouvelles régions deviennent disponibles, ceux-ci peuvent chevaucher les adresses IP utilisées par les sous-réseaux créés manuellement ou les routes statiques, ou interférer avec la planification globale de votre réseau.

• Vous avez besoin d'un contrôle complet sur les sous-réseaux créés dans votre réseau VPC, y compris les régions et les plages d'adresses IP utilisées.

• Vous prévoyez de connecter votre réseau VPC à un autre réseau :

  • Étant donné que les sous-réseaux de chaque réseau VPC en mode automatique utilisent la même plage d'adresses IP prédéfinie, vous ne pouvez pas connecter les réseaux VPC en mode automatique les uns aux autres à l'aide de l'appairage de réseaux VPC ou de Cloud VPN.

  • Comme la plage CIDR 10.128.0.0/9 en mode automatique fait partie de l'espace d'adressage RFC 1918 couramment utilisé, les réseaux en dehors de Google Cloud peuvent actuellement ou ultérieurement utiliser une plage CIDR qui se chevauche.

• Vous souhaitez créer des sous-réseaux avec des plages IPv6. Les réseaux VPC en mode automatique ne sont pas compatibles avec les sous-réseaux à double pile.

Important : Les réseaux de production doivent être planifiés à l'avance. En production, nous vous recommandons d'utiliser des réseaux VPC en mode personnalisé.

Plages de sous-réseaux IPv4

Chaque sous-réseau possède une plage d'adresses IPv4 principale. Les adresses IP internes principales des ressources suivantes proviennent de la plage d'adresses IP principale du sous-réseau : instances de VM, équilibreurs de charge internes et transfert de protocole interne. Vous pouvez éventuellement ajouter des plages d'adresses IP secondaires à un sous-réseau, qui ne sont utilisées que par les plages d'adresses IP d'alias. Cependant, vous pouvez configurer des plages d'adresses IP d'alias pour les instances depuis la plage principale ou secondaire d'un sous-réseau.

Chaque plage d'adresses IPv4 principale ou secondaire de tous les sous-réseaux d'un réseau VPC doit être un bloc CIDR valide unique. Reportez-vous aux limites par réseau pour connaître le nombre de plages d'adresses IP secondaires que vous pouvez définir.

Les sous-réseaux IPv4 n'ont pas besoin de former un bloc CIDR contigu prédéfini, mais cette configuration est possible si vous le souhaitez. Par exemple, les réseaux VPC en mode automatique créent des sous-réseaux qui correspondent à une plage d'adresses IP en mode automatique prédéfinie.

Lorsque vous créez un sous-réseau dans un réseau VPC en mode personnalisé, vous choisissez la plage d'adresses IPv4 à utiliser. Pour en savoir plus, consultez les sections plages valides, plages de sous-réseaux interdites et travailler avec des sous-réseaux.

Chaque plage de sous-réseau IPv4 principale contient quatre adresses IP inutilisables. Pour plus d'informations, consultez la section Adresses inutilisables dans les plages de sous-réseaux IPv4.

Les réseaux VPC en mode automatique sont créés avec un sous-réseau par région au moment de la création et reçoivent automatiquement les nouveaux sous-réseaux dans les nouvelles régions. Les sous-réseaux possèdent uniquement des plages IPv4, et toutes les plages de sous-réseaux entrent dans le bloc CIDR 10.128.0.0/9. Les portions inutilisées de 10.128.0.0/9 sont réservées pour une utilisation future par Google Cloud. Pour en savoir plus sur la plage d'adresses IPv4 utilisée dans chaque région, consultez la section Plages de sous-réseaux IPv4 en mode automatique.

Plages de sous-réseaux IPv6

Lorsque vous créez un sous-réseau à double pile dans un réseau VPC en mode personnalisé, vous choisissez si le sous-réseau est configuré avec une plage de sous-réseau IPv6 interne ou externe.

• Les plages de sous-réseaux IPv6 internes utilisent des adresses locales uniques (ULA).

  • Les ULA sont utilisés pour la communication de VM à VM au sein des réseaux VPC. Les ULA pour IPv6 sont analogues aux adresses RFC 1918 pour IPv4. Les ULA ne sont pas accessibles depuis Internet et ne peuvent pas être routées publiquement.

• Les plages de sous-réseaux IPv6 externes utilisent des adresses de monodiffusion globales (GUA).

  • Les GUA peuvent être utilisées pour la communication de VM à VM au sein des réseaux VPC et sont également routables sur Internet.

Pour en savoir plus sur les plages de sous-réseaux IPv6, consultez la section Sous-réseaux.

Réseaux compatibles avec les sous-réseaux à double pile

Vous pouvez créer des sous-réseaux à double pile dans un réseau VPC en mode personnalisé.

Les sous-réseaux à double pile ne sont pas compatibles avec les réseaux VPC en mode automatique, y compris le réseau par défaut. Les sous-réseaux à double pile ne sont pas compatibles avec les anciens réseaux.

Si vous disposez d'un réseau VPC en mode automatique auquel vous souhaitez ajouter des sous-réseaux à double pile, vous pouvez procéder comme suit :

1. Basculez le réseau du mode automatique vers le mode personnalisé.

2. Créez des sous-réseaux à double pile ou convertissez les sous-réseaux existants en sous-réseaux à double pile.

Routes et règles de pare-feu

Routes

Les routes représentent des chemins pour les paquets sortant des instances (trafic de sortie). Pour plus d'informations sur les types de routes Google Cloud, consultez la section Routes.

Mode de routage dynamique

Chaque réseau VPC est associé à un mode de routage dynamique qui contrôle le comportement de tous les routeurs Cloud Router. Les routeurs Cloud gèrent les sessions BGP pour les produits de connectivité Google Cloud.

Pour obtenir une description des options du mode de routage dynamique, consultez la section Effets du mode de routage dynamique dans la documentation de Cloud Router.

Annonces de routage et adresses IP internes

Les adresses IP suivantes sont annoncées dans un réseau VPC :

• Adresses IPv4 internes régionales

  Utilisées pour les plages d'adresses de sous-réseaux IPv4 principales et secondaires

• Adresses IPv6 internes et externes régionales

  Utilisées pour les plages d'adresses de sous-réseaux IPv6 internes et externes

• Adresses IPv4 internes globales

  Utilisées pour les points de terminaison Private Service Connect des API Google

Si vous connectez des réseaux VPC à l'aide de l'appairage de réseaux VPC, les plages de sous-réseaux utilisant des adresses IPv4 privées sont toujours échangées. Vous pouvez définir si les plages de sous-réseaux exploitant des adresses IPv4 publiques utilisées en mode privé sont ou non échangées. Les adresses IPv4 internes globales ne sont jamais échangées dans le cadre de l'appairage. Pour en savoir plus, consultez la documentation sur l'appairage de réseaux VPC.

Lorsque vous connectez un réseau VPC à un autre réseau, tel qu'un réseau sur site, à l'aide d'un produit de connectivité Google Cloud tel que Cloud VPN, Cloud Interconnect ou un appareil de routeur :

• Vous pouvez annoncer les adresses IP internes du réseau VPC sur un autre réseau (tel qu'un réseau sur site).
• Bien que la connectivité entre un réseau VPC et un autre réseau (tel qu'un réseau sur site) puisse utiliser un routage privé fourni par un produit de connectivité Google Cloud, les adresses IP de l'autre réseau peuvent également être routables publiquement. Gardez cela à l'esprit si un réseau sur site utilise des adresses IP routables publiquement.
• Les instances de VM d'un réseau VPC contenant des plages de sous-réseaux avec des adresses IP publiques utilisées en mode privé ne peuvent pas se connecter à des ressources externes qui utilisent ces mêmes adresses IP publiques.
• Soyez particulièrement vigilant lorsque vous annoncez des adresses IP publiques utilisées en mode privé à un autre réseau (tel qu'un réseau sur site), en particulier lorsque l'autre réseau peut annoncer ces adresses IP publiques sur Internet.

Règles de pare-feu

Les règles de pare-feu hiérarchiques et les règles de pare-feu VPC s'appliquent aux paquets envoyés vers et depuis des instances de VM (et des ressources qui dépendent de VM, telles que les nœuds Google Kubernetes Engine). Ces deux types de pare-feu contrôlent le trafic même s'il se trouve entre des VM appartenant à un même réseau VPC.

Pour déterminer quelle règle de pare-feu a autorisé ou refusé une connexion donnée, consultez la page Journalisation des règles de pare-feu.

Communications et accès

Communication au sein du réseau

Les routes de sous-réseau générées par le système définissent les chemins d'envoi du trafic entre les instances du réseau à l'aide d'adresses IP internes. Pour qu'une instance puisse communiquer avec une autre, des règles de pare-feu appropriées doivent également être configurées. En effet, chaque réseau possède une règle implicite de refus de pare-feu pour le trafic entrant.

Sauf pour le réseau par défaut, vous devez explicitement créer des règles de pare-feu pour le trafic entrant ayant une priorité plus élevée afin de permettre aux instances de communiquer entre elles. Le réseau par défaut inclut plusieurs règles de pare-feu, en plus des règles implicites, y compris la règle default-allow-internal, qui autorise la communication entre instances au sein du réseau. Le réseau par défaut propose également des règles d'entrée autorisant des protocoles tels que RDP et SSH.

Les règles fournies avec le réseau par défaut sont également présentées comme des options à appliquer aux réseaux VPC en mode automatique que vous créez à l'aide de la console Google Cloud.

Conditions d'accès à Internet

Les critères suivants doivent être remplis pour qu'une instance ait un accès Internet sortant :

• Le réseau doit disposer d'une route de passerelle Internet par défaut valide ou d'une route personnalisée dont la plage d'adresses IP de destination est la plus générale (0.0.0.0/0). Cette route définit le chemin d'accès à Internet. Pour plus d'informations, consultez la section Routes.

• Les règles de pare-feu doivent autoriser le trafic de sortie de l'instance. Sauf en cas de substitution par une règle de priorité supérieure, la règle implicite d'autorisation pour le trafic de sortie autorise le trafic sortant de toutes les instances.

• L'une des conditions suivantes doit être remplie :

  • L'instance doit avoir une adresse IP externe. L'adresse IP externe peut être attribuée à une instance lors de sa création ou après sa création.

  • L'instance doit pouvoir utiliser Cloud NAT ou un proxy basé sur une instance, correspondant à la cible d'une route 0.0.0.0/0 statique.

Communications et accès pour App Engine

Les règles de pare-feu VPC s'appliquent aux ressources exécutées sur le réseau VPC, telles que les VM Compute Engine. Pour les instances App Engine, les règles de pare-feu fonctionnent comme suit :

• Environnement standard App Engine : seules les règles de pare-feu App Engine s'appliquent au trafic entrant. Les instances d'environnement standard App Engine ne s'exécutant pas dans votre réseau VPC, les règles de pare-feu VPC ne leur sont pas applicables.

• Environnement flexible App Engine : les règles de pare-feu App Engine et VPC s'appliquent au trafic entrant. Le trafic entrant n'est autorisé que si les deux types de règles de pare-feu l'autorisent. Pour le trafic sortant, les règles de pare-feu VPC s'appliquent.

Pour plus d'informations sur le contrôle de l'accès aux instances App Engine, consultez la section Sécurité des applications.

Traceroute vers des adresses IP externes

Pour des raisons internes, Google Cloud augmente le compteur TTL des paquets qui traversent les sauts suivants sur le réseau de Google. Des outils tels que traceroute et mtr peuvent fournir des résultats incomplets, car la valeur TTL n'expire pas sur certains sauts. Les sauts internes au réseau de Google peuvent être masqués lorsque vous envoyez des paquets depuis des instances Compute Engine vers des destinations sur Internet.

Le nombre de sauts masqués varie en fonction des niveaux de service réseau de l'instance, de la région et d'autres facteurs. Si les sauts sont peu nombreux, il est possible qu'ils soient tous masqués. Les sauts manquants dans un résultat traceroute ou mtr ne signifient pas que le trafic sortant est supprimé.

Il n'existe aucune solution pour contourner ce problème. Vous devez en tenir compte si vous configurez une surveillance tierce qui se connecte à une adresse IP externe associée à une VM.

Important : Les statistiques de perte de vérification constituent un composant des tests traceroute, mais les résultats des tests doivent être analysés avec précaution. traceroute et mtr utilisent par défaut la vérification basée sur ICMP. La génération de réponses aux vérifications ICMP est généralement limitée en débit (ou désactivée) dans les routeurs qui se trouvent sur le chemin réseau que l'on cherche à vérifier, et cela peut entraîner l'absence de réponses de vérification. Dans ce cas, vous pouvez constater une perte de vérification dans les sauts de routage intermédiaires, mais cela ne présume pas que les performances de bout en bout sont dégradées. Si vous vous intéressez à la perte de paquets, le saut avant la destination finale est en général le seul qui importe.

Limites de débit de sortie

Les informations de débit réseau sont disponibles sur la page Bande passante réseau de la documentation Compute Engine.

Taille des paquets

Vous trouverez des informations sur la taille des paquets dans la section Unité de transmission maximale.

Unité de transmission maximale

Pour en savoir plus sur le paramètre d'unité de transmission maximale (MTU) d'un réseau VPC et des VM qui y sont connectées, consultez la page Unité de transmission maximale.

Pour en savoir plus sur la modification de la MTU d'un réseau VPC ou sur la migration de VM entre des réseaux VPC avec des paramètres de MTU différents, consultez la page Modifier le paramètre de MTU d'un réseau VPC.

Protocoles compatibles

Google Cloud n'accepte que les protocoles et les en-têtes d'extension suivants :

• Paquets de données IPv4 entre les VM : tous les protocoles IPv4.
• Paquets de données IPv4 entre les VM et Internet : protocoles ICMP, IPIP, TCP, UDP, GRE, ESP, AH et SCTP.
• Paquets de données IPv6 entre les VM et entre les VM et Internet : protocoles AH, ESP, GRE, ICMP, ICMPv6, IPIP, SCTP, TCP et UDP, et les en-têtes d'extension "Options de destination" et "Fragments". Il n'est toutefois pas possible de placer l'en-tête "Options de destination" après l'en-tête "Fragment" dans un paquet de données IPv6.
• Transfert de protocole : protocoles AH, ESP, GRE, ICMP, ICMPv6, SCTP, TCP et UDP

Pour autoriser les paquets de données des protocoles pris en charge, vous devez configurer des règles de pare-feu ou des règles de transfert de protocole en fonction de vos besoins.

Performances du réseau

Latence

Les mesures de latence interrégionale pour les réseaux Google Cloud sont indiquées dans notre tableau de bord en direct. Le tableau de bord présente la méthodologie et les métriques de performances de débit et de latence interrégionale médianes de Google Cloud permettant de reproduire ces résultats à l'aide de PerfKit Benchmarker.

Google Cloud mesure généralement les latences aller-retour inférieures à 55 microsecondes au 50e centile et les latences de queue inférieures à 80 microsecondes au 99e centile entre les instances de VM c2-standard-4 de la même zone.

Google Cloud mesure généralement les latences aller-retour inférieures à 45 microsecondes au 50e centile et les latences de queue inférieures à 60 microsecondes au 99e centile entre les instances de VM c2-standard-4 du même réseau à faible latence (stratégie d'emplacement "compacte"). La stratégie d'emplacement compact permet de réduire la latence du réseau en garantissant que les VM se trouvent physiquement dans le même réseau à faible latence.

Méthodologie : la latence intrazone est surveillée via un vérificateur de boîte noire qui exécute en permanence un test TCP_RR netperf entre deux VM de type c2 dans chaque zone où ces instances sont disponibles. Le vérificateur collecte les résultats P50 et P99 qui serviront à la configuration avec et sans stratégie d'emplacement compact. Le test TCP_RR mesure les performances des requêtes/réponses en mesurant le taux de transaction. Si vos applications nécessitent une latence optimale, nous vous recommandons d'utiliser des instances c2.

Perte de paquets

Google Cloud effectue le suivi de la perte de paquets interrégionale en mesurant régulièrement la perte aller-retour entre toutes les régions. Nous visons une moyenne mondiale de ces mesures inférieure à 0,01 %.

Méthodologie : un vérificateur de boîte noire VM à VM surveille la perte de paquets pour chaque paire de zones à l'aide de pings et agrège les résultats dans une seule métrique de perte globale. Cette métrique est suivie sur une période d'un jour.

Étape suivante

• Créez, modifiez ou supprimez des réseaux et des sous-réseaux VPC.

Faites l'essai

Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de VPC en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Profiter d'un essai gratuit de VPC