2026.07.23 インフラ

Cloud Armorとは？Google CloudのWAF/DDoS防御の仕組み・料金・実装判断を実装者向けに解説【2026年版】

Cloud Armorは、Google Cloudが提供するWAF（Web Application Firewall）およびDDoS防御のサービスです。ロードバランサーの手前、Google Cloudのエッジで悪性の通信をふるい落とし、SQLインジェクションやクロスサイトスクリプティング（XSS）といったアプリケーション攻撃と、大量アクセスによるサービス妨害の両方を防ぎます。この記事では、防御が働く場所とセキュリティポリシーの構造、プリコンフィグWAFルールやカスタムルール・レート制限といった主要機能、StandardとEnterpriseの違い、gcloudやTerraformでの導入手順、そして採用を見送るべき場面まで、Google Cloudでシステムを構築する技術者の判断に必要な情報を実装目線でまとめました。仕様・数値は公式ドキュメント（2026年7月時点）を基準に記載し、変動しうる項目は時点を添えて示します。

目次

まとめ：Cloud Armorの要点と採用判断の結論

Cloud Armorは、Google Cloudのロードバランサーに紐付けて使う、フルマネージドのL7セキュリティサービスです。バックエンドサービスに「セキュリティポリシー」を割り当て、その中に許可・拒否・レート制限などのルールを優先度付きで並べることで、正規の利用者に届く前に不正な通信を遮断します。OWASPが公開する攻撃パターンに対応した既製ルールが用意され、IPや地域を指定した制御や、独自条件を書くカスタムルールも組めます。

採用判断の軸は明確です。Google Cloudの外部向けロードバランサーでWebアプリやAPIを公開しており、WAFとDDoS防御をGoogle Cloud内で完結させたいなら、Cloud Armorは素直な選択肢です。逆に、配信基盤を別のCDN事業者（CloudflareやAkamaiなど）に寄せているなら、そちら側のWAFと二重になり管理が煩雑になります。ロードバランサーを介さない構成や、on-premブラウザ配信では対象外です。Google Cloudを含むインフラ設計・構築を外部に任せたい場合は、Google Cloudを含むクラウドインフラの設計・構築・運用から相談できます。

Cloud Armorとはロードバランサー前段で守るマネージドWAF

Cloud Armorは、Google Cloudのグローバルなネットワークエッジで通信を検査し、ロードバランサーの背後にあるバックエンドへ渡すかどうかを判定するサービスです。ソフトウェアやアプライアンスを自前で構築せず、ポリシーとルールを宣言するだけで守りが働く点が、自社運用のWAFとの大きな違いになります。WAF全般の位置づけやIPS・IDSとの役割分担はWAFとは何かと企業の選び方の解説で整理しているため、前提を押さえたい場合はあわせて参照してください。

Google Cloudのエッジとバックエンドサービスで防御する仕組み

Cloud Armorの検査は、利用者の通信がバックエンドに達する前、送信元にできるだけ近いGoogle Cloudのエッジで実行されます。ここで拒否された通信は、Virtual Private Cloud（VPC）ネットワークやアプリケーションのリソースを消費しません。守る対象は、外部向けアプリケーションロードバランサー（グローバル外部ALB／クラシックALB）や、プロキシ型ネットワークロードバランサーなどです。ロードバランサー自体の役割はロードバランサーの仕組みと振り分け方式の解説で扱っており、Cloud Armorはその手前に立つ防壁だと捉えると理解しやすくなります。

セキュリティポリシーとルールの優先度で許可・拒否を決める構造

Cloud Armorの中心は「セキュリティポリシー」です。ポリシーは複数のルールを束ねた入れ物で、各ルールには一致条件（送信元IP・地域・リクエストの中身など）と、一致したときの動作（許可・拒否・レート制限・reCAPTCHA提示など）、そして優先度の数値を設定します。通信は優先度の小さいルールから順に評価され、最初に一致したルールの動作が適用される仕組みです。ポリシーには、バックエンドサービスを守るbackend security policy、エッジで先に効くnetwork edge security policy、組織階層に一括適用するhierarchical security policyの区分があり、用途に応じて選びます。ルールの並び順そのものが挙動を決めるため、既定の拒否ルールと個別の許可ルールの優先度設計が実装の勘所になります。

Cloud Armorの主要機能とできることを役割ごとに整理する

Cloud Armorは、既製のルールで手早く守りを固めつつ、独自要件はカスタムルールで補える構成です。ここでは実装で使う主要機能を、役割ごとに整理します。

プリコンフィグWAFルールでOWASPの主要な攻撃パターンを防ぐ

プリコンフィグWAFルールは、OWASPが公開するCore Rule Set（4.x系・2026年7月時点）を基に組まれた既製のルール群です。SQLインジェクション、XSS、ローカル／リモートファイルインクルージョン、リモートコード実行といった代表的な攻撃の検知シグネチャがまとまっており、ポリシーに一行加えるだけで有効化できます。導入初期は誤検知（正規の通信を攻撃と誤判定する）が起きやすいため、最初はブロックせず記録だけ行うプレビューモードで様子を見て、感度（sensitivity）や除外条件を調整してから遮断へ切り替える進め方が安全です。

カスタムルール言語とレート制限で独自の防御条件を柔軟に指定する

既製ルールで足りない要件は、Cloud Armor独自のカスタムルール言語で条件を記述します。送信元IPの範囲、リクエストのヘッダーやパス、地域コードなどを組み合わせ、特定の国からの管理画面アクセスだけ拒否する、といった細かな制御を書けるのが強みです。あわせて、一定時間あたりのリクエスト数に上限を設けるレート制限（throttle）や、しきい値を超えた送信元を一定時間締め出すrate-based banも設定でき、アプリケーション層への過剰なアクセスやDDoSの緩和に効きます。DDoS攻撃そのものの種類と対策の全体像はDDoS攻撃の仕組みと企業が取るべき対策の解説で扱っています。

Adaptive ProtectionとBot管理・脅威インテリジェンス

上位のEnterprise層では、機械学習で通常時の通信傾向を学習し、L7DDoSの兆候を自動で検知するAdaptive Protectionが使えます。異常を検知すると、緩和のためのルール案を提示するため、攻撃の最中に手作業でルールを組む負担を下げられる点が利点です。加えて、reCAPTCHAと連携して自動化されたボットを見分けるBot管理、Googleが収集する脅威インテリジェンスに基づいて既知の不正なIPや地域をまとめて弾く機能、名前付きのIP群を再利用するAddress groupsなども備えます。これらは高度な防御を必要とする本番サービス向けの装備です。

StandardとEnterpriseの違いと料金の考え方の勘所

Cloud Armorには、従量課金のStandardと、年間サブスクリプションのEnterprise（旧Managed Protection Plus）があり、必要な防御の水準で選びます。どちらを選ぶかは、守りたいサービスの規模と、DDoS対応にどこまで保険をかけたいかで決まります。

従量課金のStandardと年間契約のEnterpriseの選び分け

Standardは、有効にしたセキュリティポリシー数・ルール数と、処理したリクエスト数に応じて課金される従量制です。手動でポリシーを組み、既製WAFルールとカスタムルールで守る基本構成はStandardの範囲で足ります。対してEnterpriseは、月額固定の年間契約で、Adaptive ProtectionやGoogle脅威インテリジェンス、専門チームによるDDoS対応支援、攻撃時の想定外課金に対する保護などが含まれます。常時公開の大規模サービスで、大規模DDoSのリスクを金額面まで含めて抑えたい場合はEnterprise、小〜中規模で基本的な防御を積み上げたい場合はStandard、という選び分けが実務の目安です。

コストを見積もる際に押さえておきたい課金要素と費用設計の考え方

課金額は、ポリシーとルールの本数、そして通過するリクエスト数で伸びます。ルールを細分化しすぎると本数が増え、かえって費用と運用の手間が積み上がるため、似た条件はまとめて記述する設計が費用の抑制につながります。金額は変動しうるため、最新の料金ページで自分のリージョンと想定トラフィックを当てはめて試算してください。Google Cloud全体のセキュリティ設計の考え方はクラウドセキュリティの責任共有モデルと守り方の解説とあわせて検討すると、どこを自社で守るべきかが整理しやすくなります。

AWS WAFやCloudflareとの違いと選択の判断基準を示す

WAFはCloud Armorだけではありません。AWS WAFやCloudflareといった選択肢と並べると、Cloud Armorをいつ選ぶべきかが見えてきます。中立に並べるのではなく、実務での判断を言い切ります。

配信基盤に合わせて選ぶ考え方と各WAFサービスの位置づけの違い

WAFは、通信が通る配信基盤に密着させるほど運用が素直になります。AWSのロードバランサーやCloudFrontで配信しているならAWS WAF、CloudflareのCDNを前段に置いているならCloudflareのWAFが噛み合います。同様に、Google Cloudのロードバランサーでアプリを公開しているなら、同じネットワーク内で完結するCloud Armorが管理面で有利です。複数のWAFを重ねると、どの層でブロックされたかの切り分けが難しくなり、誤検知の調査コストが増えます。「今どこで通信を受けているか」を起点に、その配信基盤に付属するWAFを第一候補にする判断が堅実です。

Cloud Armorを選ぶべきケースと他サービスが向くケース

Cloud Armorが向くのは、外部向けのGoogle Cloudロードバランサーでサービスを公開し、WAFとDDoS防御をGoogle Cloudの請求・権限・監視の中に統合したい場合です。逆に、静的配信を世界中のエッジに広く展開し、キャッシュとWAFを一体で運用したい要件なら、CDNとしての機能が厚いCloudflareが向く場面もあります。マルチクラウドで配信をまたぐ場合は、どのクラウドのトラフィックが主流かを見極め、主となる基盤側のWAFに寄せるのが管理を単純にする近道です。

Cloud Armorの導入手順と実装のつまずきどころを押さえる

採用を決めたら、実装の流れを押さえておきます。基本は「ポリシーを作る→ルールを足す→バックエンドサービスに紐付ける」の三段で、gcloudコマンドやTerraformで宣言的に管理できます。

gcloudとTerraformでセキュリティポリシーを作成しバックエンドに紐付ける

最小構成は、セキュリティポリシーを新規作成し、その中に既定動作（例：既定は許可）と個別ルール（例：特定IPを拒否）を優先度付きで追加し、対象のバックエンドサービスにポリシーを割り当てる流れです。gcloud compute security-policies create でポリシーを作り、add-rule でルールを重ね、gcloud compute backend-services update の –security-policy でロードバランサーのバックエンドへ結び付けます。継続運用では、これらをTerraformのgoogle_compute_security_policyリソースとしてコード管理し、ルール変更をレビューとバージョン管理の対象に載せると、設定ミスの巻き戻しが容易になります。

プレビューモードとログで誤検知を減らしてから遮断へ切り替える

実装で最も失敗しやすいのが、既製WAFルールをいきなり遮断で有効化して正規の通信まで巻き込む誤検知です。まずルールをプレビューモード（一致は記録するが遮断はしない）で動かし、Cloud Loggingに出る一致ログを見て、正規の通信が引っかかっていないかを確かめます。誤検知が出たら、感度を下げるか、対象パスを除外条件で外し、問題がないと確認できてから遮断へ切り替えるのが定石です。Google Cloudのサーバーレス基盤であるCloud Runの仕組みと料金の解説と組み合わせる構成でも、外部ロードバランサー経由で公開する場合は同じ手順でCloud Armorを前段に置けます。段階的に締める進め方が、公開中のサービスを止めずに守りを固める安全策です。

よくある質問

Cloud Armorの導入を検討する際に、実装者からよく挙がる質問をまとめます。

Cloud ArmorはロードバランサーなしでもLB単体のVMを守れますか？

Cloud Armorのセキュリティポリシーは、対応するロードバランサーのバックエンドサービスに割り当てて機能します。したがって、ロードバランサーを介さずに公開IPを直接付けた仮想マシン（Compute Engine）単体を、Cloud Armorで直接守ることはできません。VMを守りたい場合は、前段に外部ロードバランサーを置き、そのバックエンドにVMを収めてからポリシーを紐付ける構成にします。

Cloud ArmorとVPCファイアウォールルールは何が違いますか？

VPCファイアウォールは、IPアドレスやポート・プロトコルといったネットワーク層（L3/L4）での通信可否を制御します。対してCloud Armorは、URLパスやリクエストの中身といったアプリケーション層（L7）まで踏み込んで判定するWAFです。SQLインジェクションのように通信の中身を見なければ判別できない攻撃は、ファイアウォールでは防げず、Cloud Armorの役割になります。両者は競合せず、層を分けて併用します。

既製のWAFルールを有効にすると正規の通信も止まりませんか？

初期状態では誤検知が起きることがあります。だからこそ、いきなり遮断せず、まず一致を記録するだけのプレビューモードで動かし、ログを見て正規の通信が巻き込まれていないかを確認します。誤検知が見つかれば感度を下げるか除外条件を加え、問題がないと判断できてから遮断へ切り替えるのが定石です。この段階的な調整を挟むことで、公開中のサービスを止めずに導入できます。

StandardとEnterpriseはどちらから始めるべきですか？

基本的なWAFとレート制限で守れる小〜中規模のサービスなら、従量課金のStandardから始めて差し支えありません。大規模なL7DDoSまで見据える、あるいは攻撃時の想定外課金を保険で抑えたい常時公開サービスでは、Adaptive Protectionや専門支援が含まれるEnterpriseを検討します。まずStandardで運用し、トラフィックとリスクが増えた段階でEnterpriseへ引き上げる判断が現実的です。

Cloud Armorの設計や導入を外部に相談できますか？

可能です。Google Cloudのロードバランサー構成、Cloud Armorのポリシー設計、誤検知を抑えたルールの調整、Terraformによるコード管理までを受託開発で対応できます。ルールの優先度設計や既製ルールの感度調整は運用の初期に決めるほど手戻りが減るため、公開前の設計段階からの相談が有効です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る