アラートポリシー費用削減戦略をTerraformで実行してみた

 2025.04.22 XIMIX 山田

はじめに

2026年5月1日以降、Google Cloud Monitoring ではアラートポリシーの使用に対する課金が開始されます。これに対し、Googleはアラートポリシーの費用を削減するための戦略を複数提示しています。本記事では、アラートポリシー費用削減戦略をTerraformを活用して実現する方法について解説します。アラートポリシーの課金対応にお困りの方はぜひ参考にしてみてください。

アラートポリシーの料金モデル

料金モデルは以下になります。(2025/04現在)
  • アラートポリシーの条件あたり月額 $ 0.10
  • 指標アラートポリシー条件のクエリによって返される 1,000,000 時系列あたり $ 0.35
今回採用する「アラートポリシーを統合し、より多くのリソースをまとめて監視する」戦略は1つ目の条件にかかるコストを削減するためのものです。

アラートポリシー費用削減戦略

この戦略を実現することでどの程度コストを削減できるかを例を挙げて説明します。アラートを出す対象のリソースとして100個VMがあると仮定します。
VM1つに対して、1つのアラートポリシーを作成する場合、条件費用は以下になります。
  • 100条件×月額 $ 0.10 = 月額 $ 10 = 月額 1,500円($ 1 = 150円と定義)
アラートポリシーを統合すると1つのアラートポリシーで100VMを監視することになるので、条件費用は以下になります。
  • 1条件×月額 $ 0.10 = 月額 $ 0.10 = 月額 15円
つまり、監視対象のリソースが多いほど当戦略の恩恵は大きくなります。

 Terraformで実装

では実際にアラートポリシーを統合していきましょう。
リソースの構築はTerraformを使用して行います。
統合前のアラートポリシーソースと統合後のアラートポリシーソースを比較しながら解説します。

統合前のアラートポリシーソース

全体ソース

alert.tf
data "google_compute_instance" "vm" {

for_each = toset(var.alert_target)
name = ${each.value}
zone = "asia-northeast1-a"
}

data "google_monitoring_notification_channel" "all" {
  for_each = toset(var.notification_channels)

project      = var.project
  display_name = each.value
}


resource "google_monitoring_alert_policy" "alert_cpu" {

for_each = toset(var.alert_target)
project = var.project

display_name = "[${each.value}] VM checking cpu utilization"
combiner = "OR"
conditions {
display_name = "[${each.value}] VM checking cpu utilization"
condition_threshold {
filter = "metric.type = \"compute.googleapis.com/instance/cpu/utilization\" AND resource.labels.instance_id=\"${data.google_compute_instance.vm[each.value].instance_id}\" AND resource.type=\"gce_instance\""
duration = "120s"
comparison = "COMPARISON_GT"
threshold_value = 0.9
trigger {
count = 1
}
aggregations {
alignment_period = "60s"
per_series_aligner = "ALIGN_MEAN"
}
}
}

notification_channels = [for channel in data.google_monitoring_notification_channel.all : channel.name]

documentation {
content = "インスタンス(${each.value})のCPU使用率が高くなっています"
}
}

variable "alert_target" {
type = list(string)
}

variable "notification_channels" {
  type = list(string)
}
terraform.tfvars
alert_target = ["vm1", "vm2", "vm3"] notification_channels = ["通知チャネル1", "通知チャネル2"]
for_eachを使用してVMのCPU使用率を監視するアラートポリシーをVMの数だけ作成しています。以下で統合後に変更がある箇所を抜粋して解説します。

filter

filter = "metric.type = \"compute.googleapis.com/instance/cpu/utilization\" AND resource.labels.instance_id=\"${data.google_compute_instance.vm[each.value].instance_id}\" AND resource.type=\"gce_instance\""

resource.labels.instance_idでVMを指定しています。この記述によって指定VM専用のアラートポリシーになっています。

aggregations

aggregations {
 alignment_period = "60s"
 per_series_aligner = "ALIGN_MEAN"
 } 
ローリングウィンドウ、ローリングウィンドウ関数を設定しています。

documentation

documentation {
content = "インスタンス(${each.value})のCPU使用率が高くなっています"
}

アラートに表示するドキュメントです。問題が発生したVM名が明示されるようになっています。

統合後のアラートポリシーソース

全体ソース

alert.tf

data "google_monitoring_notification_channel" "all" {
  for_each = toset(var.notification_channels)

project      = var.project
  display_name = each.value
}


resource "google_monitoring_alert_policy" "alert_cpu" {

project = var.project

display_name = "VM checking cpu utilization"
combiner = "OR"
conditions {
display_name = "VM checking cpu utilization"
condition_threshold {
filter = "metric.type = \"compute.googleapis.com/instance/cpu/utilization\" AND resource.labels.project_id=\"${var.project}\" AND resource.type=\"gce_instance\""
duration = "120s"
comparison = "COMPARISON_GT"
threshold_value = 0.9
trigger {
count = 1
}
aggregations {
alignment_period = "60s"
per_series_aligner = "ALIGN_MEAN" group_by_fields      = ["metadata.system_labels.name"]
cross_series_reducer = "REDUCE_MEAN"

}
}
}

notification_channels = [for channel in data.google_monitoring_notification_channel.all : channel.name]

documentation {
content = "インスタンス($${metadata.system_labels.name})のCPU使用率が高くなっています"
}
}

variable "notification_channels" {
  type = list(string)
}

terraform.tfvars
notification_channels = ["通知チャネル1", "通知チャネル2"]
for_eachを削除したため、このソースで作られるアラートポリシーは1つだけです。each.valueを使っていた部分やVMのdata呼び出しを削除しています。
以下で変更点を抜粋して解説します。

filter

filter = "metric.type = \"compute.googleapis.com/instance/cpu/utilization\" AND resource.labels.project_id=\"${var.project}\" AND resource.type=\"gce_instance\""

resource.labels.project_idでプロジェクトを指定しています。1つのVMではなく、プロジェクトに存在する全てのVMを監視対象にしています。
もし監視対象を指定したい場合、以下のようにone_of演算子を使いましょう。
metadata.system_labels.name = one_of(\"${google_compute_instance.<ローカル名>.name}\", \"${google_compute_instance.<ローカル名>.name}\", \"${google_compute_instance.<ローカル名>.name}\"

aggregations

aggregations {
alignment_period = "60s"
per_series_aligner = "ALIGN_MEAN" group_by_fields      = ["metadata.system_labels.name"]
cross_series_reducer = "REDUCE_MEAN"

}
グループ化、グループ集約関数を追加しています。理由はdocumentationで後述します。

documentation

documentation {
content = "インスタンス($${metadata.system_labels.name})のCPU使用率が高くなっています"
}

リソース名の表示にmetadata.system_labels.nameを使用しています。使う指標やリソースによってはmetric変数やresource変数でもインスタンス名の表示はできますが、汎用的に使用できるのはmetadata変数です。
metadata変数を使うには、フィルタまたはグループにラベルを明示的に含める必要があります。これがaggregationsでグループ化の設定を追加した理由です。
また、${ をドキュメントに含めるために、$ 記号を2つ目の$記号でエスケープしています。
 
参考:

アラートの確認

通知チャネルをメールに設定し、実際にアラートを発報した様子を以下に掲載します。
CPU使用率が5%を超えたVM(gce-log-test-1)の名前がドキュメントに表示されています。
alert_result

まとめ 

2026年5月1日に開始されるアラートポリシーの課金への対策について、実装レベルで解説しました。アラートポリシーの費用には「条件費用」と「時系列費用」の2種類あります。今回は条件費用に着目し、「アラートポリシーを統合し、より多くのリソースをまとめて監視する」戦略を採用しました。
Terraformを使用した実装では、主に以下の要素を変更することでアラートの統合を実現しました。
  • filter:1つのVMからプロジェクト内の全VMに範囲を拡大
  • aggregations:グループ化設定追加でmetadata変数を使用可能にする
  • documentation:metadata変数を使用してリソース名を表示

参考


Google Cloud、Google Workspace に関するご相談はXIMIXへ!

Google Cloud、Google Workspaceに関する お問い合わせはこちら

執筆者紹介

山田蒼平
XIMIX 山田
2024年新卒入社。主な業務はterraformを使用したGoogle Cloudの基盤保守

アラートポリシー費用削減戦略をTerraformで実行してみた

BACK TO LIST

新規CTA

Recent post最新記事

ブログ無料購読のご案内

本ブログの更新案内をメールで
お届けします。

VIEW MORE