Google PCNE: VPC Architectuur, Subnetten en Adresplanning — Studiegids

By Laurynas Brazys · 22 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

Overzicht

Een Virtual Private Cloud (VPC) is een wereldwijd, logisch geïsoleerd netwerk dat alle Google Cloud-regio’s omspant. Subnetten zijn regionale constructies binnen een VPC en bevatten IP-reeksen die worden gebruikt door Compute Engine, GKE en andere resources. Een degelijke VPC-architectuur balanceert adresefficiëntie, groei en operationele controle, en zorgt tegelijkertijd voor kosteneffectieve connectiviteit met lage latentie voor workloads binnen en tussen projecten en naar Google API’s.

VPC-scope, subnetarchitectuur en modi

Wereldwijde VPC, regionale subnetten
- Eén enkele VPC omspant alle regio’s. Subnetten worden per regio aangemaakt en definiëren primaire IPv4 CIDR’s en optionele secundaire reeksen. Instances ontvangen IP’s van regionale subnetten, maar kunnen standaard privé communiceren tussen regio’s binnen dezelfde VPC.
- Dynamische routeringsmodus
  - Regional: Cloud Routers wisselen alleen routes uit met subnetten in hun eigen regio.
  - Global: Cloud Routers in één regio adverteren geleerde routes naar alle regio’s. Geef de voorkeur aan global wanneer multi-regionale workloads of HA egress vereist zijn.
Auto mode vs custom mode
- Auto mode maakt één subnet per regio aan met vooraf toegewezen CIDR’s. Dit is handig om snel te starten, maar inflexibel op grote schaal. Het kan worden omgezet naar custom mode; de conversie is eenrichtingsverkeer.
- Custom mode biedt volledige controle over het aanmaken van subnetten en de keuze van CIDR’s. Dit is het aanbevolen patroon voor adresplanning in productie, Shared VPC, peering en groei.
- Migratie-opmerking: Na de conversie van auto naar custom, zullen artefacten of templates die uitgingen van auto-subnetten vaak falen totdat ze expliciet zijn bijgewerkt om naar de custom subnetten te verwijzen.
Onveranderlijkheid en groei van subnetten
- De regio van een subnet is onveranderlijk; je kunt een subnet niet tussen regio’s verplaatsen.
- Primaire IPv4-reeksen kunnen ter plekke worden uitgebreid (prefix verbreden), kunnen niet worden verkleind en moeten niet-overlappend blijven binnen de VPC en alle verbonden netwerken.
- Secundaire reeksen kunnen worden toegevoegd of verwijderd (afhankelijk van het gebruik), maar moeten ook niet-overlappend zijn.

Adresplanning: primaire/secundaire reeksen, alias IP’s, IPv6 en privé-adresruimte

Primaire en secundaire IPv4-reeksen
- Primaire reeks: wijst VM-interfaceadressen toe (standaard nic0). Het creëert een door het systeem gegenereerde subnetroute en wordt gebruikt voor de meeste interne communicatie.
- Secundaire reeksen: koppelen extra CIDR’s aan het subnet en zijn vereist voor VPC-native GKE-clusters. Door het systeem gegenereerde routes voor secundaire reeksen maken oost-west connectiviteit mogelijk voor Pods en Services.
Alias IP’s
- Alias IP’s stellen een VM NIC in staat om meerdere IP’s uit de primaire of secundaire reeksen van het subnet te bezitten, wat een strak, op IP gebaseerd beleid, Pod IP’s voor VPC-native GKE en efficiënt IP-gebruik mogelijk maakt.
- Plan voor GKE grote, aaneengesloten secundaire CIDR’s om fragmentatie en toekomstige formaatwijzigingen te minimaliseren. Voorbeeld: voor 100 nodes met 200 Pods/node en 1500 Services, wijs een secundaire Pod-reeks van ten minste /17 en een Services-reeks van /21 toe om groeiruimte te laten.
Privé RFC 1918-ontwerp en IP-beheer
- Kies niet-overlappende blokken voor alle huidige en geplande VPC’s, on-premises netwerken en partners. Reserveer grote ‘parent’-blokken voor elke omgeving en deel deze vervolgens op in voorspelbare sub-blokken per regio en per functie.
- Reserveer capaciteit voor groei, secundaire reeksen, migratiebuffers (tijdelijke dual-stack/double NAT) en infrastructuur-eindpunten (ILB VIP’s, PSC-eindpunten).
- Vermijd de meest gangbare bedrijfsblokken als connectiviteit met partners waarschijnlijk is; of segmenteer met NAT om conflicten op te lossen.
IPv6-planning
- Extern IPv6: gebruik wereldwijde externe IPv6-adressen op global load balancers voor clienttoegang en anycast-bereikbaarheid.
- Intern IPv6: waar beschikbaar, schakel dual-stack subnetten in om interne IPv6-adressen aan VM’s toe te wijzen en pas de firewallregels dienovereenkomstig aan. Plan DNS AAAA-records en zorg voor pariteit met het IPv4-beleid.
- Behoud IPv4 voor interne cloudcontroles en integraties met derden; introduceer IPv6 stapsgewijs via load balancers en dual-stack subnetten.

Routing: impliciete routes, aangepaste routes, prioriteiten, tags en next hops

Impliciete (door het systeem gegenereerde) routes
- Subnetroutes: één per primair subnet en per secundair bereik, bestemming is gelijk aan de CIDR, next hop is het subnet zelf.
- Standaardroute: 0.0.0.0/0 naar de standaard internetgateway wordt standaard aangemaakt; egress naar het internet vereist een extern IP-adres of NAT.
Aangepaste routes en selectielogica
- Langste prefix-match wint. Als meerdere routes dezelfde prefixlengte hebben, wint het laagste prioriteitsnummer (standaardprioriteit 1000).
- Tags en serviceaccounts
  - Routes zonder tags zijn van toepassing op alle VM’s. Routes die op tags zijn gericht (tag-scoped) zijn alleen van toepassing op instances met overeenkomende netwerktags.
  - Op identiteit gebaseerde firewallregels kunnen matchen met serviceaccounts; gebruik deze waar mogelijk voor fijnmazigere controle dan tags.
Next hops
- Ondersteunde next hops voor aangepaste routes zijn onder andere:
  - Standaard internetgateway (0.0.0.0/0 of specifiekere egress-prefixen)
  - Instance (vereist IP-forwarding om verkeer voor anderen te routeren; gebruikt voor virtuele appliances)
  - Cloud VPN-tunnel (statische routes)
  - Regionale interne load balancer als next hop (voor schaalbare appliance-patronen)
- Je kunt de next hop niet instellen op een VPC-peeringverbinding; peering regelt zijn eigen route-uitwisseling.
Voorbeeld van traffic steering (virtuele appliance)
- Maak een specifiekere route dan de subnetroute met een next hop naar een instance met IP-forwarding, gericht op basis van tags op de bron-VM’s.
- Voorbeeld:

undefined

Egress naar Google API’s zonder externe IP-adressen
- Optie 1: Schakel Private Google Access (PGA) in op subnets en voeg vervolgens aangepaste routes voor Google API VIP’s toe naar de standaard internetgateway om, indien nodig, een standaard egress-pad van een derde partij te omzeilen.
- Optie 2: Gebruik Cloud NAT met PGA om egress te bieden voor privé-VM’s naar Google-services.
- Optie 3: Gebruik Private Service Connect naar Google API’s voor verbruik zonder internet; verkeer blijft op het netwerk van Google en gebruikt een privé RFC1918-eindpunt in je VPC.
- Voor beperkte toegang, verwijs clients naar de beperkte (restricted) Google API VIP’s en dwing egress-controles af.

Shared VPC, peering, gedelegeerd beheer en serviceaccounts

Shared VPC
- Het hostproject is eigenaar van een of meer centraal beheerde VPC’s en subnets. Serviceprojecten koppelen workloads aan geselecteerde gedeelde subnets.
- Gedelegeerd beheer
  - De Shared VPC Admin configureert koppelingen en het delen van subnets.
  - Netwerkbeheerders (Network Admins) beheren routes, subnets en de firewall in het hostproject.
  - IAM op projectniveau in serviceprojecten regelt de implementatie van workloads; je kunt alleen de benodigde subnets delen om de ‘blast radius’ en de zichtbaarheid van routes te beperken.
- Serviceaccounts
  - Geef de voorkeur aan op serviceaccounts gebaseerd firewallbeleid voor deterministische, op identiteit gebaseerde controle over teams heen.
  - Gebruik toegewijde serviceaccounts per tier en omgeving, met ’least-privilege’-rollen voor datatoegang (bijvoorbeeld, ken de rol Storage Object Viewer toe aan een serviceaccount dat data uit Cloud Storage leest).
VPC Network Peering
- Beperkingen
  - Niet-transitief: A↔B en B↔C impliceren niet A↔C. Bouw indien nodig een ‘full mesh’.
  - Geen overlappende IP-bereiken tussen gepeerde netwerken.
  - Uitwisseling is beperkt tot subnetroutes (inclusief secundaire bereiken); ’next-hop steering’ via peering wordt niet ondersteund.
- Gebruik peering voor private connectiviteit met lage latentie binnen de organisatie met minimale operationele overhead, wanneer afzonderlijke VPC’s administratief gescheiden moeten blijven.
Hybride connectiviteit
- Centraliseer Dedicated Interconnect en Cloud Router in een Shared VPC-hostproject om connectiviteit met hoge capaciteit te delen met de serviceprojecten van afdelingen.
- Gebruik HA VLAN-attachments, diverse ’edge locations’, dubbele Cloud Routers en ‘global dynamic routing’ voor veerkracht en propagatie naar alle benodigde regio’s.

Operaties: uitbreiding, HA, private toegang, verificatie en probleemoplossing

Beperkingen bij subnetuitbreiding en -migratie
- Breid ter plekke uit wanneer een subnet zijn capaciteit nadert; valideer alle verbonden netwerken op niet-overlappende ranges en zorg ervoor dat afhankelijke secundaire GKE-ranges adequaat blijven.
- Als ranges overlappen tussen organisaties of partners, gebruik dan NAT of gefaseerde hernummering. Je kunt geen overlappende VPC’s peeren of overlappende dynamische routes installeren.
Regionale plaatsing en hoge beschikbaarheid (HA)
- Plaats subnets in regio’s die het dichtst bij gebruikers en data liggen. Voor een gebruikersbestand aan beide kanten van de Atlantische Oceaan biedt een enkele VPC met regionale subnets in us-east1 en europe-west1 directe private connectiviteit met optimale latency en zonder egress-kosten binnen de VPC.
- Verdeel workloads over meerdere zones; gebruik regionale managed instance groups en regionale interne/externe load balancers voor tolerantie tegen zone-uitval.
- Voor hybride omgevingen, implementeer dubbele Cloud Routers en attachments per regio of edge-locatie; schakel BFD in waar ondersteund; gebruik global dynamic routing voor failover.
Private Google Access en beperkte eindpunten
- Schakel PGA in op subnets die instances zonder externe IP-adressen hosten.
- Om algemene internet-egress te voorkomen en tegelijkertijd Google API’s toe te staan:
  - Routeer standaardverkeer naar je NGFW.
  - Voeg specifiekere statische routes voor Google API VIP’s toe naar de default internet gateway of implementeer PSC-eindpunten naar Google API’s.
- Voorbeeld:

undefined

Topologieverificatie en probleemoplossing
- Gebruik Network Intelligence Center:
  - Connectivity Tests om bereikbaarheid te valideren en beslissingen van routing, firewall en gateway te simuleren.
  - Performance Dashboard en Topology om paden en de status ervan te visualiseren.
- Logs en telemetrie:
  - VPC Flow Logs om allow/deny en latency per interface te observeren.
  - Firewall Rules Logging om te bevestigen welke regels worden toegepast.
  - Cloud NAT-logs en -status voor egress-problemen zonder externe IP-adressen.
  - Load balancer- en health-check-logs voor de gereedheid van de backend.
- CLI-controles:

undefined

om het effectieve beleid te bevestigen. -

undefined

vanaf test-VM’s; gebruik packet mirroring voor diepgaande inspectie wanneer nodig.

Praktijkscenario

Acme Retail Group heeft een multi-regionaal Google Cloud-netwerk met lage latency nodig, met gecentraliseerd beheer, internetvrije toegang tot Google API’s voor private instances, en strikte isolatie tussen afdelingen die niet hoeven te communiceren. Sommige teams draaien GKE met een hoge Pod-dichtheid. Acme stuurt ook algemeen egress-verkeer via een firewall van een derde partij, maar wil dat verkeer naar Google API’s deze firewall vermijdt.

Bouw een enkele Shared VPC in een host project in custom mode met global dynamic routing, en creëer regionale subnets in us-east1 en europe-west1 met gereserveerde secundaire ranges voor GKE.

Rationale: Eén VPC biedt private, kosteloze, cross-regionale connectiviteit via RFC1918-adressen voor optimale efficiëntie. Custom mode en global dynamic routing ondersteunen nauwkeurige IP-planning en de propagatie van routes over meerdere regio’s.

Deel alleen de specifieke subnets die nodig zijn met het service project van elke afdeling; creëer drie service projects (Sales, Finance, Marketing) en stel alleen de vereiste subnets aan elk ervan beschikbaar.

Rationale: Het delen per subnet beperkt de ‘blast radius’ en de blootstelling van routes, wat isolatie afdwingt terwijl centrale operaties mogelijk blijven. Gedelegeerde IAM stelt centrale netwerkbeheerders in staat om firewalls en routes te beheren, terwijl app-teams onafhankelijk workloads kunnen implementeren.

Voor afdelingen die moeten communiceren, peer hun dedicated VPC’s of plaats ze in dezelfde Shared VPC-subnets; voor geïsoleerde afdelingen, zie af van peering en deel geen overlappende subnets.

Rationale: Peering biedt private connectiviteit met lage latency en minimale operationele overhead. Non-transitiviteit vereist expliciete mesh-verbindingen alleen waar nodig, wat standaard isolatie behoudt.

Schakel Private Google Access in op alle gedeelde subnets en implementeer Private Service Connect-eindpunten naar Google API’s; behoud de default route naar een firewall van een derde partij, en voeg specifiekere statische routes voor Google API VIP’s toe naar de default internet gateway.

Rationale: PGA en PSC maken internetvrij gebruik van API’s vanaf private VM’s mogelijk. De specifiekere routes zorgen ervoor dat API-verkeer de NGFW omzeilt, terwijl niet-Google internet-egress via het inspectiepad blijft lopen.

Wijs primaire en secundaire CIDR’s toe met ruimte voor groei: voor GKE, bepaal de grootte van een secundaire range voor Pods (bijvoorbeeld /17) en een voor Services (/21) per drukke regio; gebruik alias IP’s voor Pods en Services en creëer VPC-native clusters die aan die ranges zijn gekoppeld.

Rationale: Secundaire ranges en alias IP’s voorkomen uitputting van node-IP’s en maken een dichte planning van workloads mogelijk. Door rekening te houden met toekomstige vraag, worden verstorende aanpassingen en hernummering van secundaire ranges vermeden.

Implementeer HA voor hybride verkeer en verkeer via appliances: implementeer dubbele Cloud Routers en HA VPN of Interconnect waar nodig; waar verkeer via een virtuele appliance moet worden gestuurd, gebruik een specifiekere custom route met de next hop ingesteld op een regionale internal load balancer of een instance met IP forwarding en toepasbaarheid op basis van tags.

Rationale: HA aan de ’edge’ zorgt voor continuïteit tijdens storingen. Het toepassen van routes op basis van tags voorkomt onbedoelde ‘hairpinning’ van verkeer en laat alleen geselecteerde instances het appliance-pad doorlopen.

Verifieer en beheer met Network Intelligence Center Connectivity Tests, VPC Flow Logs en Firewall Rules Logging; dwing op identiteit gebaseerd firewallbeleid af met behulp van service accounts en onderhoud IPAM-records met gereserveerde buffers per regio en functie.

Rationale: Proactieve verificatie voorkomt storingen tijdens wijzigingen. Op identiteit gebaseerd beleid is robuuster dan benaderingen die alleen op tags vertrouwen. IPAM-discipline voorkomt overlap die peering zou blokkeren of geleerde routes zou onderdrukken.

Alle domeinen · Firewallbeleid →

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