Cloud Run: Cost Savings for Serverside Google Tag Manager

The serverside Google Tag Manager (sGTM) usually runs on cloud infrastructure such as Cloud Run or App Engine. The cost of running it is made up of two main parts:

• Cloud Run instances & requests: configuration & utilization of the Cloud Run services
• Cloud Logging: logs for requests & standard output (stdout)

Because services like Cloud Run are serverless, they scale up to multiple instances as needed to handle all incoming requests. Both the minimum and maximum number of instances can be adjusted in the YAML tab:

spec:
  template:
    metadata:
      name: server-side-tagging-00001-gic
      annotations:
        run.googleapis.com/client-name: cloud-console
        autoscaling.knative.dev/minScale: '2'
        autoscaling.knative.dev/maxScale: '10'

Heads up: setting a minimum number of instances results in permanent cost, even when no requests are being processed.

By default the sGTM Docker image does not set a minimum number of instances. Usually it doesn’t make much sense to add one after the fact. Exceptions prove the rule.

Cloud Logging

Cloud Logging is the log management product on the Google Cloud Platform and covers Cloud Run as well as other services like App Engine or BigQuery. By default, all requests and standard outputs are logged. For smaller websites this doesn’t really matter, but for larger platforms the logs can quickly turn into a major cost driver for running the serverside Google Tag Manager.

Cloud Run log types — Requests, Stdout

To prevent that, it makes sense to exclude logs that aren’t needed. For this you can use Logs Exclusions. Logs that are excluded this way don’t generate cost, but they are also no longer available for debugging when something goes wrong.

Logs Exclusion

Cloud Logging works with sinks, which are essentially containers in which logs are collected. The default sink is _Default. We can attach a Logs Exclusion here to stop recording Cloud Run logs.

Before activating the filter, it is highly recommended to test the filter rules first.

The filter shown above, which Google recommends, excludes all requests from Cloud Run regardless of the severity of the log. What would remain — depending on whether you write an inclusion or an exclusion filter — are either the stdout logs (inclusion) or everything that is not a stdout log (exclusion).

In my experience it’s easier to determine what to filter out — that is, write a rule that matches the logs to be excluded. They’re also easier to test in the Logs Explorer.

A filter rule to exclude all Cloud Run logs that are not of type DEFAULT or INFO could look like this:

resource.type="cloud_run_revision" AND
severity=DEFAULT OR severity=INFO

This can then be added in the Logs Router on the _Default sink as a Logs Exclusion filter.

Cloud Run Logs Exclusion Filter — _Default Sink

Committed Use Discounts

GCP offers the option to commit to resources for a predefined period of time. App Engine doesn’t support this, but for fully managed Cloud Run services you can save 17% with a one-year commitment.

Committed Use Discounts — Cloud Run (fully managed)

In my tests, this discount was fixed at 17% and didn’t change for lower or higher commitments. Spot checks across regions also showed no difference in the discount.

Conclusion

Committed Use Discounts, alongside filtering Cloud Logs, are a sensible way to reduce the cost of running a sGTM. With a minimum term of one year, the commitment is also manageable. Caveat: even if you don’t fully utilize the reserved resources, you still have to pay for them. Before purchasing a CUD it makes sense to monitor the sGTM’s utilization for a while and then buy an appropriately sized number of runtime hours.