Google PCA: Netwerken, Hybride connectiviteit en Verkeersarchitectuur — Studiegids

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

Onderdeel van de Google Professional Cloud Architect — Studiegids. Oefen met geverifieerde antwoorden in het Google-examencentrum, of doe getimede oefentests op ExamRoll.io.

Overzicht

Netwerken, hybride connectiviteit en verkeersarchitectuur op Google Cloud draaien om een veilig, schaalbaar Virtual Private Cloud (VPC)-ontwerp; betrouwbare hybride interconnects; intelligent verkeersbeheer; en robuuste observeerbaarheid. Het doel is om veerkrachtige services met lage latentie te leveren, met duidelijke segmentatie, gecontroleerde egress en voorspelbare faalmodi. Dit gedeelte beschrijft praktische ontwerppatronen, afwegingen en operationele richtlijnen voor de belangrijkste netwerkservices van Google Cloud.

VPC-architectuur en -segmentatie

• Adresplanning en subnets

  • Gebruik custom-mode VPC’s om de aanmaak van subnets en IP-adressering te beheren. Vermijd standaard VPC’s in productie.
  • Wijs in een vroeg stadium niet-overlappende RFC1918-blokken toe. Houd rekening met toekomstige groei, high-availability topologieën en hybride uitbreidingen. Reserveer bereiken voor services (bijvoorbeeld Private Service Connect-endpoints) en voor peering/Interconnect.
  • Geef de voorkeur aan kleinere subnets per functie of per omgeving boven grote, platte netwerken om de ‘blast radius’ bij storingen te minimaliseren en firewalling te vereenvoudigen.

• Routes

  • Elke VPC heeft een systeemroutetabel; routes worden geëvalueerd op basis van ’longest-prefix match’ en vervolgens op prioriteit. Door Google beheerde routes omvatten de standaard internetroute als er externe IP’s bestaan, en subnetroutes. Dynamische routes worden uitgewisseld met on-premises via Cloud Router.
  • Gebruik aangepaste statische routes spaarzaam; vertrouw waar mogelijk op dynamische routering voor veerkracht. Vermijd blackhole-routes, behalve als een bewuste controlemaatregel.

• Firewallregels

  • De VPC-firewall is stateful en wordt geëvalueerd op basis van prioriteit, met een impliciete ‘deny’ aan het einde. Richt je op netwerktags of serviceaccounts; targeting op serviceaccounts biedt sterkere identiteitsgaranties dan tags.
  • Scheid ‘allow’-regels per doel (health checks, intra-tier, beheer) en beperk hun scope tot bron-serviceaccounts of IP-bereiken.
  • Log firewallbeslissingen voor kritieke regels naar Cloud Logging om forensisch onderzoek en prestatieanalyse te ondersteunen.

• Hiërarchische firewall-policies en organisatie-policies

  • Hiërarchische firewall-policies worden toegepast op organisatie- of folderniveau en worden geëvalueerd vóór regels op VPC-niveau. Gebruik ze om globale ‘guardrails’ in te stellen (bijvoorbeeld, weiger 0.0.0.0/0 SSH) die projecten niet kunnen overschrijven. Pre- en post-policies bieden flexibiliteit, maar ‘denies’ op hogere niveaus kunnen niet worden vervangen.
  • Vul aan met Organization Policy-constraints (bijvoorbeeld, beperk het aanmaken van externe IP’s, sta het aanmaken van VPC-peering door projecten niet toe) om governance af te dwingen.

• Shared VPC en segmentatie

  • Gebruik Shared VPC om netwerken te centraliseren in Host Projects, terwijl workloads worden geïsoleerd in Service Projects. Dit patroon vermindert dubbele egress-paden, standaardiseert controles en vereenvoudigt hybride transit.
  • Isoleer omgevingen (prod, non-prod) in afzonderlijke Host Projects of folders; dwing segmentatie af met hiërarchische policies en aparte subnets. Beperk IAM zodat alleen NetOps-teams de resources van het Host Project beheren.

• VPC Network Peering

  • Peering is privé, schaalbaar en heeft een lage latentie, maar is niet-transitief. Het is het meest geschikt voor het verbinden van autonome netwerken of door derden beheerde services. Vermijd het bouwen van transit hubs met peering; gebruik Network Connectivity Center voor transit of een gecentraliseerde Shared VPC.
  • Beperkingen: geen overlappende IP’s; bepaalde routes (bijvoorbeeld de standaard internetroute) en sommige services worden niet gepropageerd. Begrijp de import/export van aangepaste routes bij het ontwerpen.

Afwegingen en faalmodi:

• Overlappende IP-bereiken blokkeren peering en de uitwisseling van hybride routes; los dit op met hernummering of NAT.
• Te permissieve firewallregels of ontbrekende health check-regels veroorzaken storingen en moeilijk te diagnosticeren gedrag.
• Statische routes creëren breekbare afhankelijkheden; geef de voorkeur aan Cloud Router voor failover.

Trafficbeheer, DNS en Edge-beveiliging

• Patronen voor Cloud Load Balancing

  • External HTTP(S) Load Balancer is wereldwijd anycast met een enkele anycast VIP, cross-region failover, pad- en host-gebaseerde routing, en CDN/Armor-integratie. Gebruik voor internetgerichte web- en API-workloads.
  • Internal HTTP(S) Load Balancer is regionaal, voor service-naar-service verkeer binnen een VPC of via Private Service Connect.
  • External/Internal TCP/UDP Network Load Balancer is een regionale L4; gebruik voor niet-HTTP-protocollen of waar het behoud van het bron-IP-adres vereist is.
  • Backend services en Network Endpoint Groups (NEGs): gebruik zonale instance group backends voor VM-pools; gebruik zonale, regionale of serverless NEGs voor GKE, hybride backends of Cloud Run. Maak afzonderlijke backend services per verkeersklasse, health-profiel of capaciteitsbeleid. Voorbeeld: serveer oude en nieuwe API-versies onder dezelfde hostnaam door pad-gebaseerde routing naar afzonderlijke backend services, zodat beide onafhankelijk van elkaar kunnen worden geïmplementeerd en geschaald.

• Health checks en veelvoorkomende valkuilen

  • Health checks moeten worden toegestaan door de firewall. Voor externe HTTP(S) health checks, sta 130.211.0.0/22 en 35.191.0.0/16 toe naar de backends. Een ontbrekende regel resulteert in backends die als ‘unhealthy’ worden gemarkeerd en snelle herstarts van VM’s als autoscaling reageert op signalen van de load balancer.
  • Lijn de paden en poorten van health checks uit met de readiness-eindpunten van containers; stel time-outs en drempelwaarden in om een balans te vinden tussen snelle failover en fout-positieven.

• DNS-architectuur

  • Gebruik Cloud DNS voor authoritative zones. Maak private zones voor interne namen; maak public zones voor internetnamen.
  • Split-horizon DNS: serveer verschillende antwoorden intern versus extern door afzonderlijke public en private zones met identieke namen aan te maken. Dit ondersteunt op een veilige manier private service-hostnamen en publiek toegankelijke records.
  • Forwarding en peering zones: integreer met on-premises DNS met behulp van DNS-beleid en serverbeleid om query’s voor specifieke domeinen door te sturen; gebruik conditional forwarding om recursielussen te vermijden.
  • Service discovery: hanteer consistente naamgevingsconventies per omgeving en service. Overweeg voor GKE headless services met Cloud DNS, of map service-eindpunten via een Internal HTTP(S) Load Balancer en private DNS-namen.

• Edge-caching en -beveiliging

  • Cloud CDN verplaatst cachebare content naar de edge, wat de latency naar de origin en de egress-kosten verlaagt. Stel cache keys, TTL’s en negative caching zorgvuldig in; omzeil caching voor gepersonaliseerde of dynamische eindpunten.
  • Cloud Armor biedt WAF, rate limiting en op geo/IP gebaseerde toegangscontrole. Koppel beveiligingsbeleid aan load balancers; monitor de logs van regel-hits. Gebruik voorgeconfigureerde regels voor veelvoorkomende CVE’s en aangepaste handtekeningen voor applicatiespecifieke bedreigingen.
  • TLS-terminatie op de load balancer centraliseert het certificaatbeheer; schakel waar mogelijk automatische certificaatprovisioning en beheerde verlengingen in.

Operationele richtlijnen:

• API’s met versiebeheer: implementeer pad- of host-gebaseerde routing naar afzonderlijke backend services, zodat elke versie onafhankelijk kan worden uitgerold met blue-green- of canary-patronen.
• Gebruik request headers en cookies voor A/B-testen via traffic steering-beleid; valideer altijd dat logging/metrics correleren met de juiste backend-identiteit.

Hybride connectiviteit, private toegang en transit

• Cloud Router en BGP

  • Cloud Router wisselt dynamisch routes uit met on-premises via BGP voor Cloud VPN-tunnels en Interconnect-attachments. Gebruik de global dynamic routing-modus in de VPC wanneer multi-region spoke-connectiviteit vereist is.
  • Adverteer alleen de benodigde prefixes; filter om route leaks te voorkomen. Begrijp de interacties tussen MED en prioriteit bij het ontwerpen van primaire/back-up paden.

• Cloud VPN, Dedicated en Partner Interconnect

  • HA VPN biedt redundante tunnels met SLA-ondersteuning via IPsec, ondersteunt dynamische routering via Cloud Router en is geschikt voor productie-hybride omgevingen met een gematigde bandbreedtebehoefte.
  • Dedicated Interconnect levert fysieke 10/100 Gbps-links op één of meerdere locaties; Partner Interconnect biedt iets vergelijkbaars via een serviceprovider. Gebruik voor hoge beschikbaarheid minstens twee diverse interconnects op afzonderlijke metrolocaties of in aparte edge zones.
  • Redundante paden en failover: ontwerp een active/active-configuratie met BGP over twee Cloud Routers per regio en twee on-prem routers; valideer de tolerantie voor asymmetrische routering. Test failover regelmatig; stem BFD-timers en health-drempels af voor de gewenste convergentie.
  • Foutscenario’s: een MTU-mismatch veroorzaakt fragmentatie en prestatieverlies; zorg voor end-to-end jumbo frames voor Interconnect. Verkeerd geconfigureerde routefilters kunnen subnets blackholen. Single-homed partnercircuits zijn een veelvoorkomend single point of failure.

• Cloud NAT, Private Google Access en Private Service Connect

  • Cloud NAT maakt egress naar het internet mogelijk voor private VM’s zonder externe IP-adressen. Dimensionneer NAT IP’s en poorttoewijzingen voor piekverbindingen om poortuitputting te voorkomen; schakel logging in voor troubleshooting.
  • Private Google Access stelt private VM’s in staat om Google API’s te bereiken via interne IP-adressen; schakel dit in op subnets voor VM-toegang en op GKE-nodes voor node-local API-toegang. Gebruik voor on-prem clients Private Service Connect for Google APIs om private VIP’s beschikbaar te stellen die als frontend voor Google API’s fungeren.
  • Private Service Connect voor producer/consumer-services biedt private, interne IP-eindpunten voor het publiceren van services over projecten of organisaties heen; combineer dit met private DNS om verkeer te sturen zonder netwerken bloot te stellen.

• Network Connectivity Center (NCC) en transit

  • NCC maakt hub-and-spoke-topologieën mogelijk waarbij de spokes VPC’s, HA VPN’s of Interconnect-attachments zijn. Gebruik een centrale hub om routedistributie en multi-VPC transit te vereenvoudigen, vooral over projecten of organisaties heen.
  • Geef de voorkeur aan Shared VPC voor transit binnen de organisatie als de governance dit toelaat; gebruik NCC wanneer je flexibele, multi-domain transit of SD-WAN-integratie nodig hebt.
  • Begrijp dat VPC Peering niet-transitief is; vertrouw hier niet op voor transit. NCC of een gecentraliseerde firewall/load balancer VPC vormt de transit-kern.

Multi-region keuzes, latency en egress-kosten:

• Plaats compute dicht bij gebruikers en stateful backends om de RTT te minimaliseren. External HTTP(S) Load Balancing biedt globale ingress met slimme routering, maar de latency en consistentie van databasereplicatie blijven beperkingen van de applicatie.
• Verkeer tussen zones binnen een regio brengt kosten met zich mee; replicatie tussen regio’s voegt egress-kosten en latency toe. Gebruik Cloud CDN om internet-egress en de belasting op de origin te verminderen, en houd ‘spraakzame’ services bij elkaar.
• Weeg voor disaster recovery een warm standby in een andere regio af tegen de egress-kosten en operationele complexiteit. Gebruik global load balancing met failover-beleid en health checks die meerdere regio’s omspannen alleen wanneer het data plane en control plane regionale isolatie kunnen tolereren.

Observeerbaarheid, Betrouwbaarheidsoperaties en Controles

• Netwerkobserveerbaarheid

  • VPC Flow Logs: schakel in op subnetniveau en stem de sampling- en metadata-opties af. Gebruik voor het vaststellen van een traffic-baseline, egress-analyse en threat hunting. Exporteer naar BigQuery voor lange-termijn analyses.
  • Logging van firewallregels: schakel in op kritieke regels om toegestaan en geweigerd verkeer vast te leggen; correleer met flow logs om misconfiguraties te detecteren.
  • Connectivity Tests: modelleer bron-bestemmingspaden om bereikbaarheid, routekeuze en firewall-evaluatie te valideren. Integreer in CI/CD om afwijkingen (drift) te detecteren vóór de implementatie.
  • Health-dashboards: monitor de status van load balancer-backends, het poortgebruik van Cloud NAT, de BGP-sessiestatus van Cloud Router en het gebruik van Interconnect. Genereer alerts bij afwijkingen.

• Betrouwbaarheidspatronen en veelvoorkomende faalscenario’s

  • Zonale veerkracht: verdeel backends over ten minste twee zones; gebruik managed instance groups of multi-zonale GKE node pools. Valideer dat health checks en firewall-tags van toepassing zijn op alle zones.
  • Routingveerkracht: gebruik global dynamic routing en meerdere Cloud Routers voor connectiviteit die regio’s overspant. Test blackhole-scenario’s en zorg ervoor dat monitoring het intrekken van routes dekt.
  • DNS-veerkracht: implementeer standaard meerdere nameservers met Cloud DNS; zorg er voor hybride omgevingen voor dat forwarders redundant zijn en vermijd single points of failure in on-prem resolvers. Voorkom split-horizon misconfiguraties die niet-routeerbare antwoorden vanaf de verkeerde kant retourneren.
  • Beveiliging aan de edge: pas Cloud Armor rate limits toe om de origin te beschermen tegen overbelasting (floods); als dit niet gebeurt, kan dit autoscaling-stormen en kostenpieken veroorzaken.

• Kostenbeheersing

  • Minimaliseer cross-region aanroepen, geef de voorkeur aan internal load balancing voor intra-VPC-verkeer en overweeg PSC voor producer-consumer-verkeer om NAT egress te vermijden.
  • Gebruik Cloud CDN voor statische en semi-statische assets; stem de cachebaarheid af. Bepaal de omvang van de Interconnect-capaciteit om te voorkomen dat u te veel betaalt voor ongebruikte headroom; gebruik verkeersdata om de omvang van de ‘commits’ correct te bepalen (right-sizing).

Operationele snippets:

• Sta health checks van de load balancer naar private backends toe:

undefined

• Schakel Private Google Access in op een subnet:

undefined

• Maak een Cloud Router voor HA VPN:

undefined

Praktisch Probleemscenario

Contoso Retail is van plan een wereldwijde e-commerce API te lanceren met zero-downtime versioning, strikt private connectiviteit met back-office systemen en geen publieke IP-adressen op de applicatie-VM’s. De oplossing moet DDoS-bescherming, edge caching en betrouwbare hybride toegang vanuit twee datacenters bieden.

Aanpak:

1. Ontwerp de VPC en segmentatie

• Maak een custom-mode Shared VPC Host Project met toegewezen subnets per tier (web, api, data) verspreid over twee regio’s. Rationale: Shared VPC centraliseert het beheer, terwijl service projects teams isoleren. Subnets per tier maken least-privilege firewalling en kleinere ‘failure domains’ mogelijk.
• Pas hiërarchische firewall policies toe op organisatieniveau om inkomende SSH vanaf het internet te weigeren en egress te beperken tot toegestane bestemmingen. Rationale: Globale ‘guardrails’ verminderen het risico op misconfiguratie in projecten.

2. Implementeer pad-gebaseerde globale ingress en API-versioning

• Implementeer een external HTTP(S) Load Balancer met één anycast IP en HTTPS-terminatie. Configureer URL maps om /v1/* en /v2/* te routeren naar afzonderlijke backend services die worden ondersteund door regionale, zonale NEG’s. Rationale: Aparte backend services maken onafhankelijke implementatie en rollback mogelijk voor elke API-versie onder één hostnaam en TLS-certificaat.
• Koppel Cloud Armor WAF en rate limits; schakel Cloud CDN in voor cachebare endpoints (bijvoorbeeld productafbeeldingen). Rationale: Beschermt de origin en verlaagt de latency en egress-kosten.

3. Zorg voor bereikbaarheid en status van de backend

• Maak een firewallregel om health checks van de load balancer naar de api instance groups op de verwachte poorten toe te staan. Rationale: Zonder dit mislukken de health checks en kunnen autoscalers onstabiel worden (’thrashing’) omdat instances als ongezond worden beschouwd.
• Verdeel instances over twee zones per regio; stel de drempelwaarden voor health checks conservatief in om ‘flapping’ te voorkomen. Rationale: Zonale diversiteit en stabiele health policies verbeteren de beschikbaarheid.

4. Bouw DNS met split-horizon en service discovery

• Maak een publieke Cloud DNS-zone voor contoso.com en een private zone met dezelfde naam voor uitsluitend interne records (bijvoorbeeld db.internal.contoso.com). Rationale: Split-horizon voorkomt dat interne namen naar buiten lekken, terwijl een consistente naamgeving behouden blijft.
• Configureer DNS policies om on-premises corp.local-queries door te sturen naar de enterprise DNS en importeer private zones in applicatieprojecten. Rationale: Naadloze naamresolutie over hybride grenzen heen zonder recursielussen.

5. Breng hybride connectiviteit met redundantie tot stand

• Provisioneer in elke regio twee HA VPN-tunnels naar elk datacenter, waarbij elk paar op afzonderlijke Cloud Routers met BGP draait. Als de capaciteits- en SLA-behoeften dit rechtvaardigen, voeg dan Partner Interconnect toe met redundante attachments in afzonderlijke edge zones. Rationale: Meerdere diverse paden bieden failover; BGP maakt snelle convergentie en dynamische route-uitwisseling mogelijk.
• Gebruik global dynamic routing in de Shared VPC en pas routefilters toe om te voorkomen dat ongewenste on-premises prefixes zich verspreiden. Rationale: Consistente routing over regio’s heen, terwijl het risico op ‘route leaks’ wordt verminderd.

6. Bied private toegang tot Google API’s en uitgaand internet

• Schakel Private Google Access in op app-subnets en configureer Private Service Connect-endpoints voor Google API’s die door batch-jobs worden gebruikt. Gebruik Cloud NAT voor niet-API uitgaande egress waar nodig. Rationale: Backends behouden geen publieke IP’s, maar kunnen toch de benodigde services bereiken; PSC vereenvoudigt naamresolutie met private DNS.

7. Centraliseer transit en connectiviteit met derden

• Maak een Network Connectivity Center-hub in het Host Project; koppel HA VPN’s, Interconnect attachments en eventuele SD-WAN spokes. Rationale: Hub-and-spoke transit vereenvoudigt de route-distributie tussen meerdere VPC’s en externe netwerken in vergelijking met peering meshes.

8. Implementeer observeerbaarheid en ‘guardrails’

• Schakel VPC Flow Logs in op alle subnets met de juiste sampling; schakel firewall-logs in op kritieke regels; exporteer naar BigQuery. Gebruik Connectivity Tests in CI/CD voordat nieuwe firewall- of routewijzigingen worden doorgevoerd. Rationale: Diepgaand inzicht ondersteunt troubleshooting, capaciteitsplanning en auditeerbaarheid.
• Stel alerts in voor BGP-sessiedrops van Cloud Router, uitputting van Cloud NAT-poorten, dalingen in de backend-status en ‘hits’ op Cloud Armor-regels. Rationale: Vroege detectie van storingen en aanvallen vermindert de MTTR (Mean Time To Repair).

9. Optimaliseer voor prestaties en kosten

• Plaats stateful services samen met compute in dezelfde regio; cache statische content aan de edge met Cloud CDN. Rationale: Minimaliseert RTT en cross-region egress.
• Controleer periodiek de flow logs om cross-zone ‘chatter’ te identificeren en pas de plaatsing of servicegrenzen aan. Rationale: Vermindert onnodige egress en latency.

Dit ontwerp levert globale, veilige ingress met geversioneerde routing, veerkrachtige hybride connectiviteit met dynamische failover, private toegang tot de benodigde services en uitgebreide observeerbaarheid, terwijl de latency en egress-kosten onder controle worden gehouden.

← Dataopslag · Alle domeinen · Beveiliging →

Oefen deze vragen → · Getimede oefening op ExamRoll.io →

Blader door Google →