Google PCA: Kosten, Prestaties en Duurzaam Cloud-ontwerp — 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

Kosten, prestaties en duurzaam cloudontwerp zijn disciplines die gezamenlijk worden geoptimaliseerd. Het bouwen van efficiënte architecturen op Google Cloud vereist financieel inzicht, elastische capaciteit die de vraag volgt, strikt beheer van de datalevenscyclus, doordachte plaatsing en caching voor netwerken, en continue metingen. Dit gedeelte legt ontwerp- en operationele patronen uit die verspilling verminderen zonder in te boeten op betrouwbaarheid, beveiliging of prestaties, en belicht faalmodi en afwegingen om kostbare verrassingen te voorkomen.

Kostenarchitectuur en Financiële Verantwoordelijkheid

Implementeer financiële controles als onderdeel van uw platformbaseline.

Factureringsanalyse en -toewijzing
- Exporteer factureringsgegevens naar BigQuery voor doorzoekbare, bijna-realtime-uitgavenanalyse per project, service, SKU en label. Partitioneer per dag voor schaalbare query’s en stel toegangscontroles voor datasets in voor financiële en technische belanghebbenden.
- Gebruik budgetten met waarschuwingsdrempels om ongemerkte kostenoverschrijdingen te voorkomen. Stuur budgetwaarschuwingen naar Pub/Sub en automatiseer reacties (bijvoorbeeld het pauzeren van niet-kritieke workloads). Houd er rekening mee dat waarschuwingen niet transactioneel zijn en vertragingen in de rapportage kunnen hebben; vertrouw er niet op als de enige controle voor uit de hand gelopen taken.
Labels, tags en kostentoerekening
- Standaardiseer organisatiebrede labels (cost_center, env, owner, app) en dwing deze af op het moment van provisioning met implementatietemplates of policy-as-code.
- Geef de voorkeur aan hiërarchische tags en een map-/projectstructuur om chargeback/showback-modellen te weerspiegelen. Gebruik zowel labels (op resourceniveau) als tags (voor beleid en factureringsbereik) om een nauwkeurige toewijzing te realiseren.
Budgetkaders en anomaliedetectie
- Configureer budgetten per project en per portfolio; stel meerdere drempels in (bijvoorbeeld 50, 80, 100 procent) en ‘voorspelde’ waarschuwingen voor proactieve actie.
- Gebruik Recommender-inzichten (inactieve VM, niet-gekoppelde schijf, IP’s, ongebruikte commitments) om continu verspilling tegen te gaan.
Praktische voorbeelden
- Labels toepassen bij het aanmaken:

undefined

Query de factureringsexport op uitgaven zonder label om naleving af te dwingen via CI/CD-controles.

Veelvoorkomende faalmodi en afwegingen:

Inconsistente labels verstoren de kostentoewijzing; dwing dit af met organisatiebeleid en validatie in pipelines.
Gecentraliseerde facturering zonder budgetten per team belemmert de verantwoordelijkheid; maak budgetten op team- of productniveau.
Vertraagde budgetwaarschuwingen betekenen dat snelle pieken het budget kunnen overschrijden; gebruik waar mogelijk limieten en quota’s als extra laag.

Compute-efficiëntie en Prestaties

Stem resources af op workloadprofielen; automatiseer elasticiteit; reserveer of verkrijg korting op een stabiele basislast.

Rightsizing en aangepaste machinetypes
- Analyseer continu het gebruik van CPU, geheugen, schijf-IOPS en netwerk om de juiste omvang te bepalen (rightsizing). Gebruik aangepaste machinetypes om vCPU en geheugen af te stemmen op de werkelijke behoeften van de app en te voorkomen dat u betaalt voor ongebruikt geheugen.
- Let op de ‘headroom’: streef naar 60-75 procent aanhoudend CPU-gebruik en zorg voor voldoende geheugenruimte voor GC of pieken. Te agressieve rightsizing verhoogt het risico op ’throttling’ of OOM’s.
Autoscaling en levenscyclusscheduling
- Gebruik autoscaling voor managed instance groups op basis van relevante signalen (CPU, load balancer-capaciteit of aangepaste wachtrijdiepte). Configureer opwarmperiodes en ‘scale-in’-controles om ’thrashing’ te voorkomen.
- Voor omgevingen die niet 24/7 draaien, plan het starten/stoppen van VM’s, GKE-nodepools of Cloud Run min-instanties om uitgaven aan inactieve resources te vermijden. Een eenvoudige eerste stap is Cloud Scheduler die een Cloud Run-taak activeert om ’s nachts dev-instanties te stoppen.
Kortingsinstrumenten
- Committed-use discounts: verbind u voor 1-3 jaar voor stabiel gebruik dat in aanmerking komt voor commitments. Breng de omvang van de commitment in evenwicht met historisch gebruik en bedrijfsvoorspellingen; te veel committeren is geldverspilling.
- Spot VM’s: ideaal voor fouttolerante, batch- of gedistribueerde workloads. Ze kunnen op elk moment worden teruggevorderd; implementeer ‘checkpointing’ en groepen met meerdere instanties met on-demand fallbacks.
  - Voorbeeld:

undefined

Capaciteitsreserveringen: reserveer zonale of regionale capaciteit voor kritieke vloten om mislukte opschaling tijdens regionale tekorten te beperken.
- Voorbeeld:

undefined

Gebruiksstatistieken en prestatie-tuning
- Instrumenteer met Cloud Monitoring, Profiler en Trace. Meet p50/p95-latentie, CPU-steal, GC-tijd en wachtrij-backlogs. Optimaliseer ‘hot code paths’ voordat u uitschaalt.
- Wijs prestatiegevoelige workloads toe aan regio’s en zones met adequate CPU-platformen en overweeg waar nodig high-throughput persistent disks of Hyperdisk.

Faalmodi en afwegingen:

Onbegrensde autoscaling kan quota’s en kostendoelen overschrijden; verhoog quota’s vooraf, stel maximale replica’s in en gebruik voorspellende autoscaling voor bekende pieken.
Spot VM’s kunnen ‘churn’ in een deel van de vloot veroorzaken; diversifieer over zones en implementeer ‘graceful termination hooks’.
Te veel CUD’s committeren of onderbenutte reserveringen creëren verzonken kosten; evalueer commitments per kwartaal.

Kosten-prestaties van Storage, Databases en Analytics

Kies storage classes en database-capaciteitsmodellen die overeenkomen met toegangspatronen, retentie en prestatie-SLO’s.

Storage classes en lifecycle-beleid
- Gebruik Standard voor ‘hot’ data, Nearline voor maandelijkse toegang, Coldline voor kwartaaltoegang en Archive voor langdurige, zeldzame toegang. Houd data en compute in dezelfde regio om egress-kosten te vermijden.
- Pas lifecycle management toe om objecten automatisch over te zetten of te verwijderen. Let op minimale opslagduren en ophaalkosten; voorbarige overgangen van class kunnen meer kosten dan ze besparen.
- Voorbeeld van een lifecycle-beleid (verwijder ouder dan 90 dagen):

undefined

Dataoverdracht en archivering
- Toegang tussen regio’s brengt vaak egress-kosten met zich mee; plaats producenten en consumenten in dezelfde locatie. Gebruik Private Google Access en VPC-SC voor veilige, kostenbewuste toegang tot Google API’s. Vermijd voor langetermijnarchieven het frequent ophalen uit Archive om hoge ophaalkosten te voorkomen.
Database-dimensionering en prestaties
- Relationeel: dimensioneer voor de ‘memory-resident working set’, IOPS en read replicas. Schakel automatische opslagvergroting in en monitor replicatievertraging; schaal verticaal op of horizontaal via sharding wanneer de vertraging RPO/RTO in gevaar brengt.
- NoSQL/tijdreeksen: gebruik Bigtable voor high-throughput, low-latency opname met een correct ‘row key’-ontwerp om hotspots te vermijden.
BigQuery-kostenbeheersing en capaciteitsmodellen
- On-demand (per gescande TB): snel om te starten, risico op kostenpieken. Op capaciteit gebaseerde reserveringen: voorspelbare uitgaven, controle over concurrency en doorvoer. Flex commitments vangen kortetermijnpieken op.
- Optimaliseer query’s met partitionering en clustering; vereis partitiefilters om volledige tabelscans te voorkomen:

undefined

Stel een maximum aantal gefactureerde bytes per job in om de uitgaven te beperken:

undefined

Gebruik materialized views, result cache, geschatte aggregaties en vermijd SELECT * in productie. Houd storage en compute in dezelfde regio.

Faalmodi en afwegingen:

Het verplaatsen van ‘hot’ objecten naar Coldline/Archive veroorzaakt ophaalkosten en kosten voor vroegtijdige verwijdering.
BigQuery on-demand zonder controlemechanismen kan leiden tot uit de hand gelopen kosten door ongefilterde scans; dwing een maximum aan gefactureerde bytes en partitiefilters af.
Overmatig sharden van databases verhoogt de operationele complexiteit; benchmark alvorens op te splitsen.

← DevOps · Alle domeinen

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