サーバーサイドGTMはAWS・Azureでも動くのか｜自動プロビジョニングとの違い｜未経験から100日後にGTMのプロになる話【Day 95】

BigQueryとの連携はここまで何度も扱ってきたので（Day15・43・62・80・87・94）、今日は「AWS」という単語が出てきたことに関連して、サーバーサイドGTMは他のクラウドでも動くのか、という点を整理します。

「自動プロビジョニング」はGoogle Cloud限定

Day29で扱ったサーバーサイドGTMの導入方法――GTM管理画面の「自動プロビジョニング」ボタンを押すだけでCloud Run上に構築される方式――は、Google Cloud専用の機能です。AWSやAzure向けに同じボタンで自動構築できるわけではありません。

他クラウドでの手動デプロイという選択肢

サーバーサイドGTMの実体は、Node.jsベースのコンテナイメージとして配布されているため、技術的にはAWSのECS/Fargateや、Azureのコンテナサービス上に手動でデプロイすることも可能です。ただしこの場合、Day29で説明した「自動プロビジョニング」の手軽さは失われ、コンテナのビルド・デプロイ・スケーリング設定・監視まで、通常のクラウドインフラ構築と同じ作業を自前で行う必要があります。すでに社内のインフラがAWSやAzureに統一されており、Google Cloudを新たに使うこと自体が組織的に難しい、という制約がある場合にのみ検討する価値がある選択肢です。

特別な理由がなければGoogle Cloudのままにする

Googleが提供するサーバーサイドGTMは、そもそもGoogle Cloud上での稼働を前提に開発・保守されているため、自動プロビジョニングやGTM側の新機能（Day69のトランスフォーメーションなど）も、まずGoogle Cloud環境を想定して提供されます。「マルチクラウド戦略だから」という理由だけでAWSに無理に載せ替えると、保守の手間が増えるだけで得るものが少ないことが多いです。既存インフラの都合がない限り、素直にGoogle Cloudの自動プロビジョニングを使うのが現実的です。

今日のまとめ

サーバーサイドGTMを他クラウドで動かすこと自体は技術的に不可能ではありませんが、自動化の恩恵を失ってでも移行する明確な理由がなければ、Google Cloudのままにしておくのが妥当な判断です。次回もGTMの実践活用を続けます。