Google ACE: VPC-netwerken, connectiviteit en verkeersbeheer — Studiegids

By Laurynas Brazys · 31 August 2026 · #google #ACE #certification #exam-prep #study-guide

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

Overzicht

Virtual Private Cloud (VPC)-netwerken op Google Cloud bieden softwaregedefinieerde, wereldwijde netwerkprimitieven met granulaire controle over adressering, routing, beveiliging en verkeersbeheer. Dit gedeelte richt zich op praktische ontwerp- en operationele onderwerpen die u zult gebruiken om veerkrachtige, veilige en observeerbare netwerken te bouwen die Google Cloud-services, on-premise omgevingen en het openbare internet met elkaar verbinden.

Kernarchitectuur van VPC en IP-planning

VPC-netwerken en subnets
- Een VPC is een wereldwijde resource; de subnets zijn regionaal en kunnen zones overspannen. Instances in elke zone van de regio kunnen een subnet gebruiken.
- Gebruik VPC’s in custom mode voor productie. Auto mode maakt vooraf één subnet per regio aan met een vooraf gedefinieerde set CIDR-reeksen en kan leiden tot overlappende IP-beperkingen, verspilde adresruimte en pijnlijke refactoring wanneer u uitbreidt.
- Secundaire IP-reeksen op subnets maken GKE Pod/Service IP’s en alias IP’s voor VM’s mogelijk. Plan primaire en secundaire CIDR’s vooraf om hernummering te voorkomen.
IP-adresplanning
- Kies niet-overlappende RFC1918-ruimte voor alle huidige en toekomstige VPC’s en on-premise netwerken waarmee u mogelijk verbinding maakt. Reserveer groeiblokken voor toekomstige regio’s en services.
- Geef subnets de juiste grootte (bijv. /24 tot /20) voor groei en vermijd te grote reeksen die ACL’s en diagnostiek bemoeilijken.
- Documenteer het IP-gebruik: primaire reeksen voor workloads, secundaire reeksen voor GKE, en gereserveerde blokken voor NAT-pools of service-eindpunten.
Voorbeeld

undefined

Routing, Firewalls en Beleidshiërarchie

Routes en dynamische routingmodi
- Elke VPC heeft een routeringstabel die bestaat uit door het systeem gegenereerde subnetroutes, standaardroutes en aangepaste statische of dynamische routes.
- Dynamische routingmodus:
  - Regionaal: dynamische (BGP) routes die via Cloud Router worden geleerd, zijn alleen bruikbaar voor resources in dezelfde regio.
  - Globaal: dynamische routes zijn bruikbaar voor resources in alle regio’s van de VPC. Geef de voorkeur aan globaal voor hybride netwerken die on-premise moeten bereiken vanuit meerdere regio’s.
- Next hops: standaard internetgateway (0.0.0.0/0), VPN-tunnel, Cloud Router (BGP), instance (routing-appliance), of een interne load balancer als next hop voor virtuele appliances.
- Routeprioriteit: lagere nummers hebben de voorkeur. Verkeerd geconfigureerde prioriteiten kunnen verkeer ‘blackholen’ of lekken naar een onbedoelde next hop. Gebruik duidelijke conventies (bijv. 1000 voor standaard egress, 900 voor specifiekere routes).
Firewallhiërarchie
- VPC-firewallregels zijn stateful en worden geëvalueerd voordat pakketten worden doorgestuurd. Ze bestaan op VPC-niveau en zijn van toepassing op alle subnets.
- Hiërarchische firewall policies (gekoppeld aan organization, folder of project) dwingen allow/deny af vóór de VPC-regels. Gebruik ze om centrale ‘guardrails’ (vangrails) te implementeren (bijv. het weigeren van aan het internet blootgestelde beheerderspoorten).
- Impliciete regels: een impliciete ‘allow egress’ en een impliciete ‘deny ingress’ bestaan met de laagste prioriteit; ze kunnen niet worden verwijderd. Alle connectiviteit vereist expliciete ‘ingress allow’-regels.
Firewallregels, tags, service accounts, secure tags
- Targeting: gebruik netwerktags of service accounts om regels toe te passen op specifieke VM’s; targeting op basis van service accounts biedt een striktere, op identiteit gebaseerde controle.
- Secure tags bieden centraal beheerde, door IAM beschermde labels voor policy-targeting; ze voorkomen dat workloads ze zelf aan zichzelf koppelen en ondersteunen zero-trust segmentatie.
- Logging: schakel firewall-logging selectief in voor zeer belangrijke regels om een balans te vinden tussen zichtbaarheid en kosten; sample pakketten, niet de volledige payloads.
- Veelvoorkomende faalscenario’s: ontbrekende source ranges voor health checks, asymmetrische routing die ‘reply drops’ veroorzaakt, te brede source ranges die onbedoelde blootstelling creëren.
Voorbeeld

undefined

Load Balancing, IP’s, DNS en Traffic Management

Typen en gedrag van Cloud Load Balancing
- Wereldwijde proxy-gebaseerde: External HTTP(S), External TCP Proxy, External SSL Proxy. Beëindigen clientverbindingen aan de rand van het Google-netwerk, ondersteunen anycast wereldwijde VIP’s en voegen headers toe (bijv. X-Forwarded-For). Het oorspronkelijke IP-adres van de client is beschikbaar via headers of het PROXY-protocol (voor TCP) in plaats van dat het wordt behouden als L3-bron.
- Regionale passthrough: External Network Load Balancer en Internal TCP/UDP Load Balancer routeren verkeer op L4 en behouden het IP-adres van de client. Gebruik dit wanneer u zichtbaarheid van het bron-IP-adres op backends nodig hebt zonder het PROXY-protocol.
- Internal HTTP(S) Load Balancer: regionale L7-proxy voor interne services met geavanceerde routerings- en mTLS-opties.
Backend services, health checks en traffic policies
- Backend services definiëren backends (instance groups, NEG/VM/Endpoint, GKE-services), de balancing-modus (UTILIZATION of RATE), capaciteitslimieten, session affinity en connection draining.
- Health checks moeten worden toegestaan door firewalls vanaf de Google health-checkers. Ongezonde backends worden automatisch verwijderd; verkeerd geconfigureerde health checks kunnen een totale storing veroorzaken.
- Traffic policies omvatten locality (regio/zone), overflow- en failover-backends, en gewogen traffic splitting voor geleidelijke rollouts bij sommige LB-typen.
Externe en interne IP’s, forwarding rules
- Externe en interne adressen kunnen ephemeral (tijdelijk) of gereserveerd statisch zijn. Wereldwijde statische externe adressen worden gebruikt door wereldwijde LB’s; de meeste andere zijn regionaal.
- Forwarding rules mappen een IP:poort naar een target (bijv. targetHttpProxy of backend service). Kies wereldwijde versus regionale regels die overeenkomen met het LB-type; een mismatch voorkomt de aanmaak.
Cloud DNS
- Zones: publieke zones resolven op het openbare internet; private zones zijn alleen resolvable vanuit geautoriseerde VPC’s. Gebruik managed records (A/AAAA, CNAME, TXT, MX, SRV, etc.).
- Split-horizon: maak zowel publieke als private zones aan voor hetzelfde domein, zodat interne resolvers private antwoorden ontvangen (bijv. ILB IP), terwijl publieke gebruikers internetgerichte IP’s krijgen.
- Private DNS forwarding: gebruik Cloud DNS-policies voor inkomende en uitgaande forwarding om te integreren met on-prem resolvers; gebruik DNS-peering tussen VPC’s om private zones te delen zonder volledige peering-connectiviteit.
Voorbeeld
- gcloud compute forwarding-rules create web-ilb –region=us-central1 –load-balancing-scheme=INTERNAL_MANAGED –ports=80 –backend-service=web-be

Hybride en Private Connectiviteit

Cloud Router, Cloud NAT en Private Google Access
- Cloud Router wisselt routes uit met on-prem via BGP, adverteert VPC-subnetten en importeert on-prem prefixes. Gebruik global dynamic routing wanneer meerdere regio’s on-prem bereikbaarheid nodig hebben.
- Cloud NAT biedt internet-egress voor private VM’s en GKE-nodes zonder externe IP’s. Bepaal de grootte van NAT IP-pools om poortuitputting te voorkomen; monitor logs voor verbroken verbindingen en schaal adressen dienovereenkomstig op.
- Private Google Access (PGA) stelt private VM’s in staat om Google API’s te bereiken zonder externe IP’s via het standaard routeringspad. Private Service Connect (PSC) voor Google API’s biedt private IP-eindpunten in uw VPC met policy-controle en vermijdt publieke egress volledig; geef de voorkeur aan PSC-eindpunten voor striktere egress-controle en consistente DNS.
Private Service Connect (producer- en consumer-services)
- Stel interne services beschikbaar achter een service attachment in een producer-project en consumeer ze via private eindpunten in consumer-projecten. DNS-mapping en expliciete allow-policies regelen de toegang. Dit verbetert de isolatie ten opzichte van VPC Peering en centraliseert het publiceren van services.
VPC Network Peering, Shared VPC en segmentatie
- VPC Peering biedt private connectiviteit tussen VPC’s met lage latentie. Het is niet-transitief en staat geen overlappende IP’s toe. Optionele import/export van custom routes breidt de bereikbaarheid uit, maar creëert nog steeds geen transitieve routering; plan hub-and-spoke-modellen bewust.
- Shared VPC centraliseert subnetten in een host-project voor gebruik door service-projecten. Dit maakt gecentraliseerde routering, firewalls, NAT en LB’s mogelijk, terwijl IAM per applicatie wordt gedelegeerd. Combineer met hiërarchische firewalls en secure tags voor segmentatie.
- Network Connectivity Center (NCC) biedt een hub voor het orkestreren van spokes (VPN, Interconnect, router appliance, VPC spokes) en het consistent beheren van enterprise WAN-topologieën.
Cloud VPN, Cloud Interconnect en BGP
- Cloud VPN: gebruik HA VPN met dynamic routing (BGP) voor beschikbaarheid en automatische route-failover. Bouw twee tunnels per peer over onafhankelijke Cloud VPN-interfaces en, indien mogelijk, afzonderlijke on-prem apparaten/verbindingen.
- Cloud Interconnect: Dedicated Interconnect biedt private 10–100 Gbps-verbindingen; Partner Interconnect maakt gebruik van een serviceprovider. Voor veerkracht (resilience), implementeer redundante interconnects in diverse edge availability domains en gebruik BFD met BGP waar ondersteund.
- Failure domains: isoleer per regio, zone, apparaat en provider. Test failover regelmatig; asymmetrische paden kunnen stateful firewalls on-prem verstoren.
Voorbeelden
- gcloud compute routers create corp-router –region=us-central1 –network=prod-net –asn=64514
- gcloud compute routers nats create nat-us-central1 –router=corp-router –nat-all-subnet-ip-ranges –auto-allocate-nat-external-ips
- gcloud compute vpn-gateways create ha-gw –region=us-central1 –network=prod-net

Observeerbaarheid en Troubleshooting

Connectiviteitstests
- Simuleer en verifieer de bereikbaarheid tussen bronnen en bestemmingen over VPC’s, on-prem (via hybride koppelingen) en load balancers. De tool evalueert routes, firewallregels en configuratie om drops of verkeerd gerouteerd verkeer te lokaliseren voordat er wijzigingen in productie worden doorgevoerd.
- Voorbeeld:

undefined

VPC Flow Logs
- Activeer op subnetniveau voor real-time inzicht in 5-tuple flows, bytes, drops en latency. Exporteer naar Cloud Logging, Pub/Sub of BigQuery voor analyses. Pas sampling- en metadataniveaus aan om de kosten te beheersen.
- Gebruiksscenario’s: effectiviteit van firewalls valideren, exfiltratie detecteren, capaciteitsplanning en SLO-monitoring.
Packet Mirroring
- Spiegel VM- of GKE-verkeer naar collector-eindpunten voor deep packet inspection of IDS. Beperk de scope van mirrors op basis van subnet, tag of instance. Begrijp de prestatie-overhead en zorg ervoor dat collectors het gespiegelde volume aankunnen. Vermijd het spiegelen van post-NAT-verkeer als u de originele headers nodig heeft.
Veelvoorkomende diagnostische patronen
- Blackhole: er bestaat een route, maar het antwoordpad wordt geblokkeerd door een firewall of asymmetrische routing; valideer met Connectivity Tests en flow logs aan beide kanten.
- Health check-fouten: bevestig dat de firewall verkeer van de health-checkers toestaat en dat backends op de juiste poorten luisteren; test lokaal vanaf een VM in hetzelfde subnet.
- NAT-uitputting: zoek naar geweigerde flows met de reden “no available NAT ports”; voeg meer NAT IP’s toe of verlaag de poortlimieten per VM.

Praktisch Probleemscenario

Acme Retail beheert een e-commerceplatform in meerdere regio’s met private backends, een publieke webingang en een on-prem ERP-systeem. Ze moeten workloads segmenteren, private egress naar Google API’s voorzien, hybride bereikbaarheid vanuit alle regio’s mogelijk maken en de beveiliging versterken met behoud van observeerbaarheid.

Creëer een Shared VPC in custom-mode voor centraal beheer

undefined

Rationale: Custom-mode vermijdt automatisch toegewezen CIDR’s en maakt een doordachte IP-planning mogelijk. Shared VPC centraliseert routing, firewalls en NAT in een hostproject, terwijl serviceprojecten veilig kunnen deployen.

Plan en creëer subnets met secundaire ranges voor GKE

undefined

Rationale: Niet-overlappende primaire en secundaire ranges voorkomen toekomstige peering-conflicten en maken alias-IP’s voor GKE mogelijk zonder IP-uitputting.

Stel VPC dynamic routing in op global en implementeer een Cloud Router

undefined

Rationale: De global-modus maakt via BGP geleerde on-prem routes bruikbaar vanuit alle regio’s, wat de hybride bereikbaarheid en failover vereenvoudigt.

Zet een HA VPN op naar on-prem en adverteer subnets

Creëer twee HA VPN-tunnels naar verschillende on-prem apparaten. Gebruik BGP om prefixes uit te wisselen en een soepele failover mogelijk te maken.
Rationale: Dubbele tunnels elimineren single points of failure; BGP convergeert routes snel tijdens onderhoud of storingen.

Implementeer Cloud NAT voor private egress en PSC voor Google API’s

undefined

Creëer Private Service Connect-eindpunten voor Google API’s en werk private DNS bij om API-eindpunten naar PSC te mappen.
Rationale: NAT maakt egress naar het internet mogelijk zonder externe VM-IP’s; PSC houdt API-verkeer op private IP’s en onder expliciet beleidsbeheer, waardoor publieke egress-paden worden geëlimineerd.

Frontend met een globale External HTTP(S) Load Balancer; interne services via Internal HTTP(S)

Creëer een globale externe HTTP(S) LB met een beheerd certificaat en een backend service die naar NEG-backends verwijst.
Creëer regionale Internal HTTP(S) LB’s voor service-naar-service-verkeer met mTLS tussen microservices.
Rationale: De globale proxy LB biedt anycast, autoscaling en CDN; de interne L7 LB biedt uitgebreide routing en beveiliging voor oost-west verkeer.

Implementeer hiërarchische firewall-policies en workload identity targeting

Koppel een policy op organisatieniveau die admin-poorten vanaf het internet weigert; sta alleen bronnen voor LB health-checks toe.
Creëer VPC-regels gericht op service accounts voor least-privilege toegang tussen tiers; gebruik secure tags voor dynamische segmentatie.
Rationale: Hiërarchie dwingt centraal ‘guardrails’ af; op identiteit gebaseerde targeting is bestand tegen tag-spoofing en vereenvoudigt automatisering.

Configureer Cloud DNS met split-horizon en forwarding

Creëer een publieke zone acme.com voor de web-VIP en een private zone acme.com voor interne servicenamen die naar ILB’s mappen.
Configureer outbound forwarding naar on-prem DNS en inbound zodat on-prem de private zones kan resolven.
Rationale: Split-horizon voorkomt datalekken en zorgt voor correcte naamresolutie op basis van het bronnetwerk; forwarding integreert legacy namespaces.

Gebruik Connectivity Tests, flow logs en packet mirroring voor inzicht

Creëer tests voor kritieke paden (gebruiker naar web LB, web naar interne services, services naar on-prem ERP).
Activeer flow logs op subnets; exporteer naar BigQuery voor trendanalyse. Schakel packet mirroring tijdelijk in tijdens incident response.
Rationale: Proactieve validatie en telemetrie verkorten de MTTR, leggen misconfiguraties bloot en bieden inzicht in de capaciteit.

Documenteer en test faalscenario’s

Simuleer het verlies van een VPN-tunnel, een regio en een backend-MIG. Verifieer de BGP-failover, de verwijdering door de LB health-check en de correctheid van DNS.
Rationale: Regelmatige ‘game days’ bevestigen aannames over redundantie en leggen configuratie-afwijkingen bloot voordat deze storingen veroorzaken.

← Containers · Alle domeinen · Opslag →

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