The tagging server's cost is growing faster than the traffic it serves

The bill is not tracking your traffic because it never did. A tagging server is billed on inbound requests multiplied by what each one triggers, and the multiplier is the part that changes without anyone deciding to change it. Adding a sixth destination to the container turns one inbound hit into seven units of work — the transform, plus six outbound calls, each with its own connection, latency and retry behaviour — for every visitor at once. Sessions stay flat, compute does not.

This is about your own cloud spend and your own egress, and the numbers below are illustrative shapes rather than anybody's real invoice. The point is the arithmetic: once you can state your multiplier, the four levers that move it are obvious and can be ordered by what each one costs you in lost measurement.

Three numbers explain the whole bill

Before touching the container, get these three from your own logs. Together they decompose the cost into a volume term, a fan-out term and an efficiency term, and every fix is aimed at exactly one of them.

Five things inflating the multiplier

Fan-out leads because it is the only driver that is multiplicative. Every other row adds requests; this one changes what each request is worth in compute. It is also the one that grows by accident: destinations get added one at a time by people solving a real problem, and no single addition ever looks like the moment the curve turned.

Health checks, previews and crawlers bill exactly like customers

This is the fastest saving available and the most often overlooked, because none of this traffic appears in a tag report. A load balancer probing the endpoint every 2 seconds generates 43,200 requests a day, and most deployments run more than one checker across more than one region. Container preview and debug sessions can produce more requests per minute than a busy customer. Crawlers execute page scripts, and with a first-party endpoint they reach your infrastructure exactly like everyone else.

• Answer probes with an HTTP 204 on a dedicated path that terminates before any transform, consent evaluation or destination logic runs. An hour of work, and it removes a permanent baseline.
• Make preview and debug traffic identifiable, then exclude it from destination sending rather than only from reports. A preview session that still fans out to 6 vendors costs what a real one costs.
• Drop crawlers at the edge on User-Agent plus network — an ASN or CIDR match is harder to spoof than a header alone — so the request is refused before it becomes compute. Log the count, so nobody has to guess later how much was dropped.
• Watch the client identifier as you filter. Any request that also carries the first-party identifier write is not free to discard — the churn it creates is the subject of returning visitors arriving as new ones.

Cold starts: paying twice for capacity you keep discarding

Autoscaling to zero looks thrifty and often is not. A container that starts, serves a handful of requests and stops has spent most of its billed life initialising, and the requests that arrive during that window pay for it in latency — which matters here because a slow response on a conversion hit is a lost conversion, not a slow page. The counter-intuitive result is that a small floor of always-warm instances usually reduces total billed time on any endpoint with steady low-volume traffic.

Set the floor from your own hourly request distribution rather than from a default. If the quietest hour still sees continuous traffic, one warm instance is almost certainly cheaper than repeated starts. If traffic genuinely stops overnight, scaling to zero is correct and the cold starts are the price of that being true.

A tagging endpoint that scales to zero has not saved you the request. It has moved the cost from compute into latency, on exactly the requests you least want to be slow.

Four levers, in the order that keeps every event you need

1. Trim at source. Stop sending client events nobody queries. This is the only lever that reduces the inbound term and the fan-out term at once, and it is free — the work is deciding which events are load-bearing, not writing code. Protect the landing hit that captures the click identifier, because losing that one is the failure traced in the click identifier missing by the time the form submits.
2. Filter at the edge. Refuse probes, previews, bots and malformed payloads before they become compute. Second because it removes work you should not have accepted, but it does not reduce anything a real visitor generates.
3. Cut the fan-out. Send each destination only the events it actually consumes, rather than every event to every destination. Most containers broadcast by default, and most destinations use a fraction of what they receive. Which fields each destination genuinely needs is the subject of assembling a server-sent conversion a platform will match.
4. Right-size the runtime. Set a minimum instance count from the hourly distribution, size memory to the observed working set rather than to a default, and check whether outbound calls reuse a pooled connection or perform a fresh TLS handshake each time — repeated 6 times per request, that handshake is pure overhead. Last, because tuning a runtime that is doing unnecessary work only makes the waste more efficient.

What to watch afterwards, so the curve stays flat

• Publish cost per thousand events beside the absolute figure. The absolute number rises with a good quarter; the ratio only rises when something got worse, and it is the number to alert on.
• Alert on outbound calls per inbound request. It is the multiplier, it changes when someone adds a destination, and a step change in it is the earliest warning you will get.
• Make adding a destination a reviewed change with a stated event subset and an owner, not a container edit. The same admission discipline applies to anything third parties inject into your pages — the checks in pre-flight checks before accepting a creative tag exist for exactly this reason.
• Give the operators a view they can read without a warehouse query. A small dashboard showing requests, fan-out and non-customer share by hour is the sort of internal tooling that pays for itself the first time a bot wave arrives on a weekend.

The honest summary is that a tagging server is not expensive; broadcasting every event to every vendor is expensive, and a server-side container makes that habit visible for the first time by putting a bill against it. Fix the multiplier and the same architecture gets cheaper as it gets more useful. The rest of this silo sits under tracking, consent and event pipelines, part of our marketing and advertising practice.

• server-side tagging
• infrastructure
• event pipelines
• diagnostics