AD2MartechGet in touch
Programmatic

Set Up Server-Side GTM on AWS to Cut Cloud Run Costs

September 23, 2026

Deploying Server-Side Google Tag Manager (sGTM) on AWS ECS Fargate instead of Google Cloud Run allows you to run high-volume tracking setups for a fraction of the cost. By migrating from GCP to AWS, you bypass the aggressive network egress fees and rigid "always-on" CPU allocation pricing that drive up Cloud Run bills under heavy traffic. This architectural shift keeps your event-driven data pipelines highly available while giving you granular control over compute provisioning and data transfer costs.

Key Takeaways

  • Significant Cost Reductions: Hosting sGTM on AWS ECS Fargate typically costs between $40 and $80 per month for up to 50 million requests, compared to $150 to $350+ on Google Cloud Run.
  • Elimination of the NAT Gateway Trap: Placing Fargate tasks in a public subnet with restricted security groups avoids costly NAT Gateway processing fees ($0.045/GB) while securing the container.
  • Configurable Health Checks: Using the /healthz path instead of the root path / prevents Application Load Balancers (ALBs) from falsely marking sGTM tasks as unhealthy and continuously restarting them.
  • No Feature Loss: The official Google sGTM Docker image runs identically on AWS, maintaining 100% compatibility with GA4, Google Ads, and Meta Conversions API.

The Cloud Run Cost Trap for High-Volume Advertisers

Google Cloud Platform (GCP) makes provisioning sGTM incredibly easy. With a single click inside the Google Tag Manager interface, you can deploy a Cloud Run environment. However, this convenience comes with a steep financial trade-off once your site scales past a few hundred thousand sessions per month.

Cloud Run pricing is based on vCPU-seconds, memory-seconds, request count, and network egress. To prevent latency spikes and cold starts—which delay event delivery and degrade tracking accuracy—you must configure minimum instances. Setting minimum instances means you pay for idle CPU and memory 24/7.

The real budget killer, however, is network egress. Every event sent to your sGTM container (such as page views, scroll depths, and custom events) must be processed and forwarded to third-party endpoints like Meta, TikTok, and Google Analytics. GCP charges standard internet egress rates on all outbound traffic leaving the container. When configuring high-volume event streams, such as those described in our Server-Side GTM Meta Conversions API guide, these outbound data transfers compound quickly. By migrating to AWS, you gain access to more flexible routing, cheaper compute options, and lower-cost data transfer paths.

The AWS Target Architecture for sGTM

To run sGTM on AWS efficiently, you need a robust, containerized architecture. The system relies on four core AWS components:

  1. AWS Certificate Manager (ACM) & Route 53: Used to provision a free SSL certificate and manage DNS routing for your custom tracking subdomain (e.g., metrics.yourdomain.com).
  2. Application Load Balancer (ALB): Terminates the SSL connection at the edge, routes incoming traffic, and handles health checks across your container instances.
  3. AWS ECS on Fargate: Runs the official Google sGTM Docker image (gcr.io/cloud-tag-manager/docker-image:latest) as serverless container tasks. Fargate eliminates the need to manage EC2 operating systems while providing granular CPU and memory allocation.
  4. Security Groups: Acts as a virtual firewall, ensuring that the ECS container instances only accept traffic originating from the ALB on port 8080.

Using AWS to host your tracking endpoint also helps stabilize your data layer. For instance, when resolving UTM source undefined in GA4 via sGTM, having a reliable, low-latency AWS container ensures HTTP headers and query parameters are consistently parsed before write-backs occur.

Step-by-Step AWS Setup Guide

Step 1: Extract Your Container Configuration String

Before launching anything on AWS, you need your unique sGTM configuration string. Navigate to your Google Tag Manager Server container. Click Admin > Container Settings > Set up server-side container. Select Manually provision tagging server and copy the long, base64-encoded string listed under Container Config. Keep this secure; you will pass it as an environment variable to your AWS containers.

Step 2: Provision Network and Security Groups

To ensure high availability, set up your resources across at least two Availability Zones (AZs) within your target AWS Region:

  • Create a Virtual Private Cloud (VPC) with at least two public subnets.
  • Create an ALB Security Group that allows inbound HTTP (port 80) and HTTPS (port 443) traffic from 0.0.0.0/0.
  • Create an ECS Security Group. Configure its inbound rules to allow TCP traffic on port 8080, but restrict the source to the ALB Security Group. This prevents direct, unauthenticated access to your container tasks.

Step 3: Define the ECS Task Definition

Navigate to Amazon ECS and create a new Task Definition. Select Fargate as the launch type. Configure the task size to use 0.25 vCPU and 0.5 GB RAM. This is the smallest allocation available and is highly capable of handling hundreds of requests per second per task. Under container definitions, add a new container:

  • Container Name: sgtm-server
  • Image URI: gcr.io/cloud-tag-manager/docker-image:latest
  • Port Mappings: Container Port: 8080, Protocol: TCP

Scroll down to the Environment Variables section and add the following keys:

  • CONTAINER_CONFIG: Paste your base64 configuration string here.
  • RUN_AS_PREVIEW_SERVER: Set this to false. (For debugging setups, you can deploy a separate ECS service where this is set to true).
  • PORT: Set to 8080.

Step 4: Configure the Application Load Balancer and Target Group

Create a Target Group with the target type set to IP addresses. Set the protocol to HTTP and the port to 8080. Under the Health Checks configuration, expand the advanced settings. Change the default Health Check Path from / to /healthz.

This path adjustment is critical. The official Google sGTM container is programmed to return an HTTP 200 status code on the /healthz endpoint to signal that the engine is healthy. If you leave the path as the default root /, the container may return a 400 or 404 status code, causing the ALB to assume the container is dead. This results in an endless loop of task termination and creation.

Next, create an Application Load Balancer. Attach it to your public subnets and assign the ALB Security Group you created in Step 2. Add an HTTPS listener on port 443, configure it to use your ACM SSL certificate, and route the traffic directly to your newly created Target Group.

Step 5: Run the ECS Service

Go to your ECS Cluster and create a new Service. Select the Fargate launch type and reference the Task Definition you created in Step 3. Set the desired number of tasks to 2 to ensure multi-AZ redundancy. Under network configuration, select your VPC and public subnets. Enable the auto-assign public IP setting.

Associate the service with your Application Load Balancer, selecting the target group you configured. Once completed, AWS will spin up your containers and register their private IPs with the ALB target group. Within a few minutes, the health checks should show as healthy.

Advanced Cost-Saving Adjustments on AWS

Simply moving to AWS Fargate yields immediate savings, but you can optimize further to minimize your monthly cloud bill.

Bypassing the NAT Gateway Data Processing Fee

Standard architectural patterns dictate placing ECS tasks in private subnets and routing outbound traffic through a NAT Gateway. However, AWS NAT Gateways charge roughly $0.045 per gigabyte of data processed, plus a base hourly rate of around $32 per month. For a high-traffic tracking server that constantly forwards payloads to external ad platforms, NAT Gateway processing fees can easily eclipse the cost of your actual compute tasks.

To eliminate this fee entirely, place your sGTM Fargate tasks in your public subnets with public IPs assigned, and lock down the ECS Security Group. Ensure the security group only permits inbound traffic on port 8080 from the ALB. Outbound traffic will flow directly to the internet via the VPC's Internet Gateway, which does not charge processing fees, saving you significant overhead.

Implementing CloudFront Caching

A large portion of the requests hitting your sGTM endpoint are simple requests for client-side JavaScript libraries, such as gtm.js or gtag.js. If every request for these files hits your Fargate containers, you pay for container compute cycles and ALB processing units (LCUs).

Placing an Amazon CloudFront distribution in front of your ALB allows you to cache these static assets at edge locations worldwide. Create a CloudFront behavior targeting /gtm.js and /gtag.js, and set a cache policy to keep them cached for up to 24 hours. Keep other paths, like /g/collect or custom write-back endpoints, configured to pass directly through to the origin without caching. This optimization is highly effective when fixing Consent Mode v2 signal issues, ensuring that consent states are instantly processed without container bottleneck delays.

Performance and Metric Verification

After your Route 53 record points your tracking subdomain to the ALB, you must verify the infrastructure. Open Google Tag Manager, enter Preview Mode, and point your client-side container to your new AWS tracking domain.

In the AWS Console, monitor your CloudWatch metrics. Pay close attention to the ALB's TargetResponseTime. It should consistently hover below 30 milliseconds. Check the ECS task metrics to ensure CPU utilization remains below 25% under normal load. If utilization regularly spikes above 80%, update your Service to increase the task count, or scale the Task Definition to 0.5 vCPU.

Frequently Asked Questions

Why is GCP Cloud Run so expensive for server-side GTM?

GCP Cloud Run defaults to dynamic scaling, which often requires minimum instances to prevent cold starts that drop tracking events. Additionally, Google Cloud's network egress rates are higher than alternative cloud providers, causing bills to scale rapidly under heavy tracking volumes.

Do I lose access to GTM Preview Mode when hosting on AWS?

No. By routing traffic through the ALB to your sGTM tasks, Preview Mode works perfectly. If you want to isolate preview traffic, you can deploy a secondary ECS service with the environment variable RUN_AS_PREVIEW_SERVER set to true and route /preview paths to it.

How do I update the sGTM container image on AWS?

Google periodically releases updates to the official sGTM Docker image. To apply these updates, you can periodically force a new deployment of your ECS Service. The service will pull the latest version of the image from gcr.io and perform a rolling update without downtime.

Can I run AWS ECS tasks on Spot Instances for sGTM?

While Spot Instances offer up to 90% savings, they can be terminated by AWS with a two-minute warning. For production tag management where data loss is unacceptable, it is best to use On-Demand Fargate instances. The low cost of a 0.25 vCPU task makes the risk of Spot interruption unnecessary.