Google PCA: Réseau, connectivité hybride et architecture du trafic — Guide d'étude

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Architect — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Vue d’ensemble

Le réseau, la connectivité hybride et l’architecture du trafic sur Google Cloud s’articulent autour d’une conception de Virtual Private Cloud (VPC) sécurisée et évolutive, d’interconnexions hybrides fiables, d’une gestion intelligente du trafic et d’une observabilité robuste. L’objectif est de fournir des services résilients à faible latence avec une segmentation claire, une sortie (egress) contrôlée et des modes de défaillance prévisibles. Cette section présente des modèles de conception pratiques, des compromis et des conseils opérationnels pour les principaux services de réseau Google Cloud.

Architecture et segmentation VPC

• Planification des adresses et sous-réseaux

  • Utilisez des VPC en mode personnalisé pour contrôler la création des sous-réseaux et l’adressage IP. Évitez les VPC par défaut en production.
  • Allouez tôt des blocs RFC1918 qui ne se chevauchent pas. Tenez compte de la croissance future, des topologies à haute disponibilité et des extensions hybrides. Réservez des plages pour les services (par exemple, les points de terminaison Private Service Connect) et pour le peering/Interconnect.
  • Préférez des sous-réseaux plus petits, par fonction ou par environnement, plutôt que de grands réseaux plats afin de minimiser le rayon d’impact des pannes (blast radius) et de simplifier la gestion des pare-feu.

• Routes

  • Chaque VPC possède une table de routage système ; les routes sont évaluées par la correspondance du préfixe le plus long, puis par la priorité. Les routes gérées par Google incluent la route Internet par défaut si des adresses IP externes existent, ainsi que les routes de sous-réseaux. Les routes dynamiques sont échangées avec les environnements sur site (on-premises) via Cloud Router.
  • Utilisez les routes statiques personnalisées avec parcimonie ; privilégiez le routage dynamique lorsque c’est possible pour la résilience. Évitez les routes de type “trou noir” (blackhole) sauf en tant que mesure de contrôle délibérée.

• Règles de pare-feu

  • Le pare-feu VPC est à état (stateful) et évalué par priorité, avec un refus implicite à la fin. Ciblez par tags réseau ou par comptes de service ; le ciblage par compte de service offre des garanties d’identité plus fortes que les tags.
  • Séparez les règles d’autorisation (allow) par objectif (vérifications de santé, intra-niveau, administration) et limitez leur portée aux comptes de service ou aux plages IP sources.
  • Journalisez les décisions de pare-feu pour les règles critiques dans Cloud Logging afin de faciliter les analyses forensiques et de performance.

• Règles de pare-feu hiérarchiques et règles d’organisation

  • Les règles de pare-feu hiérarchiques s’appliquent au niveau de l’organisation ou du dossier et sont évaluées avant les règles au niveau du VPC. Utilisez-les pour définir des garde-fous globaux (par exemple, refuser le SSH depuis 0.0.0.0/0) que les projets ne peuvent pas outrepasser. Les règles pré- et post-stratégie offrent de la flexibilité, mais les refus aux niveaux supérieurs ne peuvent pas être supplantés.
  • Complétez avec des contraintes de règles d’organisation (par exemple, restreindre la création d’adresses IP externes, interdire la création de VPC peering par les projets) pour renforcer la gouvernance.

• VPC partagé et segmentation

  • Utilisez le VPC partagé (Shared VPC) pour centraliser le réseau dans des projets hôtes (Host Projects) tout en isolant les charges de travail dans des projets de service (Service Projects). Ce modèle réduit la duplication des chemins de sortie, standardise les contrôles et simplifie le transit hybride.
  • Isolez les environnements (prod, non-prod) dans des projets hôtes ou des dossiers distincts ; appliquez la segmentation avec des règles hiérarchiques et des sous-réseaux séparés. Restreignez les permissions IAM pour que seules les équipes NetOps gèrent les ressources du projet hôte.

• VPC Network Peering

  • Le peering est privé, évolutif et à faible latence, mais non transitif. Il est idéal pour connecter des réseaux autonomes ou des services gérés par des tiers. Évitez de construire des hubs de transit avec le peering ; utilisez Network Connectivity Center pour le transit ou un VPC partagé centralisé.
  • Limitations : pas d’adresses IP qui se chevauchent ; certaines routes (par exemple, la route Internet par défaut) et certains services ne sont pas propagés. Comprenez l’importation/exportation des routes personnalisées lors de la conception.

Compromis et modes de défaillance :

• Le chevauchement des plages IP bloque le peering et l’échange de routes hybrides ; à résoudre par un nouveau plan d’adressage (renumbering) ou du NAT.
• Des règles de pare-feu excessivement permissives ou l’absence de règles pour les vérifications de santé provoquent des pannes et des comportements difficiles à diagnostiquer.
• Les routes statiques créent des dépendances fragiles ; préférez Cloud Router pour le basculement (failover).

Gestion du trafic, DNS et sécurité en périphérie

• Modèles de Cloud Load Balancing

  • L’External HTTP(S) Load Balancer est global anycast avec une VIP anycast unique, un basculement inter-régional, un routage par chemin et par hôte, et une intégration avec CDN/Armor. À utiliser pour les charges de travail web et API exposées sur Internet.
  • L’Internal HTTP(S) Load Balancer est régional, pour le trafic de service à service au sein d’un VPC ou via Private Service Connect.
  • L’External/Internal TCP/UDP Network Load Balancer est un équilibreur de charge régional de niveau 4 (L4) ; à utiliser pour les protocoles non-HTTP ou lorsque la préservation de l’adresse IP source est requise.
  • Services de backend et Network Endpoint Groups (NEGs) : utilisez des backends de groupes d’instances zonaux pour les pools de VM ; utilisez des NEGs zonaux, régionaux ou serverless pour GKE, les backends hybrides ou Cloud Run. Créez des services de backend distincts par classe de trafic, profil de santé ou politique de capacité. Exemple : servir d’anciennes et de nouvelles versions d’API sous le même nom d’hôte en utilisant le routage par chemin vers des services de backend distincts, ce qui permet de les déployer et de les mettre à l’échelle indépendamment.

• Vérifications de l’état (health checks) et pièges courants

  • Les vérifications de l’état doivent être autorisées par le pare-feu. Pour les vérifications de l’état HTTP(S) externes, autorisez les plages 130.211.0.0/22 et 35.191.0.0/16 vers les backends. Une règle manquante entraîne le marquage des backends comme défaillants (unhealthy) et des redémarrages rapides de VM si l’autoscaling réagit aux signaux de l’équilibreur de charge.
  • Alignez les chemins et les ports des vérifications de l’état avec les points de terminaison de préparation (readiness) des conteneurs ; définissez les délais d’attente (timeouts) et les seuils pour équilibrer un basculement rapide et la prévention des faux positifs.

• Architecture DNS

  • Utilisez Cloud DNS pour les zones faisant autorité. Créez des zones privées pour les noms internes ; créez des zones publiques pour les noms sur Internet.
  • DNS split-horizon : servez des réponses différentes en interne et en externe en créant des zones publiques et privées distinctes portant des noms identiques. Cela permet de gérer en toute sécurité les noms d’hôtes de services privés et les enregistrements publics.
  • Zones de transfert et d’appairage (peering) : intégrez avec un DNS sur site (on-premises) en utilisant des politiques DNS et des politiques de serveur pour transférer les requêtes pour des domaines spécifiques ; utilisez le transfert conditionnel pour éviter les boucles de récursion.
  • Découverte de services : adoptez des conventions de nommage cohérentes par environnement et par service. Pour GKE, envisagez des services headless avec Cloud DNS, ou mappez les points de terminaison de service via un Internal HTTP(S) Load Balancer et des noms DNS privés.

• Mise en cache et protection en périphérie

  • Cloud CDN décharge le contenu pouvant être mis en cache en périphérie, réduisant ainsi la latence de l’origine et les coûts de sortie (egress). Définissez soigneusement les clés de cache, les TTL et la mise en cache négative ; contournez la mise en cache pour les points de terminaison personnalisés ou dynamiques.
  • Cloud Armor fournit un WAF, une limitation de débit (rate limiting) et un contrôle d’accès basé sur la géolocalisation/IP. Attachez des politiques de sécurité aux équilibreurs de charge ; surveillez les journaux de déclenchement des règles. Utilisez des règles préconfigurées pour les CVE courantes et des signatures personnalisées pour les menaces spécifiques à l’application.
  • La terminaison TLS au niveau de l’équilibreur de charge centralise la gestion des certificats ; activez le provisionnement automatique des certificats et les renouvellements gérés lorsque cela est possible.

Recommandations opérationnelles :

• API versionnées : mettez en œuvre un routage basé sur le chemin ou l’hôte vers des services de backend distincts afin que chaque version puisse être déployée indépendamment avec des modèles blue-green ou canary.
• Utilisez les en-têtes de requête et les cookies pour les tests A/B via des politiques de répartition du trafic (traffic steering) ; validez toujours que la journalisation/les métriques correspondent à la bonne identité de backend.

Connectivité hybride, accès privé et transit

• Cloud Router et BGP

  • Cloud Router échange dynamiquement des routes avec l’environnement sur site via BGP pour les tunnels Cloud VPN et les rattachements Interconnect. Utilisez le mode de routage dynamique mondial dans le VPC lorsque la connectivité entre des branches (spokes) multi-régions est requise.
  • Annoncez uniquement les préfixes requis ; filtrez pour éviter les fuites de routes. Comprenez les interactions entre le MED et la priorité lors de la conception des chemins principaux/de secours.

• Cloud VPN, Dedicated Interconnect et Partner Interconnect

  • HA VPN fournit des tunnels redondants avec SLA sur IPsec, prend en charge le routage dynamique via Cloud Router et convient à un environnement de production hybride avec des besoins modérés en bande passante.
  • Dedicated Interconnect fournit des liaisons physiques de 10/100 Gbit/s dans un ou plusieurs emplacements ; Partner Interconnect offre une solution similaire via un fournisseur de services. Utilisez au moins deux interconnexions diverses dans des emplacements métropolitains distincts ou des zones périphériques distinctes pour une haute disponibilité.
  • Chemins redondants et basculement : concevez une architecture actif/actif avec BGP sur deux Cloud Routers par région et deux routeurs sur site ; validez la tolérance au routage asymétrique. Testez régulièrement le basculement ; ajustez les minuteurs BFD et les seuils de santé pour la convergence souhaitée.
  • Modes de défaillance : une non-concordance du MTU provoque une fragmentation et des pénalités de performance ; assurez-vous que les trames jumbo sont configurées de bout en bout pour Interconnect. Des filtres de route mal configurés peuvent créer un trou noir (blackhole) pour des sous-réseaux. Les circuits de partenaires à rattachement unique (single-homed) sont un point de défaillance unique courant.

• Cloud NAT, Private Google Access et Private Service Connect

  • Cloud NAT permet le trafic sortant (egress) vers Internet pour les VM privées sans adresses IP externes. Dimensionnez les adresses IP NAT et les allocations de ports pour les pics de connexions afin d’éviter l’épuisement des ports ; activez la journalisation pour le dépannage.
  • Private Google Access permet aux VM privées d’atteindre les API Google en utilisant des adresses IP internes ; activez-le sur les sous-réseaux pour l’accès des VM et sur les nœuds GKE pour l’accès aux API locales aux nœuds. Pour les clients sur site, utilisez Private Service Connect pour les API Google afin d’exposer des VIP privées qui servent de façade aux API Google.
  • Private Service Connect pour les services producteur/consommateur fournit des points de terminaison IP internes et privés pour la publication de services entre projets ou organisations ; combinez-le avec un DNS privé pour diriger le trafic sans exposer les réseaux.

• Network Connectivity Center (NCC) et transit

  • NCC permet des topologies en étoile (hub-and-spoke) où les branches (spokes) sont des VPC, des HA VPN ou des rattachements Interconnect. Utilisez un hub central pour simplifier la distribution des routes et le transit multi-VPC, en particulier entre projets ou organisations.
  • Préférez le VPC partagé (Shared VPC) pour le transit intra-organisation lorsque la gouvernance le permet ; utilisez NCC lorsque vous avez besoin d’un transit flexible multi-domaines ou d’une intégration SD-WAN.
  • Comprenez que l’appairage de VPC (VPC Peering) n’est pas transitif ; ne comptez pas sur lui pour le transit. NCC ou un VPC centralisé avec pare-feu/équilibreurs de charge constitue le cœur du transit.

Choix multi-régions, latence et coûts de sortie :

• Placez les ressources de calcul près des utilisateurs et des backends avec état (stateful) pour minimiser le RTT. L’External HTTP(S) Load Balancing fournit un point d’entrée (ingress) mondial avec un routage intelligent, mais la latence de réplication de la base de données et la cohérence restent des contraintes applicatives.
• Le trafic interzone entraîne des coûts au sein d’une région ; la réplication interrégionale ajoute des frais de sortie (egress) et de la latence. Utilisez Cloud CDN pour réduire le trafic de sortie Internet et la charge sur l’origine, et maintenez les services bavards (chatty) colocalisés.
• Pour la reprise après sinistre, évaluez le coût d’un déploiement en attente tiède (warm standby) dans une autre région par rapport à la complexité opérationnelle et aux frais de sortie. Utilisez l’équilibrage de charge mondial avec des politiques de basculement et des vérifications de santé (health checks) couvrant plusieurs régions uniquement lorsque le plan de données et le plan de contrôle peuvent tolérer un isolement régional.

Observabilité, opérations de fiabilité et contrôles

• Observabilité du réseau

  • VPC Flow Logs : activez-les au niveau du sous-réseau et ajustez les options d’échantillonnage et de métadonnées. Utilisez-les pour l’établissement de bases de référence du trafic, l’analyse de l’egress et la recherche de menaces. Exportez vers BigQuery pour une analyse à long terme.
  • Journalisation des règles de pare-feu : activez-la sur les règles critiques pour capturer le trafic autorisé et refusé ; corrélez-la avec les journaux de flux pour détecter les erreurs de configuration.
  • Connectivity Tests : modélisez les chemins source-destination pour valider l’accessibilité, la sélection des routes et l’évaluation du pare-feu. Intégrez dans la CI/CD pour détecter les dérives avant le déploiement.
  • Tableaux de bord de santé : surveillez la santé des backends de l’équilibreur de charge, l’utilisation des ports de Cloud NAT, l’état de la session BGP de Cloud Router et l’utilisation d’Interconnect. Alertez sur les écarts.

• Modèles de fiabilité et modes de défaillance courants

  • Résilience zonale : répartissez les backends sur au moins deux zones ; utilisez des groupes d’instances gérés ou des pools de nœuds GKE multizonaux. Validez que les vérifications de santé et les tags de pare-feu s’appliquent à toutes les zones.
  • Résilience du routage : utilisez le routage dynamique mondial et plusieurs Cloud Routers pour une connectivité couvrant plusieurs régions. Testez les scénarios de trou noir (blackhole) et assurez-vous que la surveillance couvre les retraits de routes.
  • Résilience DNS : déployez plusieurs serveurs de noms par défaut avec Cloud DNS ; pour l’hybride, assurez-vous que les redirecteurs sont redondants et évitez les points de défaillance uniques dans les résolveurs sur site (on-prem). Empêchez les erreurs de configuration en split-horizon qui renvoient des réponses non routables du mauvais côté.
  • Sécurité en périphérie (edge) : appliquez les limites de débit de Cloud Armor pour protéger l’origine des inondations de trafic (floods) ; ne pas le faire peut déclencher des tempêtes d’autoscaling et des pics de coûts.

• Contrôles des coûts

  • Minimisez les appels inter-régionaux, préférez l’équilibrage de charge interne pour le trafic intra-VPC et envisagez PSC pour le trafic producteur-consommateur afin d’éviter l’egress NAT.
  • Utilisez Cloud CDN pour les ressources statiques et semi-statiques ; ajustez la capacité de mise en cache. Dimensionnez la capacité d’Interconnect pour éviter de surpayer pour une marge de manœuvre inutilisée ; utilisez les données de trafic pour ajuster les engagements.

Extraits opérationnels :

• Autoriser les vérifications de santé de l’équilibreur de charge vers les backends privés :

undefined

• Activer Private Google Access sur un sous-réseau :

undefined

• Créer un Cloud Router pour un VPN haute disponibilité (HA VPN) :

undefined

Scénario de problème pratique

Contoso Retail prévoit de lancer une API e-commerce mondiale avec un versioning sans interruption de service, une connectivité privée stricte aux systèmes de back-office et aucune adresse IP publique sur les VM d’application. La solution doit fournir une protection DDoS, une mise en cache en périphérie et un accès hybride fiable depuis deux centres de données.

Approche :

1. Concevoir le VPC et la segmentation

• Créez un projet hôte Shared VPC en mode personnalisé avec des sous-réseaux dédiés par niveau (web, api, data) dans deux régions. Justification : Le Shared VPC centralise les contrôles tandis que les projets de service isolent les équipes. Les sous-réseaux par niveau permettent un pare-feu au moindre privilège et des domaines de défaillance plus petits.
• Appliquez des règles de pare-feu hiérarchiques au niveau de l’organisation pour refuser le SSH entrant depuis Internet et restreindre l’egress aux destinations autorisées. Justification : Les garde-fous globaux réduisent le risque d’erreur de configuration dans les projets.

2. Mettre en œuvre l’ingress mondial basé sur le chemin et le versioning d’API

• Déployez un External HTTP(S) Load Balancer avec une seule adresse IP anycast et une terminaison HTTPS. Configurez des mappages d’URL pour router /v1/* et /v2/* vers des services de backend distincts soutenus par des NEG zonaux régionaux. Justification : Des services de backend distincts permettent un déploiement et une restauration indépendants pour chaque version de l’API sous un seul nom d’hôte et TLS.
• Attachez un WAF Cloud Armor et des limites de débit ; activez Cloud CDN pour les points de terminaison pouvant être mis en cache (par exemple, les images de produits). Justification : Protège l’origine et réduit la latence et les coûts d’egress.

3. Assurer l’accessibilité et la santé des backends

• Créez une règle de pare-feu pour autoriser les vérifications de santé de l’équilibreur de charge vers les groupes d’instances de l’API sur les ports attendus. Justification : Sans cela, les vérifications de santé échouent et les autoscalers peuvent s’emballer (thrash) car les instances sont considérées comme non saines.
• Répartissez les instances sur deux zones par région ; définissez les seuils de vérification de santé de manière conservatrice pour éviter les oscillations (flapping). Justification : La diversité zonale et des politiques de santé stables améliorent la disponibilité.

4. Construire le DNS avec split-horizon et la découverte de services

• Créez une zone Cloud DNS publique pour contoso.com et une zone privée du même nom pour les enregistrements internes uniquement (par exemple, db.internal.contoso.com). Justification : Le split-horizon empêche la fuite des noms internes tout en conservant une dénomination cohérente.
• Configurez les politiques DNS pour transférer les requêtes sur site (on-premises) pour corp.local vers le DNS d’entreprise et importer les zones privées dans les projets d’application. Justification : Résolution transparente à travers les frontières hybrides sans boucles de récursion.

5. Établir une connectivité hybride avec redondance

• Dans chaque région, provisionnez deux tunnels HA VPN vers chaque centre de données, chaque paire sur des Cloud Routers distincts avec BGP. Si la capacité et les besoins en SLA le justifient, ajoutez Partner Interconnect avec des rattachements redondants dans des zones de périphérie distinctes. Justification : Plusieurs chemins diversifiés assurent le basculement ; BGP permet une convergence rapide et un échange de routes dynamique.
• Utilisez le routage dynamique mondial dans le Shared VPC et appliquez des filtres de route pour empêcher la propagation de préfixes sur site non désirés. Justification : Routage cohérent entre les régions tout en réduisant le risque de fuites de routes.

6. Fournir un accès privé aux API Google et à l’Internet sortant

• Activez Private Google Access sur les sous-réseaux des applications et configurez des points de terminaison Private Service Connect pour les API Google utilisées par les tâches batch. Utilisez Cloud NAT pour l’egress sortant non-API si nécessaire. Justification : Les backends ne conservent aucune adresse IP publique tout en atteignant les services nécessaires ; PSC simplifie la résolution de noms avec le DNS privé.

7. Centraliser le transit et la connectivité tierce

• Créez un hub Network Connectivity Center dans le projet hôte ; attachez les HA VPNs, les rattachements Interconnect et tout spoke SD-WAN. Justification : Le transit en étoile (hub-and-spoke) simplifie la distribution des routes entre plusieurs VPC et réseaux externes par rapport aux maillages de peering.

8. Mettre en œuvre l’observabilité et les garde-fous

• Activez les VPC Flow Logs sur tous les sous-réseaux avec un échantillonnage approprié ; activez les journaux de pare-feu sur les règles critiques ; exportez vers BigQuery. Utilisez Connectivity Tests dans la CI/CD avant de promouvoir de nouvelles modifications de pare-feu ou de routage. Justification : Une visibilité approfondie facilite le dépannage, la planification de la capacité et l’auditabilité.
• Définissez des alertes pour les interruptions de session BGP de Cloud Router, l’épuisement des ports de Cloud NAT, les baisses de santé des backends et les déclenchements de règles Cloud Armor. Justification : La détection précoce des défaillances et des attaques réduit le MTTR.

9. Optimiser pour la performance et le coût

• Colocalisez les services avec état (stateful) avec le calcul dans la même région ; mettez en cache le contenu statique en périphérie avec Cloud CDN. Justification : Minimise le RTT et l’egress inter-régional.
• Examinez périodiquement les journaux de flux pour identifier le bavardage inter-zone et ajuster le placement ou les frontières des services. Justification : Réduit l’egress et la latence inutiles.

Cette conception fournit un ingress mondial et sécurisé avec un routage versionné, une connectivité hybride résiliente avec basculement dynamique, un accès privé aux services requis et une observabilité complète, tout en contrôlant la latence et les coûts d’egress.

← Stockage des données · Tous les domaines · Sécurité →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Google →