GTM Server-Side sur AWS

Exécuter GTM Server-Side sur AWS s’applique aux organisations déjà investies dans AWS qui ne souhaitent pas maintenir un compte GCP distinct pour un conteneur de tagging. L’image Docker — gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable — se déploie sans modification sur les services de conteneurs AWS.

Le coût du compute AWS est inférieur à celui de Cloud Run, mais AWS nécessite de construire une infrastructure que Cloud Run inclut par défaut (réseau, HTTPS, scalabilité). Pour les petits déploiements, le coût total dépasse souvent Cloud Run malgré des tarifs vCPU plus bas. Pour les déploiements à grande échelle sur une infrastructure AWS existante avec des Savings Plans, l’économie peut favoriser AWS.

ECS Fargate : l’option principale

AWS ECS Fargate exécute l’image du serveur de tagging en tant que conteneurs managés sans que vous gériez directement des instances EC2. C’est l’équivalent AWS le plus proche du modèle de conteneur serverless de Cloud Run.

La différence architecturale par rapport à Cloud Run devient rapidement évidente. Là où Cloud Run gère automatiquement le réseau, HTTPS et la scalabilité, Fargate vous demande de construire :

Un VPC avec des sous-réseaux publics et privés (le serveur de tagging est dans le sous-réseau privé, accessible uniquement via le load balancer)
Un Application Load Balancer pour la terminaison HTTPS et le routage du trafic vers les tâches Fargate
Une ou plusieurs NAT Gateways pour l’accès internet sortant depuis le sous-réseau privé (le conteneur doit transmettre des événements à GA4, Meta et autres endpoints vendeurs)
Route 53 pour la gestion DNS et la validation des certificats via ACM

Aucun de ces éléments n’est optionnel. Le serveur de tagging a besoin d’un accès internet sortant (NAT Gateway), d’une terminaison HTTPS (ALB) et de DNS (Route 53). Vous ne choisissez pas si vous construisez cette infrastructure ; vous choisissez combien d’effort y investir.

Lari Haataja a publié un projet AWS CDK open source qui automatise l’ensemble de cette stack. Si vous optez pour Fargate, utiliser un projet CDK plutôt que de construire from scratch économise un temps considérable et réduit le risque de mauvaise configuration.

Configuration des tâches

Pour la tâche du serveur de tagging, une configuration de départ raisonnable :

{
  "family": "gtm-tagging-server",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "1024",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "gtm-tagging-server",
      "image": "gcr.io/cloud-tagging-10302018/gtm-cloud-image:stable",
      "portMappings": [
        {
          "containerPort": 8080,
          "protocol": "tcp"
        }
      ],
      "environment": [
        {
          "name": "CONTAINER_CONFIG",
          "value": "YOUR_GTM_CONTAINER_CONFIG_STRING"
        },
        {
          "name": "PREVIEW_SERVER_URL",
          "value": "https://preview.gtm.yourdomain.com"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/gtm-tagging-server",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "ecs"
        }
      }
    }
  ]
}

La valeur CONTAINER_CONFIG provient de GTM — c’est la chaîne encodée en base64 qui identifie votre conteneur serveur. La même chaîne que vous utiliseriez dans un déploiement Cloud Run.

Profil de coût réel

Le pricing Fargate est genuinement moins cher que Cloud Run. Une tâche always-on avec 1 vCPU et 0,5 Go coûte environ 31 $/mois. L’équivalent Cloud Run coûte environ 49 $/mois.

Mais l’infrastructure environnante érode rapidement cet avantage :

Composant	Coût mensuel
Tâche Fargate (1 vCPU, 0,5 Go, always-on)	~31 $
Application Load Balancer	~16 $
NAT Gateway (par gateway)	~32 $ + frais de transfert de données
Total minimal réaliste	~79 $+

La NAT Gateway est le coût surprise. À environ 32 $/mois par gateway plus 0,045 $/Go traité, elle dépasse souvent le coût du compute pour les petits déploiements. Un serveur de tagging qui transmet des événements à 3-4 endpoints vendeurs génère un volume de données sortantes non négligeable.

Par comparaison, Cloud Run à la même configuration coûte 49 à 90 $/mois au total — sans ALB, sans NAT Gateway, avec HTTPS et scalabilité inclus.

Là où AWS l’emporte

L’économie bascule en faveur d’AWS à deux points :

Réutilisation de l’infrastructure existante. Si vous disposez déjà d’un VPC, d’un ALB et de NAT Gateways pour d’autres workloads, ajouter un service Fargate à l’infrastructure existante n’implique que des coûts de compute. Le plancher de 79 $+ ne s’applique que si vous construisez une infrastructure dédiée.

Tâches Graviton2/ARM. Fargate prend en charge les conteneurs ARM64 (construire l’image GTM pour ARM nécessite un build multi-stage ou une cross-compilation). Les tâches Fargate ARM Graviton2 sont environ 20 % moins chères que x86 à allocation de ressources équivalente.

Savings Plans. Les AWS Compute Savings Plans offrent jusqu’à 52 % de réduction sur les tarifs à la demande avec des engagements de 1 ou 3 ans. Pour les organisations ayant des engagements AWS significatifs, un serveur de tagging s’intègre dans la couverture des Savings Plans existants. Les remises pour usage engagé de Cloud Run existent mais sont généralement moins agressives.

Pour les sites à fort trafic traitant des dizaines de millions d’événements par mois, la remise Savings Plan sur le compute Fargate peut significativement réduire les coûts par rapport à Cloud Run — surtout si les tâches ARM sont viables.

App Runner : plus simple mais plus cher

AWS App Runner est l’équivalent AWS le plus proche de l’expérience développeur de Cloud Run. Il est entièrement managé, avec auto-scaling et HTTPS par défaut. Vous le pointez vers l’image Docker et il tourne. Pas de configuration VPC, pas d’ALB, pas de NAT Gateway.

Le problème : App Runner coûte environ 1,5 à 2 fois plus cher que Fargate pour les workloads continus. Pour un serveur de tagging qui doit être always-on (pour éviter les événements perdus lors des cold starts), cette prime s’accumule.

App Runner est pertinent pour les équipes qui souhaitent une évaluation rapide sans investissement en infrastructure. Pour les déploiements en production où le coût compte, Fargate avec une infrastructure existante est plus économique.

Lambda ne fonctionne pas

Lambda est souvent le premier réflexe pour « exécuter quelque chose de serverless sur AWS ». Pour le serveur de tagging GTM, ça ne fonctionnera pas.

L’image du serveur de tagging GTM exécute un serveur HTTP Node.js persistant qui se bind sur un port et écoute les connexions. Le modèle d’exécution de Lambda est conçu pour des invocations de fonctions de courte durée — une requête arrive, la fonction s’exécute, elle se termine. Lambda ne prend pas en charge les serveurs HTTP de longue durée.

Il existe des contournements comme Lambda Web Adapter ou des runtimes personnalisés qui adaptent les serveurs HTTP au modèle d’invocation de Lambda, mais ils introduisent des problèmes de fiabilité et de performance pour un workload qui exige une faible latence constante. N’empruntez pas cette voie.

Si vous avez besoin d’une exécution serverless sur AWS sans la surcharge d’infrastructure Fargate, App Runner est le bon choix.

Multi-région sur AWS

Le déploiement multi-région GTM Server-Side sur AWS nécessite une infrastructure nettement plus importante que sur GCP. Le pattern typique :

Déployer des services Fargate dans chaque région cible (par exemple us-east-1 et eu-west-1)
Créer des ALB dans chaque région
Utiliser AWS Global Accelerator ou le routage basé sur la latence Route 53 pour diriger les utilisateurs vers la région la plus proche
Si vous utilisez Global Accelerator, configurer des groupes d’endpoints pointant vers chaque ALB régional

Chaque stack régionale nécessite son propre VPC, ALB, NAT Gateway et service Fargate. Le coût d’infrastructure se cumule par région.

Pour les déploiements multi-régions sans infrastructure AWS multi-région existante, Cloud Run derrière un Global External Application Load Balancer ou un provider managé comme Stape est presque toujours plus rentable.

Le point de décision

Choisissez l’hébergement AWS quand :

Votre organisation fonctionne principalement sur AWS et des raisons politiques ou contractuelles empêchent de maintenir un compte GCP distinct
Vous traitez un volume suffisamment élevé pour que les remises Savings Plans rendent Fargate moins cher que Cloud Run
Vous disposez déjà d’une infrastructure VPC, ALB et NAT Gateway pour d’autres workloads

Acceptez Cloud Run ou un provider managé quand :

Vous démarrez sans infrastructure AWS existante
Votre volume de trafic ne justifie pas les Savings Plans
Vous voulez du multi-région sans construire une infrastructure AWS multi-région

L’image du serveur de tagging GTM est cloud-agnostique. Migrer entre plateformes d’hébergement signifie redéployer le même conteneur avec les mêmes variables d’environnement et mettre à jour le DNS. La décision n’est pas permanente.