← Retour à tous les articles Tracking Server-Side & CAPI Réservé aux clients 13 novembre 2026 ⏱ 15 min de lecture

Héberger le sGTM sur AWS Fargate ou Google Cloud Run : coûts et performance

Le choix du fournisseur cloud pour le conteneur sGTM influe sur la latence et sur le budget IT. Nous analysons en détail le duel entre AWS Fargate et Google Cloud Run.

Ingénierie de performance Random Spécialistes du trafic payant & du suivi côté serveur

13 novembre 2026

Héberger le sGTM sur AWS Fargate ou Google Cloud Run : coûts et performance

DIAGNOSTIC TECHNIQUE · OPÉRATIONS > BRL 100K/MOIS 15 min de lecture

Scénario opérationnel : Les équipes technologiques font face à des coûts de calcul cloud imprévisibles ou à des pannes du conteneur serveur lors des pics de trafic de campagnes promotionnelles.

Cause racine technique : Mauvais dimensionnement des conteneurs et méconnaissance des particularités de facturation du trafic sortant (egress) et du cold start entre AWS et GCP.

Directive d’ingénierie : Décision d’architecture fondée sur le profil de l’entreprise : Cloud Run pour des déploiements rapides et une scalabilité automatique sans serveur ; AWS Fargate pour les opérations dont l’écosystème est déjà chez Amazon.

La décision d’infrastructure pour le Server-Side GTM

Mettre en place un conteneur Server-Side de Google Tag Manager (sGTM) exige de provisionner des serveurs dédiés dans le cloud pour traiter le trafic des requêtes analytiques. Si Google propose une configuration par défaut automatisée sur Google Cloud Platform (GCP), la plupart des entreprises de taille moyenne ou grande disposent de contrats et d’infrastructures d’entreprise hébergés chez Amazon Web Services (AWS).

Le choix entre Google Cloud Run et AWS Fargate implique des arbitrages techniques sur quatre dimensions critiques : temps de réponse (latence réseau), tolérance aux pics de trafic, complexité de la maintenance opérationnelle et coût financier mensuel.

Architecture 1 : Google Cloud Run (standard natif de Google)

Cloud Run est la plateforme de calcul serverless de Google, qui exécute les conteneurs directement sur l’infrastructure mondiale de l’entreprise. Ses principales caractéristiques d’ingénierie sont les suivantes :

Déploiement automatisé en 1 clic : intégration native à l’interface de Google Tag Manager, qui permet de lancer des instances de test et de production sans écrire de manifestes d’infrastructure as code (IaC).
Concurrence par conteneur : une seule instance Cloud Run peut traiter jusqu’à 80 requêtes simultanées par défaut, ce qui réduit le nombre total de conteneurs actifs nécessaires.
Scale to Zero : capacité d’éteindre les instances la nuit s’il n’y a pas de trafic, même si, en production, il est recommandé de garder au minimum 2 instances toujours actives pour éviter la latence de démarrage à froid (cold start).

Architecture 2 : AWS Fargate (environnement d’entreprise Amazon)

AWS Fargate permet d’exécuter des conteneurs Docker dans Amazon ECS (Elastic Container Service) sans avoir à provisionner ni gérer d’instances virtuelles EC2 :

Intégration au réseau interne AWS : idéal pour les organisations dont les serveurs d’application, les bases de données et les chaînes de CI/CD résident déjà sur AWS, ce qui garde tout le trafic dans le même VPC (Virtual Private Cloud).
Stabilité thermique du processeur : les instances Fargate restent actives en continu avec une allocation dédiée de mémoire et de vCPU, ce qui élimine totalement les variations de cold start.
Nécessité d’un répartiteur (ALB) : exige la configuration d’un Application Load Balancer devant les instances pour distribuer les connexions et gérer les certificats SSL.

Google Cloud Run

Déploiement simplifié, natif dans GTM
Facturation à la fraction de seconde et à la concurrence
Scalabilité élastique ultra rapide
Coût estimé : 40 à 110 dollars par mois pour un trafic moyen

AWS Fargate (ECS)

Intégration totale au VPC et à la sécurité d’entreprise
Performances stables, sans aucun cold start
Exige des compétences DevOps et la configuration d’un ALB
Coût estimé : 70 à 160 dollars par mois avec Load Balancer

Questions fréquentes sur l’infrastructure sGTM

Laquelle des deux options offre la plus faible latence au Brésil ?

Les deux disposent de régions de données à São Paulo (southamerica-east1 sur GCP et sa-east-1 sur AWS). Lorsqu’elles sont configurées sur la région brésilienne, la latence de réponse pour les utilisateurs locaux reste inférieure à 30 millisecondes.

Puis-je faire tourner le sGTM sur des serveurs VPS ordinaires (comme DigitalOcean ou Hetzner) ?

Techniquement, il est possible de faire tourner l’image Docker du sGTM sur n’importe quel serveur Linux. Mais on perd la montée en charge élastique automatique pendant les pics de trafic des grandes campagnes, ce qui exige une surveillance manuelle constante par un administrateur système.

Vous avez besoin d’un accompagnement spécialisé pour provisionner votre conteneur sGTM ?

L’équipe d’ingénierie de Random Marketing conçoit et met en place des infrastructures cloud résilientes pour les grands annonceurs.

Je veux engager Random Marketing pour mon entreprise ↗

DOCUMENT RÉSERVÉ · RÉSERVÉ AUX CLIENTS

Accès restreint aux clients de l’accompagnement

Les modèles d’architecture, listes de vérification, scripts d’intégration et chaînes opérationnelles de ce dossier sont réservés aux entreprises accompagnées par Random Marketing.

✓ Liste de vérification technique d’implémentation auditée

✓ Modèles d’architecture et de paramétrage

✓ Gouvernance des données et suivi par un ingénieur

Comment devenir client ?

Accompagnement pour les opérations dont l’investissement mensuel en médias est d’au moins BRL 100k.

RIGUEUR TECHNIQUE & SOURCES PRIMAIRES

Documentation officielle & références d’ingénierie

Directives d’architecture, spécifications d’API et documentation technique officielle consultées pour appuyer ce dossier :

Google Cloud Cloud Run Pricing and Concurrency Architecture Modèle de facturation à la milliseconde de CPU allouée et concurrence par conteneur.

Amazon Web Services AWS Fargate Serverless Compute for Containers Spécification d’instances conteneurisées sans gestion des serveurs EC2 sous-jacents.

Mots-clés d’indexation : #sgtm aws fargate #sgtm google cloud run #infrastructure cloud sgtm #coût serveur sgtm #performance server-side tagging