Zo bouw je een robuuste landing zone op Google Cloud

Heb je Google Cloud als platform gekozen, dan is de volgende grote stap een stevige basis leggen. Zonder die basis kunnen ook de meest vernieuwende applicaties tegen problemen aanlopen met schaalbaarheid, beveiliging of compliance.

Zie de landing zone als de bouwtekening van je cloudomgeving. Hij geeft structuur, scheidt verantwoordelijkheden en zet vangrails neer, zodat je team snel kan werken zonder in te leveren op beveiliging of governance.

In dit artikel laten we zien hoe je een landing zone op Google Cloud ontwerpt en inricht, aan de hand van een fintechbedrijf dat betalingen veilig en efficiënt moet verwerken.

Wat is een landing zone?

Een landing zone is een startsjabloon om op Google Cloud een veilige, schaalbare en beheersbare infrastructuur op te zetten. In de kern is het een fundament. Je ontwerpt er vanaf het begin alle kritieke onderdelen systematisch mee, zoals beveiliging, netwerken, identiteitsbeheer, beleid en kostenbeheersing. Zo staat er een degelijke infrastructuur voordat je aan je applicatie begint.

Onderdelen van een landing zone op Google Cloud

De onderdelen van een landing zone zijn in een aantal categorieën in te delen:

Organisatie en projecten:

Voor elke omgeving wordt een apart Google Cloud-project aangemaakt. IAM-beleid, budgetten en facturering worden per project apart beheerd.

IAM (Identity & Access Management):

Gebruikers, serviceaccounts en rollen worden vastgelegd volgens het principe van minimale rechten (least privilege). Zo hebben ontwikkelaars alleen toegang tot de Dev-omgeving, terwijl alleen het beheerteam bij de Prod-omgeving kan.

VPC en netwerken:

Voor elke omgeving wordt een aparte VPC vastgelegd, of geïsoleerde subnetten binnen dezelfde VPC. Privétoegang tot services loopt via Private Service Access, VPN of Interconnect.

Beveiliging en compliance:

Cloud Armor: bescherming tegen DDoS-aanvallen

Secret Manager: beheer van gevoelige gegevens zoals API-sleutels, wachtwoorden en private keys

KMS (Key Management Service): beheer van cryptografische sleutels

Audit Logs & SCC (Security Command Center): herleidbaarheid en controle op compliance

CI/CD-pipeline:

Applicaties gaan automatisch van Dev → Test → Prod met Cloud Build, GitHub Actions of Jenkins.

Voor Infrastructure as Code (IaC) gaat de voorkeur uit naar Terraform of Deployment Manager.

Cloud Build → tests → Artifact Registry → deployment op Cloud Run/Kubernetes Engine

Monitoring en logging:

Cloud Monitoring en Cloud Logging: metrics en logs worden per omgeving centraal gevolgd.

Alerting: meldingen per e-mail of Slack bij kritieke fouten

Stap 1: de omgevingslagen plannen

Een van de belangrijkste principes van een landing zone is scheiding van omgevingen. Elke fase van de ontwikkeling heeft een eigen doel:

• Development (Dev): een flexibele omgeving waarin engineers experimenteren, nieuwe ideeën testen en snel werken zonder bang te zijn dat ze productie platleggen.
• Test / QA: een gecontroleerde omgeving om koppelingen te valideren, prestaties te controleren en problemen op te sporen.
• Staging (Pre-Prod): een vrijwel exacte kopie van productie, met realistische data. Dit is het laatste vangnet voor een release.
• Production: de live-omgeving waarin financiële transacties worden verwerkt, met de hoogste eisen aan beveiliging, veerkracht en uptime.

Die scheiding is geen bureaucratie maar risicobeheer. Zonder scheiding kunnen kleine fouten in development makkelijk doorwerken tot storingen of compliance-overtredingen in productie.

Stap 2: Identity and Access Management (IAM)

Beveiliging begint bij toegangsbeheer. Het principe van minimale rechten moet streng worden toegepast. Een ontwikkelaar die in Dev werkt, hoort geen rechten te hebben om live klantdata in Prod op te vragen. Ook serviceaccounts krijgen alleen de rechten die ze voor hun taak nodig hebben.

Een serviceaccount met alleen leesrechten op BigQuery kan bijvoorbeeld niet per ongeluk datasets verwijderen of aanpassen. Door IAM-beleid centraal op map- of organisatieniveau te beheren, voorkom je inconsistenties en help je compliance af te dwingen in alle projecten.

Stap 3: het netwerk (VPC) ontwerpen

De netwerkarchitectuur is de basis voor veilig en efficiënt verkeersbeheer binnen de landing zone. Voor sterke isolatie en gecontroleerde verbindingen:

Shared VPC-model: een gedeelde Virtual Private Cloud (VPC) dient als centrale netwerklaag, met gestandaardiseerde governance en consistent beleid in alle omgevingen.

Strikte scheiding van omgevingen: tussen de omgevingen (Development, Staging en Production) gelden duidelijke grenzen. De Development-omgeving kan bijvoorbeeld niet rechtstreeks communiceren met de Production-omgeving. Dat beperkt het risico op onbevoegde toegang, datalekken of onbedoelde verstoringen.

Firewallregels: de firewallregels van het netwerk volgen het principe van minimale rechten. Alleen goedgekeurde poorten, services en protocollen zijn toegestaan, zodat elke workload alleen kan communiceren met resources die daar uitdrukkelijk voor zijn vrijgegeven.

Gecontroleerde toegang tot data: ontwikkelaars in de lagere omgevingen (zoals Dev of Test) kunnen niet bij gevoelige productiesystemen. Dat verkleint de kans dat live data per ongeluk zichtbaar wordt.

Beperkingen: backendservices hebben geen directe publieke ingress en geen onbeperkte egress. Uitgaand verkeer naar externe API's van derden moet via een beveiligde proxylaag lopen, waar het centraal wordt gemonitord, gelogd en gecontroleerd. Dat versterkt de isolatie en voorkomt datalekken.

Stap 4: CI/CD, Artifact Registry en scheiding van omgevingen

Automatisering speelt een cruciale rol bij het verplaatsen van code van development naar productie. Daarin zijn twee onderdelen belangrijk:

Artifact Registry (repository voor Docker-images)

Voor alle omgevingen wordt één Artifact Registry-repository gebruikt. De scheiding tussen omgevingen loopt via een tagstrategie.

Bijvoorbeeld:

• payment-service:41-stage → getest in Staging
• Na goedkeuring wordt hetzelfde image payment-service:41-prod

Zo voorkom je het klassieke scenario van "werkt in Staging, breekt in Prod" en wordt terugdraaien eenvoudig.

CI/CD-pipeline

Zet een pipeline op met Cloud Build of GitHub Actions. Het proces verloopt meestal zo:

1. Code-commit → Docker-image wordt gebouwd.
2. Het gebouwde image wordt naar Artifact Registry gepusht (payment-service:41).
3. Automatische deployment naar de staging-omgeving.
4. Tests geslaagd → handmatige goedkeuring → de tag -prod wordt aan hetzelfde image toegevoegd.
5. Precies hetzelfde image wordt naar de productieomgeving uitgerold.

Dit proces bewaakt de kwaliteit en houdt deployments snel en betrouwbaar.

Stap 5: infrastructuur beheren met Terraform en Atlantis

Cloudresources met de hand beheren vraagt om fouten. Daarom hoort alle infrastructuur als code (Infrastructure as Code, IaC) beheerd te worden met Terraform.

Scheiding van omgevingen

Elke omgeving heeft eigen configuratiebestanden, terwijl gedeelde modules zorgen voor consistentie tussen projecten.

• environments/dev/
• environments/staging/
• environments/prod/

Terugkerende resources worden vastgelegd in gedeelde modules (modules/)

Terraform automatiseren met Atlantis

Door Terraform te koppelen aan Atlantis krijg je automatisering en governance. Atlantis voert Terraform-wijzigingen automatisch door via pull requests (PR).

• De ontwikkelaar dient de Terraform-code in door een PR te openen.
• Atlantis draait automatisch terraform plan en plaatst de uitkomst ter beoordeling.
• Na goedkeuring wordt terraform apply gestart.

Deze workflow maakt riskante handmatige commando's overbodig, zorgt dat elke wijziging door een collega wordt beoordeeld en legt duidelijk vast wie wat wanneer heeft gewijzigd.

Stap 6: observability

In fintech zijn downtime en verborgen fouten onacceptabel. Met observability weet je altijd wat er gebeurt. Daarvoor richt je het volgende in:

• Alle logs worden centraal verzameld met Cloud Logging.
• Metrics worden gevolgd met Cloud Monitoring.
• Alerts zorgen dat het team direct een melding krijgt als er iets misgaat.

De landing zone in de praktijk: een opzet met meerdere omgevingen op Google Cloud

Het diagram toont een GCP-architectuur met meerdere omgevingen voor een fintechapplicatie, met een mobiele client in Flutter en backendservices zoals betalingen en wallets.

• Verkeersstroom: verzoeken gaan vanuit de Flutter-app via HTTPS REST API's naar een publieke laag, die wordt afgehandeld door de Apigee API Gateway in een publiek subnet, en worden via een Global HTTP(S) Load Balancer gerouteerd.
• Backendservices: de load balancer verdeelt verzoeken over Cloud Run-services (Payments en Wallet) met proxy's en routeringsregels.
• Datalaag: de backends maken binnen een private VPC privé verbinding met Cloud SQL (transactiedata) en BigQuery (analyse, rapportage, ML, dashboards).
• Beveiligingsgrens: de publieke ingress wordt voor de efficiëntie gedeeld, maar is gescheiden van de private workloads, die per omgeving geïsoleerd zijn. Zo verloopt de communicatie veilig en schaalbaar, zonder dat iets rechtstreeks publiek bereikbaar is.

Waarom één project voor Apigee?

Eén gedeeld project (bijvoorbeeld fintech-apigee-shared) brengt het beheer van Apigee op één plek samen en voorkomt dubbel werk.

Belangrijkste voordelen:

• Scheiding van omgevingen: geregeld via configuraties zoals virtual hosts, omgevingen (test/acc/prod) en target proxies (payment-proxy-dev, payment-proxy-prod).
• Toegangsbeheer: API-sleutels en IP-allowlists per proxy bepalen naar welke omgeving verkeer gaat.
• Efficiëntie: minder dubbele infrastructuur, eenvoudigere updates en lagere kosten.
• Aansluiting op de landing zone: één gezamenlijke "voordeur", waarbij de proxy's de omgevingen strikt van elkaar gescheiden houden.

Waarom vier aparte projecten voor Dev, Test, Acc en Prod?

Maak vier projecten aan: fintech-dev, fintech-test, fintech-acc, fintech-prod, elk in een eigen map per omgeving binnen de landing zone.

Voordelen:

• Isolatie: voorkomt risico's tussen omgevingen, zoals datalekken of concurrentie om resources.
• Governance: facturering, quota, audit logs en IAM-beleid per omgeving apart.
• Flexibiliteit: in Dev/Test kun je experimenteren met goedkopere tiers; Acc is een spiegel van Prod voor realistische validatie; Prod borgt de compliance (bijvoorbeeld PCI-DSS).
• Netwerken: een gedeelde private VPC met subnetten per omgeving. Verkeer loopt via de gedeelde Apigee/load balancer naar de backends van de juiste omgeving.

Services beheren in elk project

• Cloud Run: deploy de gecontaineriseerde betaal- en walletservices per project. Ze schalen los van elkaar, en met revisies voer je updates veilig en zonder downtime door.
• Cloud SQL: richt instances in met private IP-adressen (bijvoorbeeld PostgreSQL). Zet in Acc/Prod HA en back-ups aan, en maak verbinding via Private Service Connect.
• IAM: ken per project rollen toe met minimale rechten. Gebruik workload identity voor veilige authenticatie tussen services.
• BigQuery: maak per project datasets aan voor analyse, ML-modellen en dashboards. Pas beveiliging op rijniveau toe om de Prod-data af te schermen.

Resources beheren met CI/CD via Terraform en andere tools

Alle resources (projecten, Apigee, VPC's, Cloud Run, Cloud SQL, IAM, BigQuery) horen als code beheerd te worden, zodat ze reproduceerbaar en controleerbaar zijn.

Aanbevolen opzet:

• Terraform als IaC: declaratieve provisioning in alle omgevingen.
• Modules: herbruikbare modules voor gedeelde resources (modules/apigee, modules/cloud-run).
• Omgevingsvariabelen: gebruik variabelen (bijvoorbeeld var.environment = "dev") voor configuratie per omgeving.
• State-beheer: sla de state per omgeving op in aparte Cloud Storage-buckets, zodat ze geïsoleerd blijven. Verwijs naar gedeelde resources met remote state data sources.
• CI/CD-integratie: combineer dit met Cloud Build, GitHub Actions of GitLab CI om workflows te automatiseren (build → test → deploy).

Apigee (gedeeld project)

• Gebruik de Terraform-provider google_apigee om organisaties, omgevingen en proxy's te beheren.
• Laat voor de deployment linting- en validatiestappen draaien (terraform validate, lint-tools voor Apigee).

Beheer de proxy's centraal en dwing de scheiding tussen omgevingen af via configuratie.

CI/CD-workflow (voorbeeld met Cloud Build)

Een typische CI/CD-pipeline kan er zo uitzien:

1. Trigger: Git-push of PR (op basis van branches: main voor prod, develop voor dev/test, staging voor acc).
2. Build: draai terraform init/plan en bouw de Docker-images.
3. Opslag van artifacts: push de gebouwde images naar Artifact Registry.
4. Deployen naar Staging: automatische deployment om te testen.
5. Goedkeuringsmoment: slagen de tests, dan zet een handmatige goedkeuring hetzelfde image door naar Prod.

Zo draait precies hetzelfde artifact dat in staging is getest ook in productie. Dat beperkt de risico's van opnieuw bouwen en maakt terugdraaien eenvoudiger.

Wat deze aanpak oplevert

Door Terraform, Apigee, Cloud Build en CI/CD-pipelines te combineren, krijg je:

• Idempotentie: elke deployment geeft hetzelfde resultaat.
• Controleerbaarheid: volledig zicht op wie wat wanneer heeft gewijzigd.
• Beveiliging: geïsoleerde omgevingen, IAM met minimale rechten en gecontroleerde ingress/egress.
• Operationele efficiëntie: minder handwerk en minder configuratiedrift.
• Schaalbaarheid: een gedeelde ingresslaag voor efficiëntie, met strikte scheiding voor de backendservices.

Conclusie

Een goed gestructureerde landing zone op Google Cloud is niet alleen relevant voor fintech. Of je nu een e-commerceplatform, een SaaS-product of een datagedreven applicatie bouwt, de principes blijven hetzelfde.

Begin je met een degelijke landing zone, dan kan je team zich richten op het leveren van functionaliteit en waarde, in plaats van zich zorgen te maken over valkuilen in de infrastructuur. Zo leg je de basis voor groei, vernieuwing en veerkracht op Google Cloud.

Weet je niet goed waar je moet beginnen? Neem gerust contact op, we bespreken je project graag.