Statisch IP-adres voor uitgaand sGTM-verkeer: zo configureer je het in Google Cloud
Sommige vendoren vereisen dat je het IP-adres van inkomende verzoeken op een allowlist zet. Voor een server-side GTM-container op Cloud Run is dat lastig: uitgaand verkeer gebruikt standaard een grote, wisselende pool van Google-IP-adressen. Via een combinatie van een Virtual Private Cloud, een Serverless VPC Connector en een Cloud NAT-gateway kun je alle uitgaande verzoeken van een specifieke Cloud Run-instantie aan één vast extern IP-adres koppelen. De opzet is complex en brengt aanzienlijke kosten met zich mee — weeg dat zorgvuldig af voordat je begint.
Waarom een statisch IP-adres nodig kan zijn
Standaard verzendt een sGTM-container op Cloud Run uitgaande verzoeken vanuit een enorm en veranderlijk pool van Google-IP-adressen. Voor de meeste vendor-integraties is dat geen enkel probleem. Maar sommige partijen — denk aan bepaalde data-warehouses, CRM-systemen of advertentieplatformen — eisen dat je het IP-adres van inkomende API-verzoeken van tevoren opgeeft en allowlist. Zonder statisch IP-adres valt dat simpelweg niet te garanderen.
Hoe de architectuur werkt
De oplossing combineert vier Google Cloud-componenten in één regio. Een Serverless VPC Connector stuurt het uitgaande verkeer van een Cloud Run-service door een Virtual Private Cloud in plaats van rechtstreeks naar het publieke internet. Een Cloud NAT-gateway vertaalt het interne VPC-adres naar een vast, extern IP-adres dat je zelf hebt gereserveerd. Belangrijk detail: alleen verkeer dat via dit specifieke VPC-subnetwork loopt, krijgt het statische IP. Overig sGTM-verkeer blijft de reguliere adrespool gebruiken. Dat is ook de reden waarom je een aparte Cloud Run-instantie aanmaakt voor dit verkeer, in plaats van de bestaande server aan te passen.
De zeven stappen op hoofdlijnen
Stap 1 is het reserveren van een VPC-subnetwork met een IPv4-range die eindigt op /28 — dat is verplicht voor de Serverless VPC Connector. Kies één regio voor alle componenten in deze pipeline; een multi-region opzet is aanzienlijk complexer en duurder. Stap 2 is het aanmaken van de Serverless VPC Connector in diezelfde regio, gekoppeld aan het subnetwork uit stap 1. Let op: de connector draait minimaal op twee VM-instanties, wat doorlopende kosten genereert. Stap 3 is het reserveren van een statisch extern IP-adres van het type Regional in dezelfde regio. Dit is het adres dat je aan je vendor doorgeeft voor de allowlist. Stap 4 is het aanmaken van een Cloud NAT-gateway met een nieuwe Cloud Router. Stel de bron in op Custom, selecteer je eigen subnetwork, en koppel het gereserveerde statische IP-adres als Manual NAT-adres. Stap 5 is het aanmaken van een nieuwe Cloud Run-service door een bestaande tagging-server te kopiëren. Stel in de netwerkinstellingen in dat al het uitgaand verkeer via de VPC loopt met de Serverless VPC Connector. Direct VPC Access ondersteunt op dit moment geen Cloud NAT en is daarmee geen bruikbaar alternatief. Stap 6 is het aanpassen van de load balancer. Maak een nieuwe backend service aan die gekoppeld is aan de nieuwe Cloud Run-service via een Serverless Network Endpoint Group. Voeg vervolgens een routing rule toe — op basis van een URL-pad of query-parameter — zodat alleen het relevante vendorverkeer naar deze backend wordt gestuurd. Overig verkeer blijft naar de bestaande backend gaan. Stap 7 is testen via de Preview-modus van de server-container. Controleer of verzoeken naar het gereserveerde pad het statische IP-adres tonen en of overige verzoeken dat juist niet doen. Een optionele custom request header in de backend service maakt het eenvoudiger om in Preview te verifiëren via welke route een verzoek binnenkomt.
Kosten en beperkingen: weeg dit af
De Serverless VPC Connector is de grootste kostenpost: je betaalt altijd voor minimaal twee draaiende VM-instanties, ongeacht het verkeersvolume. Daar komen netwerkkosten voor egress bovenop. Een goedkopere optie — Cloud Run Direct VPC Access — ondersteunt vooralsnog geen Cloud NAT en is daarmee geen werkend alternatief. Zodra Direct VPC Access uit de preview-fase komt en Cloud NAT ondersteunt, vervalt de noodzaak voor de Serverless VPC Connector en dalen de kosten aanzienlijk. Tot die tijd is de beschreven aanpak de enige werkende route.
Wat betekent dit voor jouw sGTM-setup
Controleer eerst of een vendor daadwerkelijk IP-allowlisting vereist — veel integraties werken prima zonder. Is dat wel het geval, zorg dan dat je alle componenten (subnetwork, VPC Connector, Cloud NAT, Cloud Run-service, load balancer-backend en routing rule) in dezelfde regio configureert. Stel een multi-region variant pas in nadat je de single-region pipeline volledig werkend hebt. Houd de kosten van de VPC Connector actief in de gaten via Cloud Billing en vergelijk die met de waarde van de vendor-integratie. Voeg tijdens het testen een custom request header toe aan de backend service zodat je in sGTM Preview Mode direct kunt zien of een verzoek via de statische IP-pipeline loopt.