Google PCNE: Load Balancing, Cloud CDN en Globaal Verkeersbeheer — 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

Deze sectie legt uit hoe Google Cloud Load Balancing, Cloud CDN en wereldwijd verkeersbeheer samenwerken om veerkrachtige, performante en veilige services te leveren. Het behandelt load-balancer-families en de selectie ervan, proxy- versus passthrough-gedrag, backend- en routeringscomponenten, failover en capaciteitsbeheer, Cloud CDN-caching en origin-beveiliging, anycast- en cross-region-ontwerpen, DNS-sturing en health checks, observeerbaarheid en ontwerppatronen voor robuuste wereldwijde toegangspunten.

Load-balancer-families, selectie en data-plane-gedrag

Google Cloud biedt externe en interne load balancers met verschillende scope-, protocol- en data-plane-kenmerken. Door de juiste te kiezen, stemt u protocolbehoeften, geografie en operationele controles op elkaar af.

Externe proxy L7 (globaal): External Application Load Balancer voor HTTP(S) en gRPC. Beëindigt TLS, dwingt L7-beleid af, ondersteunt URL-maps, Cloud CDN, Cloud Armor, request/response-functionaliteiten en anycast IPv4/IPv6. Meest geschikt voor op het internet gerichte web-API’s/sites die geavanceerde routering, beveiliging en caching vereisen.
Externe proxy L4.5: External TCP Proxy Load Balancer (globaal) en External UDP Proxy Load Balancer (regionaal) beëindigen clientverbindingen en fungeren als proxy naar backends. Gebruik wanneer u een globale VIP en L4-functionaliteiten (TLS-beleid, behoud van client-IP via headers voor TCP) nodig hebt zonder L7-routering.
Externe passthrough L3/L4 (regionaal): External Network Load Balancer stuurt pakketten door zonder de verbinding te beëindigen. Laagste latency en eenvoudigst; ondersteunt TCP/UDP/ESP/ICMP. Geschikt voor lift-and-shift, heterogene backends of protocollen die proxy-beëindiging niet tolereren. Klassieke NLB gebruikt target pools; de nieuwere regionale passthrough NLB gebruikt backend services.
Interne proxy (regionaal): Internal HTTP(S) Load Balancer (L7) en Internal TCP Proxy Load Balancer (L4.5) beëindigen verbindingen en fungeren als proxy binnen een VPC voor north-south- en service-to-service-gebruik van microservices. Ondersteunen host/path-routering (HTTP), mTLS naar clients via de applicatie en per-service beveiligingsbeleid.
Interne passthrough (regionaal): Internal TCP/UDP Load Balancer distribueert verbindingen naar backends via private RFC1918-adressen, waarbij het client-IP behouden blijft en MAGLEV-hashing wordt gebruikt. Ideaal voor east-west-services (databases, custom protocollen) die zone-bewuste distributie en lage overhead vereisen.

Afwegingen tussen laag en beëindiging:

Proxy L7/4.5 biedt geavanceerde routering, TLS-offload, observeerbaarheid, Cloud Armor/CDN en cross-region failover ten koste van extra hops en mogelijke header/NAT-wijzigingen. Het is geschikt voor publieke toegangspunten en service meshes.
Passthrough L3/L4 behoudt het client-IP end-to-end en minimaliseert de latency, maar heeft geen L7-functionaliteiten en minder observeerbaarheidshooks. Sessiegedrag is op hash gebaseerd; health checks zijn eenvoudiger.

Scope en IP-families:

Globale anycast VIP’s zijn beschikbaar voor de externe Application LB en externe TCP Proxy LB, en bieden één enkel IPv4/IPv6-adres dat overal bereikbaar is. Regionale LB’s gebruiken regionale unicast VIP’s. IPv6-blootstelling voor publieke services wordt bereikt door een externe globale load balancer te configureren met een IPv6-adres.

Hoofdpunten van selectiecriteria:

Nood aan host/path-routering, redirects, Cloud CDN, Cloud Armor of gRPC: External Application LB.
Nood aan globale TCP zonder L7: External TCP Proxy LB.
Protocollen die niet goed werken met proxy’s (bijv. sommige legacy UDP/TFTP): Externe of Interne passthrough.
Private service-to-service met HTTP-routering: Internal HTTP(S) LB.
Minimaliseer kosten/hops voor intra-VPC-verkeer: Interne passthrough.

Backend-services, routeringsobjecten, health en traffic stickiness

Kernobjecten van de data-plane:

Backend-services: Definiëren backends (instance groups, zonal NEG, hybrid NEG, serverless NEG), healthchecks, balancing-modus, capaciteit, sessieaffiniteit, time-out en failover-beleid. Vereist voor proxy-LB’s en nieuwere passthrough-LB’s.
Target pools: Verouderde constructie voor klassieke externe NLB. Geschikt voor eenvoudige TCP/UDP-distributies en heterogene VM’s tijdens lift-and-shift.
Named ports: Sleutels op instance groups die logische namen (bijv. http) koppelen aan poortnummers, waarnaar wordt verwezen door backend-services en URL-maps. Zorg voor consistentie tussen de leden van de groep.

Healthchecks en failover:

Typen: HTTP(S), HTTP/2, gRPC, TCP, SSL. Kies een check die de daadwerkelijke gereedheid van de service valideert, niet alleen de bereikbaarheid van het besturingssysteem.
Scope: Healthchecks zijn regionaal; elke backend moet een healthcheck hebben die is gescoped op de regio waarin deze actief is.
Failover-beleid: Een backend-service kan primaire en failover-backends aanwijzen. Verkeer schakelt over naar de failover-backend wanneer de primaire backend ongezond is of onvoldoende capaciteit heeft (als failover-on-capacity is ingeschakeld en de drempelwaarde is bereikt). Overweeg draining en capaciteitsreservering om een ’thundering herd’-effect te voorkomen.

URL-maps en routering:

URL-map wordt gekoppeld aan de externe of interne HTTP(S) LB en definieert hostregels en pad-matchers.
Standaard service: Catch-all backend voor verzoeken die niet aan een regel voldoen; als dit niet is ingesteld, wordt een 404 geretourneerd.
Redirects en rewrites: Gebruik URL-map-acties om HTTPS-redirects, canonieke host-redirects of pad-rewrites uit te voeren voordat er wordt gerouteerd.

Voorbeeld: minimale URL-map met HTTPS-redirect en standaard backend

Maak een hostregel voor example.com, stuur HTTP door naar HTTPS, routeer /static naar een backend-bucket met CDN en gebruik standaard een regionale backend-service.

Sessieaffiniteit en draining:

Affiniteitsopties zijn afhankelijk van het LB-type. Veelvoorkomende opties:
- Geen: Beste voor stateless; maximaliseert de verdeling van de belasting.
- Client-IP: Sticky op basis van bron-IP voor L4/L7; gebruik wanneer meerdere protocollen (bijv. HTTP en TFTP) co-sticky moeten zijn naar dezelfde backend.
- Gegenereerde cookie (alleen L7): LB stelt een cookie in om de sessie aan een backend te koppelen; betere verdeling dan client-IP bij clients achter NAT.
Afwegingen: Affiniteit kan hotspotting veroorzaken en autoscaling bemoeilijken. Geef waar mogelijk de voorkeur aan statelessness.
Connection draining: Bij scale-in of het verwijderen van een backend, respecteert de LB de draining-time-out om bestaande verbindingen netjes te laten sluiten. Stem de drain-tijd af op je langst verwachte verzoek om resets te voorkomen.

Capaciteit en autoscaling:

Balancing-modi: Gebaseerd op gebruik (bijv. CPU), RPS of verbindingen. Elke backend adverteert capaciteit; de LB leidt verkeer af of voert een failover uit wanneer verzadiging optreedt.
Autoscaling: Managed instance groups schalen op basis van signalen (CPU, aangepaste metrics). Vertraging bij het uitschalen (scale-out lag) kan 503-fouten veroorzaken als de LB onvoldoende capaciteit heeft; warm vooraf op met een minimumaantal replica’s of voorspellende autoscaling voor dagelijkse verkeerspatronen.
Failover en overflow: Het inschakelen van failover-on-capacity met een geschikte drempelwaarde maakt een soepele overflow tussen regio’s mogelijk.

Beveiliging bij backends:

Beperk de toegang tot de backend met firewallregels die gericht zijn op instance-tags of service-accounts. Sta alleen verkeer toe van de Google load balancer en de bronbereiken van de healthchecks, en je goedgekeurde clientbereiken als directe toegang voor interne clients vereist is.

Voorbeeld: beperk clients en healthchecks tot een groep met backend-tags

Tag instances met application.
Maak een ingress allow-regel voor tcp:80 vanaf je client-CIDR’s en de Google healthcheck-bereiken, gericht op de tag application.
Een deny-by-default-beleid wordt aanbevolen om geweigerd verkeer zichtbaar te maken in de logs.

Cloud CDN, cachebeleid en origin-beveiliging

Cloud CDN integreert met de externe Application Load Balancer om responsen te cachen bij edge POP’s, wat de latency verlaagt en de origin-capaciteit ontlast.

Cachemodi en TTL’s:

Gebruik origin-headers: Respecteert Cache-Control en Expires van je origin. Heeft de voorkeur voor correctheid.
Forceer cache: Cacht alle responsen met een geconfigureerde standaard-TTL, waarbij optioneel origin-headers voor statische content worden overschreven of genegeerd. Gebruik dit voorzichtig om te voorkomen dat dynamische data wordt gecacht.
Cache omzeilen: Nuttig voor paden die nooit gecacht mogen worden.

Cachesleutels:

Sleutelvelden omvatten protocol, host, pad, queryparameters, headers en cookies. Configureer query-string-beleid (alles opnemen, geselecteerde opnemen of negeren), selectieve opname van headers en cookies, en apparaatsegmentatie naar behoefte.
Houd sleutels minimaal om de hit ratio te maximaliseren; varieer alleen op velden die de representatie veranderen.

Ondertekende verzoeken:

Signed URL’s: Voeg een HMAC- of RSA-handtekening met vervaldatum en pad-scope toe om tijdsgebonden toegang tot specifieke resources te verlenen. Goed voor CDN-as-accelerator met autorisatie per object.
Signed cookies: Autoriseer een reeks paden met een cookie; nuttig voor afgeschermde content op een volledige site.
Roteer sleutels en dwing korte vervaltijden af om het risico op replay-aanvallen te verminderen.

Compressie en correctheid:

Origins moeten comprimeren, zelfs wanneer verzoeken een Via-header bevatten. Als de CDN ongecomprimeerde objecten serveert terwijl de origin ‘compressie ondersteunt’, verifieer dan of de origin is geconfigureerd om te comprimeren wanneer de Via-header aanwezig is.

Origin-beveiliging:

Gebruik HTTPS van edge-proxy’s naar origins met moderne TLS-beleidsregels.
Beperk de bereikbaarheid van de origin: backend-firewallregels die alleen verkeer toestaan van Google load balancer- en health check-bronbereiken en van bekende private producers. Backend-instances mogen geen willekeurig publiek inkomend verkeer accepteren.
Koppel met Cloud Armor voor L7 DDoS/WAF, rate limiting en dreigingsdetectie. Gebruik de preview-modus voor nieuwe regels om false positives te beperken.
Invalideer content opzettelijk met cache-invalidatie-API’s wanneer je deze moet verwijderen voordat de TTL verloopt. Geef voor dynamische content de voorkeur aan korte TTL’s en revalidatie (ETag/If-None-Match).

Faalmodi en afwegingen:

Te brede cachesleutels verspillen cache en verlagen de hit ratio; te smalle sleutels riskeren het serveren van incorrecte varianten.
Het forceren van het cachen van dynamische data kan gepersonaliseerde content lekken.
Signed URL’s/cookies beveiligen de toegang aan de edge, maar het omzeilen van de origin moet nog steeds worden geweigerd via netwerkbeleid.

Globaal verkeersbeheer, DNS-sturing, observability en veerkrachtige toegangspunten

Anycast front-doors en cross-region failover:

External Application LB en external TCP Proxy LB gebruiken globale anycast VIP’s om clients naar de dichtstbijzijnde Google edge te leiden. Het verkeer wordt vervolgens via een proxy doorgestuurd naar de meest gezonde en dichtstbijzijnde backend met capaciteit. Configureer meerdere backend-regio’s met consistente health checks en capaciteitsinstellingen voor naadloze failover en overflow.
Voorzie capaciteit in secundaire regio’s om ‘cold-start penalties’ te vermijden; coördineer de min/max van de autoscaler met de capaciteitsdrempels van de LB.

Regionaal intern verkeersbeheer:

Internal HTTP(S) LB en internal passthrough LB zijn regionaal; ontwerp voor diversiteit van zones binnen een regio en, indien nodig, voor multi-region met behulp van afzonderlijke LB’s met Private Service Connect of service-aware clients om regionale endpoints te selecteren.
Houd de oost-west latency laag door communicerende services in dezelfde regio en VPC te plaatsen. Gebruik RFC1918-adressering met een enkele VPC of peered VPC’s voor minimale kosten en operationele eenvoud.

Cloud DNS-routeringsbeleid en health checks:

Beleidsregels: Weighted round robin (verkeer splitsen), geolocatie (gebruikers naar de dichtstbijzijnde regionale VIP sturen) en failover (primair/back-up). Combineer beleidsregels om aan de bedrijfsregels te voldoen.
Health checks: Koppel DNS health checks (HTTP/HTTPS/TCP) aan A/AAAA-records die worden gebruikt bij de sturing, zodat ongezonde endpoints worden teruggetrokken. Houd rekening met resolver caching (TTL), wat de reactie vertraagt; houd TTL’s laag op gestuurde records om de reactiesnelheid van failover te verbeteren, ten koste van meer DNS-lookups.
Verkeerssturing: Gebruik ‘weighted’ beleidsregels om migraties te faseren of de belasting tussen regio’s te verschuiven. Vermijd het sturen naar privé-adressen vanaf het internet, tenzij u split-horizon DNS gebruikt.

Observability en diagnostiek:

Load-balancer logging: Schakel logging in voor alle LB’s. HTTP(S)-logs bevatten request method/URI, latency, cache hit/miss, backend service, URL map-regel, TLS-details en response codes. TCP/UDP-logs bieden verbindingsmetadata en de status van health probes.
Metrics: Monitor de backend health, utilization, RPS, verbindingen, latency, cache hit ratio, 4xx/5xx-rates en capaciteitsverzadiging. Stel alerts in voor plotselinge veranderingen en aanhoudende drempelwaarden.
Veelvoorkomende HTTP(S)-foutpatronen:
- 404: Geen URL map-match; controleer de host/path-regels en de default service.
- 301/302: Opzettelijke redirects; controleer op redirect loops.
- 502: Backend-verbindings- of protocol-mismatch (bijv. HTTP/1.1 vs gRPC); controleer de health en de protocolconfiguratie van de backend.
- 503: Geen gezonde backends of geen capaciteit; controleer de health checks, quota’s en het gedrag van de autoscaler.
Request tracing: Gebruik X-Forwarded-For, X-Forwarded-Proto en trace-ID’s die door uw app worden doorgegeven. Correleer LB-logs met backend-logs met behulp van request-ID’s.
Firewall insights: Schakel VPC firewall logging in voor ‘allow’- en ‘deny’-regels. Om drops expliciet te loggen, voegt u een ‘deny-all’-regel met lage prioriteit en ingeschakelde logging toe.

Ontwerp van veerkrachtige globale toegangspunten:

Gebruik één globale anycast VIP op een external Application LB die meerdere regionale backends bedient. Plaats serverless/VM/container-backends in ten minste twee regio’s. Schakel cross-region failover en overflow in, configureer conservatieve health checks en stem de draining en timeouts af op uw workloads.
Bescherm de toegang met Cloud Armor en beleid voor quotabeperking. Gebruik Cloud CDN voor statische en cachebare dynamische content om piekbelastingen in het verkeer aan de edge op te vangen.
Stel dual-stack IPv4/IPv6 beschikbaar op de globale LB om alle netwerken te bedienen. Voor strikte clienttoegang past u backend firewall-regels toe met precieze source ranges en instance tags of service accounts.

Voorbeeld: firewallregel die client- en health check-ranges beperkt tot getagde backends

Tag instances met ‘application’.
Maak een ingress ‘allow’-regel voor tcp:443 met source-ranges=203.0.113.0/24,198.51.100.0/24 en de Google health check-ranges, gericht op ‘application’.
Zorg ervoor dat er een ‘deny-all’-regel met lagere prioriteit en logging bestaat om onverwachte bronnen op te vangen.

Praktisch Probleemscenario

Acme Retail lanceert een wereldwijd e-commerceplatform dat lage latency, sterke beveiliging en transparante failover vereist tussen us-east1 en europe-west1, terwijl statische media efficiënt worden aangeboden. Alleen de hoofdkantoren en een partner CDN-stagingnetwerk mogen de private beheerinterface bereiken.

Front-door en backends

Maak een external Application Load Balancer met een dual-stack anycast VIP en TLS-certificaten voor de publieke storefront-hostname.
Definieer twee backend services, die elk verwijzen naar een regionale managed instance group in us-east1 en europe-west1. Schakel health checks (HTTPS) in en stel de balancing mode in op ‘utilization’ met een capaciteitsdrempel van 80%. Reden: Anycast plus multi-region backends zorgt ervoor dat gebruikers de dichtstbijzijnde edge bereiken en naadloos een failover uitvoeren als een regio ongezond of overbelast is.

URL map, routering en redirects

Configureer een URL map met host-regels voor de publieke storefront- en private administrator-hostnames. Routeer /static naar een backend bucket met Cloud CDN ingeschakeld; routeer /api en / naar de VM-backends. Voeg een HTTP-naar-HTTPS redirect toe. Reden: Host/path-routering scheidt statisch van dynamisch verkeer en dwingt veilige toegang af.

Cloud CDN-beleid

Stel voor de /static backend bucket de cache mode in op ‘use origin headers’ en definieer een cache key die niet-functionele query parameters negeert en alleen de Accept-Encoding header opneemt. Schakel negative caching in voor veelvoorkomende 404’s met een korte TTL. Reden: Respecteert de semantiek van de content, maximaliseert de hit ratio en voorkomt het cachen van incorrecte varianten.

Session affinity en draining

Stel ‘generated-cookie’ affinity in voor de publieke storefront en geen affinity voor statische assets; stel connection draining in op 60 seconden. Reden: Cookies houden winkelwagensessies stabiel terwijl brede distributie mogelijk blijft; draining voorkomt voor de gebruiker zichtbare fouten tijdens scale-in of failover.

Cross-region failover en autoscaling

Schakel ‘failover-on-capacity’ in met een overflow-drempel van 90% om overtollig verkeer naar de andere regio te verplaatsen. Configureer MIG autoscaling met een minimum van 4 replica’s per regio en CPU-targets die overeenkomen met de LB-utilization. Reden: Vermijdt capaciteitsdrempels (‘capacity cliffs’) en coördineert beslissingen van de LB en autoscaler voor soepele schaalvergroting.

Beperking van de beheerinterface

Maak een internal HTTP(S) Load Balancer voor de private administrator-hostname, die alleen toegankelijk is binnen de VPC. Publiceer split-horizon Cloud DNS zodat interne clients de ILB VIP resolven en externe clients een NXDOMAIN ontvangen. Reden: Houdt beheerverkeer privaat en gecontroleerd zonder publieke endpoints bloot te stellen.

Backend firewall en origin security

Tag de admin- en web-backends met ‘application’ en voeg een ‘allow’-regel toe voor tcp:443 vanaf de CIDR’s van het bedrijf en de staging-omgeving, plus de source ranges van de Google load balancer en health checks; voeg een ‘deny-all’ met logging toe op een lagere prioriteit. Reden: Zorgt ervoor dat alleen bedoelde clients en de Google-infrastructuur de backends kunnen bereiken en biedt inzicht in gedropte pakketten.

Cloud Armor

Pas een security policy toe met beheerde WAF-regels en een rate limit in preview-modus voor pieken op /api. Reden: L7-bescherming en gefaseerde handhaving verminderen het risico tijdens het afstemmen.

Cloud DNS-sturing en health checks

Publiceer A- en AAAA-records voor de publieke storefront-hostname naar de anycast VIP van de ALB. Voor een blue/green canary, maak een ‘weighted’ beleid aan op een specifieke canary-hostname, waarbij 5% wordt gesplitst naar de ALB die alleen in europe-west1 draait en 95% naar de globale implementatie. Koppel HTTPS health checks om de canary terug te trekken als deze ongezond is en stel de TTL in op 20 seconden. Reden: Een op DNS gebaseerde canary maakt geleidelijke blootstelling mogelijk met health-aware verwijdering en snelle convergentie.

Observability

Schakel LB- en CDN-logs in; exporteer deze naar BigQuery voor analyse. Stel alerts in voor de 5xx-rate, backend-capaciteit, mislukte health checks en de CDN hit ratio. Gebruik URL map-tests en request-logs om routeringsfouten te diagnosticeren; inspecteer pieken in 502/503-fouten op backend-verzadiging of protocol-mismatches. Reden: Proactieve monitoring en snelle diagnostiek minimaliseren de MTTR en waarborgen de gebruikerservaring.

← Hybride Connectiviteit · Alle domeinen · Cloud DNS →

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