AWS Firewall Manager入門｜WAF・Shield・Network FirewallをOrganizations全体で一元管理するクラウドセキュリティ運用ガイド

マルチアカウント構成でクラウドを運用し始めると、必ず直面するのが「各アカウントのセキュリティルールをどうやって統一するか」という問題です。開発・ステージング・本番と環境が増えるたびに、WAFのルールをコピーしてまわったり、Shield Advancedの設定を個別アカウントで繰り返したりするのは、運用負荷が高いだけでなく、設定漏れによるリスクも孕んでいます。

AWS Firewall Managerは、そのペインポイントを解消するために設計されたサービスです。AWS Organizationsと連携し、WAF・Shield Advanced・セキュリティグループ・Network Firewallといったセキュリティポリシーを組織全体のアカウントへ一括適用・自動補完する仕組みを提供します。

この記事では、AWS Firewall Managerの仕組みと前提条件、サポートされるポリシータイプ、料金の構造、具体的な設定手順、そして現場でよくはまるポイントを整理します。既存のWAF・Shield・Network Firewallを個別に使っている方が、次のステップとして組織統合を検討する際の参考にしてください。

AWS Firewall Managerとは何か？（オンプレ運用との違い）

オンプレミスでは、ファイアウォールポリシーはネットワーク境界の物理・仮想アプライアンスに集約されていました。すべてのトラフィックがその境界を通るため、ルールを一か所に入れれば組織全体に効いていました。

クラウドでは構造が変わります。AWSアカウントが複数に分割され、リージョンも複数にまたがるため、WAFのWeb ACLはALBやCloudFrontごとに個別にアタッチしなければならず、セキュリティグループはVPCごと・インスタンスごとに設定が必要です。組織が大きくなるほど、ポリシーの「抜け」「ばらつき」が生まれやすくなります。

AWS Firewall Managerは、この問題を解決するための「ポリシー配布・強制適用レイヤー」です。管理者アカウントから一度ポリシーを定義すれば、Organizations配下の対象アカウントへ自動的に展開・適用されます。新しいアカウントがOrganizationsに加わった際も、スコープの条件に合致すれば自動的にポリシーが適用される点が、手作業との大きな違いです。

利用前の前提条件

AWS Firewall Managerを使う前に、以下の3点が整っている必要があります。

1. AWS Organizationsの有効化（すべての機能）

Firewall ManagerはAWS Organizationsと統合して動作します。組織が作成されており、「すべての機能」が有効になっている必要があります（コンソリデーティッドビリング機能のみでは不可）。AWS Organizationsの基礎とSCPによるガバナンス設計については別記事で詳しく解説しています。

2. Firewall Manager管理者アカウントの指定

OrganizationsのManagement Account（マスターアカウント）、または委任された管理者アカウントのどちらかをFirewall Managerの管理者として指定します。管理者の指定はManagement AccountからのみCLIまたはコンソールで実行します。

# AWS CLIでFirewall Manager管理者アカウントを指定する（Management Accountから実行）
aws fms associate-admin-account   --admin-account 123456789012   --region us-east-1

# 現在の管理者アカウントを確認する
aws fms get-admin-account   --region us-east-1

注意: CloudFront向けのWAFポリシーはus-east-1で作成する必要があります。CloudFrontはグローバルサービスであり、us-east-1のWAFしかアタッチできないためです。他のリージョン向けポリシーはそれぞれのリージョンで作成します。

3. 対象アカウントでのAWS Config有効化

Firewall Managerはリソースのコンプライアンス評価にAWS Configのリソース追跡を利用します。対象アカウントおよびリージョンでAWS Configが有効になっていないと、ポリシーを適用できません。新アカウント作成時にConfigを自動有効化する仕組みを事前に整えておくことを推奨します。

サポートされるポリシータイプ（2026年時点）

Firewall Managerが管理できるポリシータイプは主に5種類あります。それぞれの役割と適用範囲を整理します。

1. AWS WAF ポリシー

AWS WAFのWeb ACLを組織全体のALB・CloudFront・API Gateway・AppSyncに自動的に作成・アタッチします。

・強制適用モード: 対象リソースに既存のWeb ACLがアタッチされていても、Firewall Managerが管理するWeb ACLを追加でアタッチします（既存のACLを削除はしない）
・共通ルールの先頭固定: どのアカウントのWeb ACLにも、組織共通のルール（例: AWSマネージドルール、IPレピュテーションリスト）を先頭に固定挿入できます
・個別ルールの追加許可: 共通ルールの後ろに、各アカウントが独自ルールを追加することを許可するかどうかを設定できます

2. AWS Shield Advanced ポリシー

AWS Shield Advancedのサブスクリプションと保護設定を、組織内の対象アカウントへ自動展開します。ALB・EIP・Route 53ホストゾーン・CloudFrontなどの対象リソースに保護を自動適用します。

Shield AdvancedはFirewall Managerを通じてOrganizations統合で利用すると、組織全体で1つの定額料金（,000/月・執筆時点）に集約できます。個別アカウントでShield Advancedを契約するよりも管理が簡潔になります。

3. セキュリティグループポリシー

2種類のモードがあります。

・共通セキュリティグループポリシー: 組織全体のEC2インスタンスやENIに共通のセキュリティグループを自動アタッチします（踏み台経由SSH許可や監視エージェント用ポートの許可など）
・コンテンツ監査ポリシー: 既存のセキュリティグループのルールが組織のポリシーに準拠しているかを監査します。0.0.0.0/0への全ポート公開などのリスクルールを検知・報告・自動修正できます

セキュリティグループとネットワークACLの使い分けを理解したうえでコンテンツ監査ポリシーを設計すると、誤検知のないルール定義が組みやすくなります。

4. AWS Network Firewall ポリシー

AWS Network Firewallのポリシーとファイアウォールエンドポイントを、対象アカウントのVPCに自動デプロイします。

・集中型モード: 検査用のVPCにNetwork Firewallを集中配置し、Transit Gatewayでトラフィックを集約・検査する設計
・分散型モード: 各アカウントのVPCにNetwork Firewallエンドポイントをデプロイする設計

Firewall Managerを使うと、どのVPCにどのモードでデプロイするかを一括定義できるため、アカウント数が多い環境でのNetwork Firewall展開コストが大幅に下がります。

5. Route 53 Resolver DNS Firewall ポリシー

DNSクエリに対するフィルタリングルール（悪意あるドメインのブロックなど）をVPC単位で適用します。Firewall Managerを使うと、DNS Firewallのルールグループとその関連付けを組織全体に自動展開できます。EC2インスタンスからの外部DNS通信を組織ポリシーで統制したい場合に有効です。

料金の仕組み（2026年時点）

AWS Firewall Managerの料金は「ポリシーごと・リージョンごとの月額料金」と「配下のAWSリソース料金」の合算です。

費用試算の例: WAFポリシー1本を東京・大阪・バージニア北部の3リージョンに適用すると、ポリシー料金だけで00/月（3リージョン×00）になります。さらに10アカウントにWeb ACLが作成されると0/月加算されます。

ポイントは「00/月はポリシー×リージョンの組み合わせでカウントされる」点です。むやみにリージョンを増やすと費用が積み上がるため、実際にトラフィックが通過するリージョンのみを対象とするスコープ設計が重要です。

設定の基本手順

WAFポリシーをFirewall Managerで組織全体に展開する手順を例に説明します。

1. 管理者アカウントでFirewall Managerコンソールを開く

Firewall Managerを管理者として指定したアカウントでAWSコンソールにログインし、「AWS Firewall Manager」サービスを開きます。初回は管理者アカウントの指定と、AWS Configの有効化を促すウィザードが表示されます。指示に従って設定を完了させてください。

2. ポリシーを作成する

「セキュリティポリシー」→「ポリシーを作成する」から新しいポリシーを作成します。ポリシータイプで「AWS WAF」を選択し、次の項目を設定します。

・Web ACLの設定: 共通ルール（AWSマネージドルールグループ、IPレピュテーションリストなど）を定義します
・スコープ（対象アカウント・OU）: Organizations全体、特定のOUのみ、特定のアカウントのみ、といった条件で絞り込みます
・対象リソースタイプ: Application Load Balancer、CloudFront、API Gatewayなど、Web ACLをアタッチするリソースタイプを選択します
・自動修復の設定: 非準拠リソースが見つかったとき、Firewall Managerが自動でWeb ACLをアタッチするかどうかを選択します

3. コンプライアンス状況を確認する

ポリシー作成後、コンソールの「コンプライアンス状況」タブで各アカウントの準拠状況が一覧確認できます。非準拠リソースがあれば、そのリソース名・アカウントIDとともに詳細が表示されます。

# AWS CLIでFirewall Managerポリシーの一覧を取得する
aws fms list-policies   --region us-east-1

# 特定ポリシーのコンプライアンス状況を確認する
aws fms list-compliance-status   --policy-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   --region us-east-1

# 特定アカウントの違反リソース詳細を取得する
aws fms get-violation-details   --policy-id xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx   --member-account 123456789012   --resource-id arn:aws:elasticloadbalancing:...   --resource-type AWS::ElasticLoadBalancingV2::LoadBalancer   --region us-east-1

現場で役立つ設計・運用Tips

【重要】スコープ設計は「除外リスト」で管理する

Firewall Managerのスコープはデフォルトで「Organizations全体」に設定できますが、開発環境のアカウントにShield Advancedを適用してしまうと不要なコストが発生します。対象アカウントを「除外するOUタグ」で管理するパターンが運用しやすく、環境ごとにAWSアカウントを分けている構成と相性が良いです。

たとえば、本番OU・ステージングOUをFirewall Manager対象とし、開発OUを除外するといった設計です。

WAFポリシーは「共通ルール固定＋追加ルール許可」の組み合わせで設計する

Firewall Managerが配布するWAF Web ACLには、共通ルール（AWSマネージドルール、地域制限）を先頭のルールグループとして固定しつつ、個々のアカウントが独自ルール（アプリケーション固有のパスブロックなど）を後ろに追加できる構成にすると、統一性と柔軟性のバランスが取れます。

優先度（Priority）の設計：
・Priority 0～10: Firewall Managerが配布する共通ルールグループ（上書き不可）
・Priority 11以降: 各アカウントが自由に追加できる独自ルール

セキュリティグループ監査ポリシーは「警告モード」から始める

コンテンツ監査ポリシーを「自動修復あり」で適用すると、既存の正当な設定が予期せず修正されるリスクがあります。最初は自動修復をオフにして「非準拠リソースの可視化のみ」から運用を始め、ルールの影響範囲を把握してから自動修復を有効化するのが安全です。

AWS Security Hubとの統合でアラートを一元化する

Firewall Managerのコンプライアンス違反はAWS Security Hubに自動的に転送されます。Security HubでFirewall Managerの検出結果を受け取るように設定すると、WAF・Shield・セキュリティグループの違反が一つのダッシュボードにまとまり、セキュリティ運用の効率が上がります。

CloudTrail・GuardDutyと組み合わせると、「誰がどのアカウントでFirewall Managerのポリシーを変更したか」までトレースできる体制が整います。

よくあるトラブルと対処法

「管理者アカウントが見つからない」エラーが出る

Firewall Managerのコンソールを開いたとき「このアカウントはFirewall Manager管理者として設定されていません」と表示される場合、Management AccountからFirewall Manager管理者アカウントの指定が完了していないか、指定したアカウントとは別のアカウントでコンソールを開いています。Management Accountに切り替えて、 CLIコマンドで正しく設定されているか確認してください。

新アカウントにポリシーが自動適用されない

Firewall Managerのポリシーは、スコープの条件に合致したアカウントに自動適用されますが、対象アカウントでAWS Configが有効になっていないと適用されません。新アカウント作成時にAWS Configを自動有効化する仕組みを事前に整えておくことが重要です。AWS Control Towerを使っている場合はランディングゾーンでConfigが自動有効化されます。

CloudFront向けWAFポリシーが反映されない

CloudFrontに適用するWAFポリシーは、必ずus-east-1リージョンで作成する必要があります。他のリージョンで作成したWAFポリシーはCloudFrontへのアタッチに対応していません。Firewall Managerコンソールのリージョンをバージニア北部（us-east-1）に切り替えてから、CloudFront向けポリシーを作成してください。

ポリシーを削除してもリソースが残る

Firewall Managerのポリシーを削除しても、ポリシーが作成したWAF Web ACLやNetwork Firewallエンドポイントは自動では削除されません。削除時にコンソールで「関連リソースも削除する」オプションを明示的に選ぶか、手動で各リソースを削除する必要があります。残留リソースはコスト発生源になるため、ポリシー削除後は対象アカウントのリソースを確認する習慣をつけてください。

本記事のまとめ

AWS Firewall Managerは、マルチアカウント構成でのセキュリティルール統一という課題に対して、手作業の繰り返しをゼロにする仕組みです。組織アカウント数が10を超えてきたあたりから、個別管理のコストがFirewall Managerの導入コストを超え始めます。

・前提条件: AWS Organizations（すべての機能有効）、Firewall Manager管理者アカウントの指定、各アカウントでAWS Config有効化
・対応ポリシータイプ: WAF v2・Shield Advanced・セキュリティグループ・Network Firewall・DNS Firewall
・料金の考え方: 00/月 × ポリシー数 × リージョン数（Shield AdvancedポリシーはShield本体に含む）
・設計の要点: スコープは「除外OUタグ」で管理、WAFは「共通ルール固定＋追加許可」構成、監査ポリシーは「警告モード」から開始
・Security Hubとの連携: コンプライアンス違反を一元集約して運用効率を向上

マルチアカウント設計を進めているチームは、早めの導入を検討する価値があるサービスです。