AWS Firewall Manager本番運用Vol1｜横断防御統制

1. マルチアカウント防御統制の課題とAWS Firewall Managerの全体像

AWS Organizationsで数十・数百のアカウントを運用する環境では、各アカウントの防御設定がばらつき、組織全体で一貫したセキュリティベースラインを維持することが難しくなります。AWS Firewall Managerは、WAF・Shield Advanced・Security Group・Network Firewall・Route 53 Resolver DNS Firewallといった防御を、組織横断で一元的に配信・強制するオーケストレーターです。

本セクションでは、マルチアカウント防御統制の本番課題を整理したうえで、Firewall Managerの全体像・個別防御サービスとの違い・本記事全体の構成を説明します。

1-1. マルチアカウント防御統制の本番課題

AWS環境を複数アカウントで運用する組織では、個別の防御サービスを各アカウントで独自に設定するアプローチが、規模の拡大とともに4つの根本的な課題を引き起こします。

課題1: 新規リソースへの防御適用漏れ

開発チームが新しいALBやAPI Gatewayを作成するたびに、セキュリティチームへの申告・WAFルールの手動アタッチが必要な環境では、通知漏れや作業漏れが避けられません。チームが増えるほど通知経路が複雑化し、保護されていないリソースが本番に存在する状態が常態化します。数十から数百のアカウントを横断するエンタープライズ環境では、この適用漏れを検出する仕組みそのものを構築するだけでも相当のコストが必要です。

「新規リソースは必ずWAFをアタッチする」というルールを徹底しようとしても、アカウント数が増えるにつれて例外が積み重なり、セキュリティ基準の維持が形骸化していきます。

課題2: 設定ドリフトと一貫性の崩壊

個別チームが自分のアカウント内でWAFルールを独自に変更したり、共通ルールを削除したりしても、中央から気づく手段がなければ組織全体のセキュリティベースラインが静かに崩れていきます。このドリフトは「設定した時点では正しかったが、その後変更された」状態であり、既存の監視ツールでは検出が困難です。

規制業界（金融・医療・政府）では、このドリフトが監査指摘事項となるため、常時監視と即時修復の仕組みが必須です。セキュリティ担当者が気づいたときには、基準外の状態が数週間〜数か月続いていたというケースは珍しくありません。

課題3: 組織全体のコンプライアンス可視化困難

50アカウントのうち何アカウントでWAFが適切に有効化されているか、どのリソースが保護されていないかを把握するには、各アカウントへのクロスアカウントアクセスを使ったカスタムスクリプトや、AWS Configアグリゲーターを組み合わせた複雑な仕組みが必要です。

このような自前の集約基盤を整備・維持するコストは、組織の成長とともに増大します。リアルタイムで組織全体の防御状態を把握することは、手動運用では現実的ではありません。四半期ごとの手動監査では発見が遅すぎ、インシデント後に「あのアカウントはWAFなしだった」と判明するリスクが残ります。

課題4: 手動運用の限界とセキュリティ人材の逼迫

新規アカウントを作成するたびにセキュリティチームが介入して標準ポリシーを適用する手動オペレーションは、組織規模と線形に増大します。開発速度の加速やM&Aによる大規模なアカウント追加の局面では、手動対応の破綻リスクが急増します。セキュリティ人材は定型的な適用作業ではなく、脅威分析・アーキテクチャ改善に集中すべきであり、自動化による解放が急務です。

AWS Firewall Managerは、これら4つの課題を自動化によって解決する設計思想で構築されています。管理アカウント（または委任管理者アカウント）からポリシーを一度定義すれば、Organizations配下の全対象アカウントへ自動適用・自動修復が行われ、新規リソースへも即座に保護が適用されます。

前提基盤: Organizations × AWS Config × 委任管理者

Firewall Managerは以下の3つを前提条件として要求します。前提が整っていなければポリシー適用が機能しないため、導入設計の最初に確認が必要です。

1. AWS Organizations（全機能有効化）: Firewall ManagerはOrganizations APIを使って組織構造（OU・アカウント）を参照します。Consolidated Billing機能のみでは不十分で、Organizations全機能（All features）の有効化が必要です。
2. AWS Config（各メンバーアカウントで有効化）: Firewall ManagerはConfigを使ってリソースを検出します。Configが有効化されていないアカウントはポリシー適用対象として認識されないため、全アカウントへのConfig有効化を先行して実施します。
3. Firewall Manager管理者アカウント（委任管理者）: Organizations管理アカウント（ルートアカウント）から委任管理者アカウントを指定します。日常的な防御統制運用は委任管理者アカウントから実施し、ルートアカウントへの直接ログインを減らすことで最小権限原則を徹底します。

ポリシータイプ6系統の概要

Firewall Managerは6系統のポリシータイプで、異なる防御サービスを組織横断で統制します。

multi-admin（最大10管理アカウント）の価値

multi-admin機能により、Organizations内で最大10のアカウントをFirewall Manager管理者として登録できます。この機能の本質的な価値は、部門横断の責務分離にあります。たとえば、セキュリティ部門アカウントがWAFポリシーを管理し、ネットワーク部門アカウントがNetwork Firewallポリシーを管理するといった役割分担が可能になります。各管理アカウントは自身が定義したポリシーの範囲内でのみ権限を持ち、他の管理者のポリシーに干渉できないため、大規模組織での運用管理に適しています。

1-2. 読者像と本記事の前提知識

本記事は次のような状況にあるAWSエンジニアを対象としています。

• AWS Organizationsで複数アカウントを管理中であり、WAF・Network Firewallなどの個別防御サービスはすでに導入済みですが、組織横断での一貫適用・コンプライアンス強制が課題になっているセキュリティエンジニア・プラットフォームエンジニア
• 監査・コンプライアンス対応の担当者で、防御設定の組織全体での準拠状態をリアルタイムに把握・報告する必要があるチーム
• Landing ZoneやControl Towerを導入済みで、ガードレールに加えてネットワーク防御の統制レイヤーを追加したいアーキテクト

前提知識として、AWSのマルチアカウント設計（Organizations）の基本概念と、WAFやNetwork Firewallの個別設定経験を想定します。各防御サービスの設定詳細（WAFルールの書き方・Network Firewallのルールグループ設計等）は本記事では扱いません。Firewall Managerによる横断統制の運用設計に集中します。

1-3. Firewall Managerと個別防御サービスの差別化

Firewall Managerを導入すべき場面と、個別防御サービスで十分な場面を明確に区別することが、不要なコスト負担を避け、適切な統制設計を行う出発点です。

Firewall Managerが費用対効果を発揮する閾値として、アカウント数が5〜10を超え、セキュリティ標準の一貫適用が監査要件となった時点で、Firewall Managerの自動化メリットが手動管理コストを上回ります。1〜3アカウントの小規模環境では、個別防御サービスの直接設定が適切です。

AWS Configとの役割分担

Firewall ManagerとAWS Configは補完関係にあります。

• AWS Config: すべてのリソース設定変更を記録し、「ある時点でどんな設定だったか」を追跡します。設定変更のコンプライアンス評価（Config Rules）も担いますが、防御ポリシーの強制配信は対象外です。
• AWS Firewall Manager: 防御ポリシー（WAF・Shield等）の組織横断強制配信・コンプライアンス違反の自動修復を担います。「どんな防御が適用されているべきか」を定義し、それを強制します。

Firewall ManagerはConfigを前提として利用しますが（リソース検出のため）、両者の守備範囲は明確に異なります。Config単体での設定変更追跡と、Firewall Managerによる防御ポリシー強制の両方を組み合わせることで、組織横断のセキュリティ統制が完成します。

導入ロードマップの概要

Firewall Managerを組織に導入する際は、一度にすべてのポリシーを展開するのではなく、段階的なアプローチを推奨します。まず本番環境の特に重要なALBへのWAFポリシー適用から始め、効果とコストを確認した後、対象を拡大していくことが現実的です。

1. Phase 1（検証）: 少数の本番アカウントをスコープとしてWAFポリシーを試験的に適用。自動修復は無効（検知のみ）にして既存設定への影響を確認。
2. Phase 2（展開）: 本番環境OUへの段階的な展開。自動修復を有効化し、非準拠リソースの自動是正フローを確立。
3. Phase 3（完全統制）: 全ポリシータイプを対象OUへ展開。Security HubとEventBridgeによる監視体制を整備。

本記事の各セクションは、このロードマップの理解を深めるための詳細解説として構成しています。§2の前提基盤から順に読み進めることで、実際の導入手順を体系的に把握できます。

Organizations・Configの前提整備に時間を要することが多いため、Firewall Manager導入前に早期着手することを推奨します。

2. 前提と基盤 — Organizations × 委任管理者 × AWS Config依存

Firewall Managerを利用するには、AWS Organizationsと委任管理者、AWS Configといった前提条件を整える必要があります。本セクションでは、これらの依存関係と、最大10管理アカウントを設定できるmulti-admin機能を解説します。

2-1. Organizationsと委任管理者の設定

AWS Firewall Managerを利用するには、AWS Organizationsの「全機能有効化（All features）」が必須条件です。デフォルトの「統合請求のみ（Consolidated billing only）」モードではFirewall Managerは動作しません。まず現在のモードを確認し、必要に応じて移行します。

# Organizations の現在のモードを確認
aws organizations describe-organization \
  --query 'Organization.FeatureSet'
# "ALL" が返れば全機能有効化済み
# "CONSOLIDATED_BILLING" の場合は有効化が必要

全機能有効化への移行は Organizations管理アカウントから開始しますが、すべてのメンバーアカウントの承認が必要です。承認は各アカウントのオーナーがメールで受け取るリクエストに応答する形で行われ、組織規模によっては数日〜1週間程度かかる場合があります。移行中のサービス停止は発生しません。ただし、SCPの有効化により既存のアクセスが制限されるリスクを伴うため、事前にSCPの影響範囲を評価しておくことをお勧めします。

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

全機能有効化が完了したら、Firewall Managerの管理者アカウントを指定します。管理者アカウントはFirewall Managerポリシーの作成・配信・コンプライアンス監視を担う重要なアカウントです。

# Organizations 管理アカウントから実行
# Firewall Manager 管理者アカウント（委任管理者）を登録
aws fms associate-admin-account \
  --admin-account 123456789012 \
  --region us-east-1

# 登録された管理者アカウントの確認
aws fms get-admin-account \
  --region us-east-1

Firewall Manager管理者アカウントには以下の権限が与えられます。

• 組織全体を対象としたポリシーの作成・更新・削除
• 各メンバーアカウントのコンプライアンス状態の確認
• ポリシー違反リソースの一覧表示
• 自動修復アクションの実行

委任管理者 vs Organizations管理アカウント直接使用

セキュリティのベストプラクティスとして、Organizations管理アカウント自身をFirewall Manager管理者に指定することは避けることをお勧めします。専用の委任管理者アカウントを設置することで、以下のメリットがあります。

委任管理者アカウントはOrganizations管理アカウントとは別の、セキュリティチームが運用する専用アカウント（たとえば security-tooling アカウント）とするのが一般的なベストプラクティスです。

Firewall Managerのオプトイン設定とアカウント登録フロー

Firewall Managerはリージョン固有のサービスです。aws fms associate-admin-account コマンドは各リージョンで個別に実行する必要があります。組織全体に横断するポリシーを配信する場合も、ポリシー自体は特定リージョンのFirewall Managerから作成します。

メンバーアカウントの自動登録については、Organizations全機能有効化後にOrganizationsの信頼済みアクセス（Trusted Access）を有効化することで、メンバーアカウントを個別にオプトインする手順が不要になります。

# Firewall Manager の Organizations 信頼済みアクセスを有効化
aws organizations enable-aws-service-access \
  --service-principal fms.amazonaws.com

信頼済みアクセスを有効化すると、Organizations内の新規アカウントもFirewall Managerのポリシー対象として自動的に含まれます。これにより、新規アカウント作成時に手動でオプトインする手間がなくなり、セキュリティベースラインの自動適用が実現します。

2-2. AWS Config依存と前提条件

AWS ConfigはFirewall Managerが機能するための根幹インフラです。Firewall Managerはリソースの構成状態を把握するためにAWS Configのリソースインベントリを利用しており、Config未有効化の環境ではポリシーが適用されません。

なぜAWS Configが必須なのか

Firewall Managerがポリシーを適用するには、組織内の各アカウント・各リージョンにどのようなリソースが存在するかを継続的に把握する必要があります。AWS Configはリソースの作成・変更・削除を継続的に記録し、そのインベントリデータをFirewall Managerに提供します。

具体的には以下のフローで機能します。

1. メンバーアカウントでALBが新規作成される
2. AWS ConfigがALBの作成イベントを検知・記録する
3. Firewall ManagerがConfigのイベントを受信し、WAFポリシーの適用対象かどうかを評価する
4. 対象であればWAF Web ACLをALBに関連付ける（自動修復が有効な場合）

このフローにおいてConfigが存在しない場合、Firewall Managerはリソースの存在を認識できず、ポリシーが適用されないまま放置されます。

Config有効化の設定確認方法

全アカウント・全リージョンでのConfig有効化状態を確認するには、ConfigのマルチアカウントアグリゲーターまたはAWS Configコンソールの「アグリゲーター」機能を使用します。

# 特定アカウント・リージョンの Config レコーダー確認
aws configservice describe-configuration-recorders \
  --region ap-northeast-1

# Config レコーダーの起動状態確認
aws configservice describe-configuration-recorder-status \
  --region ap-northeast-1

大規模Organizations（数十〜数百アカウント）において、全アカウントのConfig状態を手動で確認することは困難です。Organizations + Service Control Policiesと組み合わせて、新規アカウント作成時に自動でConfigを有効化するテンプレートを整備することをお勧めします。

Configリソース記録の要件

各ポリシータイプが必要とするリソースタイプをConfigで記録していることが必要です。主な対応関係は以下のとおりです。

Configのカスタムリソース記録設定を使用している環境では、上記リソースタイプが記録対象から除外されていないか確認が必要です。

Config未有効化時の挙動

Config未有効化のアカウント・リージョンでは、対象リソースが「NON_COMPLIANT（非準拠）」ではなく「評価対象外」として扱われます。Firewall Managerのコンプライアンスダッシュボードには該当リソースが表示されないため、「ポリシーが適用されているはず」という誤認識につながるケースがあります。

Config未有効化が原因の場合、ポリシーの削除・再作成をしても解消しません。対象アカウントでConfigを有効化し、リソースの初回スキャンが完了するまで（通常数分〜数時間）待機する必要があります。

AWS Configのコスト考慮

Firewall Manager導入を契機に全アカウント・全リージョンでConfigを有効化すると、Config自体の料金が想定以上に増加します。Configの主な課金要素は以下のとおりです。

• 設定項目の記録: 100万設定項目あたり$0.003（東京リージョン）
• 設定項目の評価（Config Rules）: 1万ルール評価あたり$0.001
• 設定スナップショット: スナップショット配信ごとに課金

100アカウント × 5リージョンの組織でリソース数が各アカウント1,000件程度の場合、Config料金だけで月額数千〜数万円規模になる可能性があります。AWS Pricing Calculatorで事前に見積もり、不要なリソースタイプの記録を無効化するコスト最適化を検討することをお勧めします。

2-3. multi-admin（最大10管理アカウント）

AWS Firewall Managerのmulti-admin機能は、1つのOrganizationsに対して最大10のFirewall Manager管理アカウントを設定できる機能拡張です。大規模組織でセキュリティ責務を複数チームへ分散させる際に有効です。

multi-adminの概要と背景

従来のFirewall Managerは、1つのOrganizationsに対してFirewall Manager管理アカウント（委任管理者）が1つしか設定できませんでした。これは小〜中規模の組織では問題ありませんが、大規模組織では以下の課題が生じていました。

• セキュリティチームが複数存在する場合（インフラセキュリティ/アプリセキュリティ/コンプライアンス等）、全員が同一の管理アカウントを共有する必要がある
• 一人の誤操作が全組織のFirewall Managerポリシーに影響する
• チームごとに管理するポリシータイプを分離できない

multi-admin機能により、これらの課題が解消されました。

委任管理者との違い

multi-adminの活用パターン

大規模企業での典型的な活用例は以下のとおりです。

• インフラセキュリティチーム: Network FirewallポリシーとDNS Firewallポリシーを管理
• アプリケーションセキュリティチーム: WAFポリシーとShield Advancedポリシーを管理
• ガバナンスチーム: Security Groupポリシー（コンテンツ監査・使用状況監査）を管理

このように責務を分割することで、各チームが自分の専門領域のポリシーのみを管理・変更できる体制を実現できます。

multi-adminの設定

multi-adminはOrganizations管理アカウントから設定します。

# Organizations 管理アカウントから実行
# Firewall Manager multi-admin 機能で管理アカウントを追加
aws fms put-admin-account \
  --admin-account 234567890123 \
  --admin-scope '{
 "AccountScope": {
"Accounts": [],
"AllAccountsEnabled": true,
"ExcludeSpecifiedAccounts": false
 },
 "RegionScope": {
"Regions": ["ap-northeast-1", "us-east-1"],
"AllRegionsEnabled": false
 },
 "PolicyTypeScope": {
"PolicyTypes": ["WAFV2"],
"AllPolicyTypesEnabled": false
 }
  }'

AdminScope パラメータで、各管理アカウントが管理できる範囲（対象アカウント・リージョン・ポリシータイプ）を限定できます。これにより、各チームの責務範囲を明確に定義できます。

multi-admin利用時の注意事項

multi-admin機能を有効化する際には以下の点に注意が必要です。

既存の委任管理者との関係として、従来の associate-admin-account で設定した委任管理者は「デフォルト管理者」としてmulti-admin環境でも機能します。デフォルト管理者は全ポリシーを参照・管理できる特別な権限を持ちます。

各管理アカウントは自分が作成したポリシーのコンプライアンス状態しかデフォルトでは表示されません。組織全体のコンプライアンス状態を俯瞰するには、デフォルト管理者のビューを使用します。

また、multi-adminを有効化すると、従来の get-admin-account APIの挙動が変わります。新しい list-admin-accounts-for-organization APIを使用して全管理アカウントを確認することをお勧めします。

3. ポリシータイプ詳解—WAF・Shield・SG・Network Firewall・DNS Firewall・サードパーティ

Firewall Managerは6種類のポリシータイプをサポートしており、組織のセキュリティ要件に応じて適切なタイプを選択します。各ポリシータイプは独自の保護対象と適用範囲を持ちます。ここでは各ポリシータイプの概要と使い分けを整理します。

3-1. WAF / Shield Advanced ポリシー

AWS WAFポリシーは、WebACLを組織横断で自動配信するためのポリシータイプです。個別アカウントで手動WebACLを作成していた従来の運用と異なり、Firewall Managerを通じて組織標準のWebACLをすべての対象リソースに一斉適用できます。

AWS WAFポリシーの保護対象リソース

WAFポリシーが保護できるリソースは次のとおりです。

• ALB（Application Load Balancer）: Webアプリケーションへの直接通信を防御
• Amazon CloudFront: エッジロケーションでの早期遮断
• Amazon API Gateway: REST APIとHTTP APIの防御
• AWS AppSync: GraphQL APIの防御
• Amazon Cognitoユーザープール: 認証エンドポイントの防御

WebACLの構成と配信

WAFポリシーでは、マネージドルールグループとカスタムルールを組み合わせたWebACLを定義します。主要なマネージドルールグループの組み合わせ例は次のとおりです。

• AWSManagedRulesCommonRuleSet: SQLインジェクション・XSS・OS/LFI攻撃を検出するコアセット
• AWSManagedRulesKnownBadInputsRuleSet: 既知の悪意あるリクエストパターンを検出
• AWSManagedRulesAmazonIpReputationList: Amazonが収集した悪意あるIPリストによるブロック
• AWSManagedRulesBotControlRuleSet: ボットトラフィックの検出・制御（APIスクレイピング対策）

Firewall ManagerのWAFポリシーでは、強制適用ルールグループ（First/Last） とメンバーアカウントのカスタマイズ許可範囲を設定できます。組織標準のルールをFirstルールグループとして配信し、メンバーアカウントが独自ルールを追加する余地を残す設計が推奨されます。

# WAFポリシー設定イメージ（CloudFormation）
PolicyName: OrgWAFPolicy
RemediationEnabled: true
ResourceType: AWS::ElasticLoadBalancingV2::LoadBalancer
SecurityServicePolicyData:
  Type: WAF
  ManagedServiceData: |
 {
"type": "WAF",
"defaultAction": { "type": "ALLOW" },
"overrideCustomerWebACLAssociation": false,
"preProcessRuleGroups": [
  { "managedRuleGroupIdentifier": {
"vendorName": "AWS",
"managedRuleGroupName": "AWSManagedRulesCommonRuleSet"
 }
  }
]
 }

レートベースルールによるDoS対策

WAFポリシーにはレートベースルールを組み込むことができ、同一IPからの過剰なリクエストを自動ブロックします。5分間に2,000リクエストを超えた場合にブロックするルールを全アカウントのALBに一括配信することで、単純なHTTPフラッド攻撃に対する組織標準の防御を確立できます。レートベースルールはFirewall ManagerポリシーのpostProcessRuleGroupsに組み込むことで、メンバーアカウントのローカルルールが実行されたあとに必ず評価されます。

AWS Shield Advancedポリシー

Shield Advancedポリシーは、DDoS攻撃からの保護を組織横断で有効化するポリシータイプです。個別アカウントで別々にShield Advancedを有効化する手間をなくし、Organizations全体に対して一度の設定で保護を適用します。

保護対象リソースには、ELB・CloudFront・Route 53ホストゾーン・EC2 EIP・AWS Global Acceleratorが含まれます。Firewall ManagerのShield Advancedポリシーを使うと、新規作成されたリソースにも自動的にShield Advanced保護が適用されます。

DDoS攻撃が発生した際は、Shield Response Team（SRT）が対応支援を行います。Firewall ManagerのShield Advancedポリシーでは、SRTがIAMロール経由でメンバーアカウントのWAFルールを緊急変更できるよう、IAMロール付与の自動化も設定できます。事前にSRTの緊急アクセスロールをポリシーに紐付けておくことで、インシデント発生時に素早く対応を依頼できます。

DDoS攻撃によるトラフィックスケールアップで発生した追加コストをShield Advancedが補償する「コスト保護」機能があります。Firewall ManagerのShield Advancedポリシーで組織全体にこの機能を確実に有効化することで、攻撃による予期せぬコスト増加を防ぎます。Shield Advancedの料金は月額約3,000ドル（1組織につき1契約）であり、Firewall Managerを通じて組織横断に適用すればアカウントごとの個別契約が不要になります。

3-2. Security Group ポリシー

Security Group（SG）ポリシーは、EC2インスタンスやENI、ALBに紐付くセキュリティグループを組織横断で管理するポリシータイプです。3種類のポリシーが用意されており、目的に応じて使い分けます。

共通セキュリティグループポリシー（Common Security Group Policy）

組織全体で使用する共通SGルールを配信するポリシーです。例えば、全アカウントのEC2インスタンスに「ポート443の許可」「不要なポートのデフォルト拒否」を強制適用するユースケースに使います。

共通SGポリシーには2つのモードがあります。

• 一括変更モード: Firewall ManagerがすべてのEC2インスタンスに共通SGを直接アタッチします
• 適用チェックモード: 共通SGのルールと同等のルールを持つSGが存在するか検証し、なければ報告・修復します

適用チェックモードは既存のSG設定を保ちながら準拠状態を検証するため、移行初期フェーズに適しています。準拠状態が安定したあとに一括変更モードへ切り替えることで、運用リスクを抑えた段階移行が可能です。

コンテンツ監査ポリシー（Security Group Content Audit Policy）

組織内のSGルールが定義した基準を満たしているかを継続的に監査するポリシーです。「0.0.0.0/0へのSSH（ポート22）許可ルールを含むSGをすべてのアカウントで禁止」といった要件を強制できます。

次の違反ルールタイプを検出できます。

• 全IPアドレス（0.0.0.0/0、::/0）への広範囲な許可
• 管理ポート（SSH: 22、RDP: 3389）のパブリック公開
• 定義した禁止プロトコルやポート範囲の使用

# 非準拠SGの確認（Firewall Manager CLI）
aws fms list-compliance-status \
  --policy-id "${POLICY_ID}" \
  --query 'PolicyComplianceStatusList[?PolicyComplianceStatus!=`COMPLIANT`].[MemberAccount,EvaluationResults]' \
  --output table

自動修復を有効にすると、違反ルールを自動削除します。本番環境では最初にview-onlyモードで影響範囲を確認してから自動修復を有効化することを推奨します。自動修復前にはListViolations APIで修復対象を一覧化し、重要なアプリケーションへの影響がないことを確認します。

使用状況監査ポリシー（Security Group Usage Audit Policy）

リソースに紐付いていない未使用SGや、過剰にリソースに関連付けられたSGを検出するポリシーです。不要なSGが増殖するのを防ぎ、セキュリティグループ管理の健全性を保ちます。

検出できる条件は次のとおりです。

• 30日以上いずれのリソースにも紐付いていない未使用SG
• 同一のインバウンドルールを持つ重複SG（統合候補）

未使用SGは手動削除が難しい規模になりがちですが、Firewall ManagerのSG使用状況監査ポリシーを使うと組織全体で一括検出・修復できます。定期的な棚卸しが不要になり、セキュリティグループ管理の自動化に貢献します。

3-3. Network Firewall / Route 53 DNS Firewall ポリシー

AWS Network Firewallポリシー

Network Firewallポリシーは、VPCにAWS Network Firewallエンドポイントを自動作成し、組織標準のファイアウォールルールセットを配信するポリシータイプです。個別アカウントでのエンドポイント作成とルール管理を一元化できます。

Firewall ManagerのNetwork Firewallポリシーでは、エンドポイントの配置モードを選択できます。

• 集中型モード（Centralized Deployment）: 専用のInspection VPC（セントラルVPC）にエンドポイントを配置し、Transit Gateway経由でトラフィックを集約してインスペクション
• 分散型モード（Distributed Deployment）: 各VPCの保護対象サブネットごとにエンドポイントを個別に作成

集中型モード:
  メンバーVPC → Transit Gateway → Inspection VPC（Firewallエンドポイント） → インターネット

分散型モード:
  各VPC内サブネット → VPC内のFirewallエンドポイント → 次ホップ（IGW等）

集中型モードはインターネット出口を1か所に絞れる反面、Transit Gatewayのコストと帯域制約を考慮する必要があります。分散型モードはVPCごとにエンドポイントが作成されるためコストは増えますが、レイテンシーが低く各VPCの独立性を保てます。

ルールの配信形式はSuricataルールグループ（ステートフルルール）と5-tuple形式（ステートレスルール）の2種類をサポートします。Suricataルールグループを使うと、シグネチャベースの詳細な脅威検出ルールをすべてのVPCに一括配信できます。組織共通の禁止ドメインリストや脅威シグネチャをSuricataルール形式で管理し、Firewall Manager経由で自動配信する運用が標準的です。

Amazon Route 53 Resolver DNS Firewallポリシー

DNS FirewallポリシーはVPC内のDNS解決（Route 53 Resolverを経由するクエリ）を対象に、悪意あるドメインや不審なDNSクエリを検出・ブロックするポリシータイプです。アプリケーション層の防御だけではカバーできないDNSトンネリングやC2通信を、DNS解決レベルでブロックします。

Firewall ManagerのDNS Firewallポリシーでは、AWSが提供するマネージドドメインリストを活用できます。

• AWSManagedDomainsAggregatedThreatList: マルウェア・ボットネット・スパイウェアのドメインリスト
• AWSManagedDomainsGlobalThreatList: 世界規模の脅威ドメイン（高精度版）
• AWSManagedDomainsGlobalThreatListShared: パブリックに利用可能な脅威ドメインリスト

カスタムドメインリストを作成して組織固有の禁止ドメインやC2サーバーのドメインを追加できます。Lambda経由で外部脅威インテリジェンスフィードを取り込み、カスタムリストを定期更新する自動化パターンが実践的です。

サードパーティポリシー（Marketplace連携）

Firewall ManagerはAWS Marketplaceのサードパーティ製ファイアウォールと連携したポリシータイプをサポートします。対応ベンダーの例を次に示します。

• Palo Alto Networks: VM-Series Next-Generation Firewallをエンドポイント経由で組織横断に配備
• Fortinet: FortiGate-VMによるディープパケットインスペクションを一元管理
• CheckPoint: CloudGuard Networkによる脅威防止を自動適用

サードパーティポリシーでは、Firewall ManagerがVPCにサードパーティのエンドポイントサービスを自動作成します。ライセンス管理はベンダーのMarketplaceサブスクリプション経由で行い、ルール管理はベンダーのコンソールで行うハイブリッド運用モデルになります。AWS固有のルール管理では対応できない高度な脅威インテリジェンス統合や、オンプレミス環境と統一したポリシー管理が必要な場合に選択します。既存のオンプレミスNGFWと同一ベンダーのクラウド版を使いポリシーを統一する運用は、ハイブリッドクラウド環境での一貫したセキュリティポリシー管理を実現します。

4. ポリシー適用&スコープ — アカウント × OU × タグ × 自動修復

ポリシーをどの範囲に適用し、非準拠リソースをどう扱うかは、Firewall Manager運用の要です。本セクションでは、スコープ指定と自動修復の挙動を解説します。

4-1. スコープ設計の3軸—アカウント・OU・タグフィルタリング

Firewall Managerのポリシーに「対象」を指定するためのスコープ設計は、3つの軸で構成されます。適切な組み合わせにより、保護対象を必要最小限に絞りながら、新規リソースへの漏れのない適用を実現できます。

アカウント指定（包含と除外）

スコープ設定の最も基本的な軸が「アカウント指定」です。ポリシーを適用するアカウントを明示的にリストアップする「アカウント包含」と、適用対象から外す「アカウント除外」の2種類があります。

• アカウント包含: Organizations配下の特定アカウント（例: 本番環境アカウントのみ）を対象として指定します。新規アカウントを自動カバーするには「組織全体」か「OU指定」を使います。
• アカウント除外: サンドボックスアカウントやテストアカウントのように、ポリシーを適用したくないアカウントを除外リストに追加します。除外リストは後述するOU指定と組み合わせることで、より精密な制御が可能です。

アカウントIDの直接指定は確実ですが、アカウント増減に追従できません。組織の成長に合わせてスコープを動的に維持するには、OU指定やタグフィルタリングを主軸にすることを推奨します。

OU指定

AWS Organizationsの組織ユニット（OU）を単位としてスコープを指定する方法です。

• 包含OU指定: 特定OU配下の全アカウントを対象にします。例えば ou-xxxx-production のOU配下の全アカウントにポリシーを適用できます。
• 除外OU指定: 特定OUを除外します。例えば ou-xxxx-sandbox のOU配下のアカウントをポリシー対象外にできます。

OU指定の最大の利点は、新規アカウントを対象OU配下に作成した瞬間から自動的にポリシーが適用される点です。アカウント追加のたびにポリシーを手動更新する運用が不要になり、「防御適用漏れ」リスクを構造的に排除できます。

タグフィルタリング（リソースタグによる対象絞り込み）

ポリシーが対象とするリソースをタグで絞り込む機能です。アカウントやOU全体ではなく、特定用途のリソースのみに適用したい場合に有効です。

代表的な設定例として、以下のタグ指定が挙げられます。

タグキー: Env
タグ値:prod

上記のように設定すると、Env=prod タグが付いたリソース（ALB・CloudFront DistributionなどのWAFポリシー対象リソース）のみにポリシーが適用されます。

• 包含タグ: 指定タグを持つリソースのみが対象
• 除外タグ: 指定タグを持つリソースをスコープから除外（例: SkipFWM=true タグで個別免除）

タグ戦略を設計する際は、タグの意味・命名規則・所有者をドキュメント化し、Organizations全体でタグポリシー（Tag Policies）を有効化して表記ゆれを防ぐことが重要です。

新規リソースへの自動適用

「Auto-apply to new in-scope resources」を有効にすると、スコープ内のアカウントで新規作成されたリソース（ALB・VPCなど）が自動的にポリシーの対象になります。インフラ展開のたびに手動でポリシーを適用する運用が不要になります。

この設定はデフォルトで有効化されており、Firewall Managerの主要な利便性の源泉です。ただし、意図しないリソースがスコープに入り余分なコストが発生するケースもあるため、タグフィルタリングと組み合わせてスコープを必要最小限に絞ることが重要です。

4-2. 自動修復（Auto-remediation）の挙動と制限

Firewall Managerのポリシーは、非準拠リソースへの対応方法として「検知のみ（Remediation disabled）」と「自動修復（Remediation enabled）」を選択できます。

検知のみモード（Remediation disabled）

非準拠リソースを検知してFirewall Managerコンソール・Security Hubに報告するだけで、自動的な変更は行いません。

• 設定変更は一切発生せず、既存リソースへの影響がない
• 組織の現状把握フェーズや、自動修復前の影響範囲確認に適している
• コンプライアンスダッシュボードで違反数の把握は可能

自動修復モード（Remediation enabled）

スコープ内で非準拠と判定されたリソースを自動的に修正します。

• 例: WAFポリシーのスコープ内ALBに指定のWebACLが紐付いていない場合、自動的にWebACLを関連付ける
• 新規作成リソースへの適用も自動化（Auto-apply to new in-scope resourcesと連動）
• 修復の実行ログはCloudTrailに記録される

自動修復の制限 — 全リソースタイプで使用可能とは限らない

自動修復の挙動はポリシータイプによって異なります。

一部のポリシータイプ（Security Groupの内容監査など）では、違反の性質によって自動修復できないケースがあります。自動修復不可の場合は「REMEDIATION_NOT_POSSIBLE」ステータスで記録されます。

自動修復のリスクと慎重な有効化判断

自動修復は「本番稼働中のリソース設定を自動変更する」ことを意味します。以下のリスクを正しく認識したうえで有効化を判断してください。

段階的な有効化パターン

本番環境で安全に自動修復を有効化するには、以下の段階的アプローチを推奨します。

1. 検知のみモードで開始: まず検知のみで現状の非準拠リソースを把握します。
2. 影響範囲の確認: 非準拠リソースのリストを確認し、自動修復が与える変更内容を事前検証します。
3. テスト環境で先行有効化: 本番前に開発・検証環境のOUでのみ自動修復を有効化してテストします。
4. 本番有効化: 影響範囲を確認済みの本番環境で段階的に有効化します。

# 自動修復の現在の設定を確認するCLIコマンド例
aws fms get-policy \
  --policy-id <policy-id> \
  --query 'Policy.RemediationEnabled'

4-3. 適用順序・新規アカウント自動適用・RAM連携

Firewall Manager環境が成長し、複数の管理者や複数のポリシーが存在するようになると、「どのポリシーがどの順番で適用されるか」「新規アカウントはいつから保護されるか」「Resource Access Managerとどう連携するか」が重要な運用課題となります。

複数ポリシーの適用順序

同一リソースに複数のFirewall Managerポリシーが適用される場合（例: 管理者Aと管理者BがそれぞれWAFポリシーを定義している場合）、ポリシーはコンソールで表示される順序（番号付き）で評価されます。

• 評価順序は管理コンソールのポリシーリストで確認・変更が可能
• 「強制（Forced）」と「非強制（Non-forced）」の区別が重要

「強制/非強制」の使い分けガイドライン

本番環境では「非強制」で開始し、影響が確認できたら「強制」に切り替える段階的アプローチが安全です。

新規アカウント追加時の自動適用（Organizations新メンバー自動カバー）

Firewall Managerのポリシースコープに「組織全体」または「特定OU」を指定していると、Organizationsに新規アカウントが追加された際（または既存アカウントが対象OUに移動した際）に自動的にポリシーが適用されます。

この挙動により、以下のメリットが得られます。

• Landing ZoneやControl Towerで自動作成されるアカウントも即座に保護される
• アカウント払い出しチームがFirewall Manager設定を意識しなくても、組織標準のセキュリティベースラインが自動適用される
• 新規アカウントへの「防御適用漏れ」が構造的に防止される

注意点として、新規アカウントでAWS Config Recorderを有効化していることが必須です。Config未有効の場合、ポリシーは適用されません。また、大量のアカウントへ一斉適用する場合、Network Firewallなど従量制サービスの料金が急増する点にも注意してください。

Resource Access Manager（RAM）との連携

Firewall Managerは、AWS RAMを通じて共有されるリソース（VPCサブネット・Transit Gatewayなど）に対してもポリシースコープの設定が機能します。

中央検査VPCに配置したFirewallをRAMで共有されるアタッチメント（サブネット）に対して適用することで、Hub-and-Spoke構成での一元的なトラフィック検査が可能です。

# Firewall Managerポリシーの準拠状態一覧を確認するコマンド
aws fms list-compliance-status \
  --policy-id <policy-id> \
  --query 'PolicyComplianceStatusList[*].{Account:MemberAccount,Status:PolicyComplianceDetail.EvaluationResults}'

管理者間の権限境界とポリシー競合の防止

multi-admin機能（最大10管理者アカウント）を利用する場合、各管理者に「管理可能なポリシータイプ」「管理可能なOU/リージョン」を明確に割り当てることで、意図しない競合を防止します。

推奨設計の例を以下に示します。

• セキュリティチームA: WAFポリシーのみ（本番OUのみ対象）
• セキュリティチームB: Network Firewallポリシーのみ（全OU対象）
• コンプライアンスチーム: Security Group監査ポリシー（全OU・全リージョン）

各管理者アカウントのスコープが重複しないように設計することで、同一リソースへの競合する自動修復の発生を防ぎます。

5. コンプライアンス&ドリフト検知 — 準拠状態 × 違反検知 × 自動是正 × 通知

Firewall Managerは、配信したポリシーに対する各アカウントの準拠状態を継続的に評価します。本セクションでは、ドリフト検知・違反通知・自動是正の仕組みを解説します。

5-1. 準拠状態モニタリング

Firewall Managerは、配信したポリシーに対する各アカウント・リソースのコンプライアンス状態を継続的に評価し、管理コンソールのダッシュボードで組織全体の準拠状況を一元的に確認できます。

コンプライアンス状態の3区分

準拠状態は次の3種類で表されます。

「不明」はFirewall Managerがリソース状態を評価できない場合に表示されます。各メンバーアカウントでAWS Configが有効化されていない・Configレコーダが停止している・リソースタイプがConfigの記録対象外であるといったケースが該当します。「不明」リソースは非準拠とは異なりますが、評価ができていない状態のため定期的な確認が必要です。

ダッシュボードの構成と読み方

Firewall Managerコンソールの「Compliance」ビューでは、次の情報を確認できます。

• ポリシー別サマリ: 各ポリシーに対する準拠・非準拠・不明のリソース数と準拠率
• アカウント別ドリルダウン: 特定のポリシーを選択すると、対象アカウントごとの準拠状態が表示される
• リソース別詳細: 非準拠アカウントを選択すると、違反リソースのARN・違反タイプ・検知時刻が一覧表示される

準拠率はポリシーに含まれる対象リソース総数に対する準拠リソースの割合で算出されます。組織全体で数百のアカウントを運用している場合でも、このビューから非準拠の集中しているOUやアカウントを絞り込めます。

AWS Configとの連携による継続評価

Firewall ManagerはバックエンドでAWS Configのリソース設定情報を参照しています。Configが各メンバーアカウントで有効化されていることが、コンプライアンス評価の前提条件です。

評価タイミングは主に次の2種類です。

1. 変更イベント駆動評価: リソース設定が変更されたとき（セキュリティグループのルール変更・WebACL関連付けの解除など）にConfigが変更を検知し、Firewall Managerが即時に再評価します
2. 定期評価: 定期スキャンにより、変更イベントを逃したリソースも評価対象になります

Configレコーダが停止している場合や、特定リソースタイプが記録対象外の場合は、Firewall Managerへの設定変更通知が届かず「不明」状態が継続します。Organizations管理者は全メンバーアカウントのConfig有効化状況をService Control Policyで強制することを推奨します。

評価結果のAPI取得

コンソールに加え、AWS CLIでも準拠状態を取得できます。

# ポリシーへの対象アカウントごとの準拠状態取得
aws fms list-compliance-status \
  --policy-id <POLICY_ID> \
  --region us-east-1

# 特定アカウントのリソース非準拠詳細取得
aws fms get-compliance-detail \
  --policy-id <POLICY_ID> \
  --member-account <ACCOUNT_ID> \
  --region us-east-1

返却されるIssueDetail内のViolationReasonフィールドに、違反の具体的な理由が格納されます。これをCloudWatch LogsやS3に蓄積することで、組織全体の違反傾向を分析できます。

5-2. ドリフト検知と違反通知

ドリフトとは

ポリシー適用後にリソース設定がポリシー要件から外れた状態を「ドリフト」と呼びます。例えば、Firewall Managerの配信した共通セキュリティグループのルールが手動で変更された場合や、WebACLの関連付けを解除した場合などが典型例として挙げられます。ドリフトはConfigの設定変更検知をトリガーとして即時に捕捉されるため、逸脱から検知までのタイムラグは数分以内に収まります。

代表的な違反タイプ

Firewall Managerが検知する代表的な違反タイプを次に示します。

これらの違反タイプはGetComplianceDetailのViolationReasonで確認でき、自動化スクリプトで種別ごとに対応フローを分岐させることができます。

SNS連携による違反通知

Firewall Managerポリシーの作成時にAmazon SNSトピックを指定することで、非準拠リソースが検知されるとSNS経由で通知を受け取れます。

通知に含まれる主な情報は次のとおりです。

• 違反が検知されたアカウントID
• 対象リソースのARN
• 違反タイプ（ViolationReason）
• 検知タイムスタンプ

クロスアカウント通知が必要な場合は、管理者アカウントのSNSトピックからメンバーアカウントのメールアドレスやAWS Chatbot経由でSlackをサブスクライブします。これにより、違反が発生したアカウントの担当者へ直接通知できます。

EventBridge連携

Firewall ManagerはイベントをAmazon EventBridgeに発行します。イベントのsourceはaws.fmsです。EventBridgeルールを作成することで、違反検知イベントをLambdaやStep Functionsと組み合わせた自動ワークフローに接続できます。

{
  "source": ["aws.fms"],
  "detail-type": ["Firewall Manager Policy State Change"],
  "detail": {
 "policyId": ["<POLICY_ID>"]
  }
}

このイベントルールにLambda関数を紐付け、JiraやServiceNowへのチケット自動起票や、Slackへのリアルタイム通知を実装するパターンが広く使われています。

Security Hub連携（ASFF形式）

Security Hubを有効化してFirewall Managerとの統合を有効にすると、違反検知の結果がSecurity HubのFindingとして集約されます。FindingはASFF（Amazon Security Finding Format）に準拠しており、他サービスのセキュリティイベントと統一したビューで管理できます。

重大度マッピングの例は次のとおりです。

Security Hubのインサイト（Insights）機能を使うと、「どのポリシーで最も多く違反が発生しているか」「違反の多いアカウントはどこか」を集計・可視化できます。GuardDutyやInspectorのFindingとFirewall Managerの違反を同一ダッシュボードで管理することで、組織全体のセキュリティ態勢を統一的に把握できます。

5-3. 自動是正のワークフローと注意点

自動是正が実行される条件

ポリシー設定でAuto-remediationを有効化すると、非準拠リソースが検知された時点でFirewall Managerが自動的に設定を修復します。ポリシータイプに応じた是正アクションは次のとおりです。

検知から是正までの時系列フロー

Auto-remediationが有効な場合の典型的なフローを示します。

1. リソース設定変更: メンバーアカウントの担当者が誤ってWebACLの関連付けを解除
2. Config変更検知: 数秒〜1分以内にAWS Configがリソース変更を記録
3. 非準拠判定: Firewall ManagerがConfigデータを参照してポリシー違反を検知
4. 自動是正実行: Firewall ManagerがWebACLを対象リソースへ自動的に再関連付け
5. 準拠状態に更新: コンプライアンスダッシュボードが「準拠」に更新される
6. 通知送信: SNSおよびSecurity Hubへ是正完了の通知が送信される

変更検知から是正完了までの所要時間はリソースタイプによって異なりますが、通常は数分以内に完了します。

手動是正フロー（view-onlyモード）

Auto-remediationを無効化したview-onlyモードでは、非準拠の検知と通知のみが行われ、設定の修復は実施されません。手動是正フローは次のとおりです。

1. SNS/EventBridge通知が違反アカウントの担当者に送信される
2. 担当者がFirewall Managerダッシュボードで違反内容と対象リソースを確認する
3. 違反の原因（意図的な変更か誤操作かを判断）を調査する
4. 必要に応じてポリシー例外を設定するか、リソース設定を手動で元に戻す
5. 是正後にダッシュボードで「準拠」に更新されることを確認する
6. 是正対応の記録をエビデンスとして保管し、承認者に報告する

コンプライアンスレポートの自動生成と監査対応

Firewall Managerコンソールの「Reports」セクションから、ポリシー別・アカウント別のコンプライアンスレポートをCSV形式でエクスポートできます。レポートには次の情報が含まれます。

• ポリシー名・ポリシーID
• アカウントID・リソースARN
• 準拠状態（Compliant / Non-Compliant / Unknown）
• 違反タイプと検知時刻

定期的（月次・四半期など）にレポートを自動エクスポートし、S3バケットに保存するLambdaを構成することで、監査証跡の継続的な蓄積が可能です。PCI DSS・SOC 2・ISO 27001などの監査対応では、このレポートをエビデンスとして提出できます。

# コンプライアンス状態の一覧取得（CLIでの確認）
aws fms list-compliance-status \
  --policy-id <POLICY_ID> \
  --region us-east-1 \
  --query 'PolicyComplianceStatusList[*].{Account:MemberAccount,EvaluationResults:EvaluationResults}'

警告: 自動修復を過信してはいけない

6. 運用・監視・コスト

Firewall Managerは強力な統制機能を提供する一方、運用設計とコスト構造の理解が欠かせません。本セクションでは、監視・コスト・トラブルシュートを解説します。

6-1. Firewall Managerダッシュボード・Security Hub統合・CloudWatchアラーム

Firewall Managerコンソールの「Security policies」画面では、各ポリシーのコンプライアンス状態を組織全体で一元確認できます。各ポリシーの概要画面には「Compliant accounts」「Noncompliant accounts」のカウントが表示され、非準拠アカウントをクリックすると、どのリソースが違反しているかまでドリルダウンできます。

コンプライアンスダッシュボードの活用

コンプライアンスの可視化画面で確認すべき観点は以下のとおりです。

• ポリシー適用カバレッジ: 対象アカウント数に対して準拠アカウントが何件か。カバレッジ率100%を目標に、非準拠が1件でも発生した場合は即座にアラートを受け取る設計を推奨します。
• 非準拠リソースの詳細: 非準拠ステータスのアカウントを選択すると、対象リソース（ALB・VPC等）の詳細と違反理由が確認できます。
• 自動修復の履歴: 自動修復を有効にしている場合、修復アクションのログをCloudTrailで確認できます。修復が繰り返し失敗しているリソースは個別調査が必要です。
• multi-admin環境での分布: 複数の管理アカウントを使っている場合、各管理アカウントが担当するポリシーのコンプライアンス分布を個別に確認します。

定期レビューの運用設計

Firewall Managerのダッシュボードを週次・月次のセキュリティレビューに組み込むことで、防御統制の継続的な改善が可能になります。レビュー時に確認すべき項目は次のとおりです。

1. 新規に検出された非準拠アカウント・リソースの有無と原因分析
2. 自動修復が繰り返し失敗しているリソースの調査と対処
3. ポリシー適用スコープ外リソースの意図的な除外確認（意図しない除外がないか）
4. ポリシー定義そのものの見直し（新しいリソースタイプへの対応等）
5. 月額ポリシー費用の実績確認

Security Hub統合による違反検知の集約

Firewall ManagerはSecurity Hubとネイティブに統合されており、コンプライアンス違反をSecurity Hub Findingとして自動送信します。Security Hubを有効化（Firewall Manager管理者アカウント内）すると、各アカウントのFirewall Manager違反が組織全体のセキュリティ態勢の一部として集約されます。

Security HubのFindingには以下の情報が含まれます。

• ProductName: “Firewall Manager”
• Types: “Software and Configuration Checks/Policy Drift”
• Resources: 違反しているリソース（ALB ARN等）
• Compliance.Status: FAILED
• Remediation.Recommendation: 修復手順の参照

Security Hubの「Findings」画面でProductNameフィルタを「Firewall Manager」に設定することで、防御ポリシー違反だけを絞り込んで確認できます。GuardDutyの脅威検知・ConfigルールのFindingと並べて、組織全体のセキュリティ態勢をCSPM視点で管理できます。

CloudWatchメトリクス連携とEventBridgeアラーム設定

Firewall Manager自体が直接発するCloudWatchメトリクスは限られていますが、連携する防御サービスのメトリクスと組み合わせることで包括的な監視が実現できます。

Firewall Managerで配信したWAFポリシーの各リソースは、CloudWatch上でAWS/WAFV2名前空間にメトリクスを発します。ALB・CloudFront・API GatewayごとにBlockedRequests・AllowedRequests・CountedRequestsが収集されます。

非準拠検知をリアルタイムに届けるには、Security Hub → EventBridgeルール → SNS通知のパターンが推奨されます。EventBridgeルールの例は以下のとおりです。

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
 "findings": {
"ProductArn": [
  {"prefix": "arn:aws:securityhub:*:*:product/aws/firewall-manager"}
],
"Compliance": {
  "Status": ["FAILED"]
}
 }
  }
}

このルールにより、Firewall Managerが非準拠を検知した瞬間にSNS通知が発火します。通知を受けた担当者は、Firewall Managerコンソールで対象リソースと違反内容を確認し、自動修復の対象とするか手動対応するかを判断します。

6-2. コスト構造と最適化

Firewall Managerのコスト体系

Firewall Managerのコストは、管理ポリシー単位の費用と、保護リソースに紐付く防御サービスコストの2階層で構成されます。

ポリシー管理費用

• ポリシー1件あたり: $100/月（リージョン単位）
• 同一リージョンに5ポリシーを設定した場合: $500/月
• マルチリージョン展開（東京・バージニア等）では、リージョン数分の費用が発生します。東京と北部バージニアの2リージョンで同じポリシーを展開すると、ポリシー1本あたり$200/月になります。

防御サービス自体のコスト（別途発生）

Firewall Managerで配信したポリシーに紐付く防御サービスの料金は別途発生します。

Shield Advancedをマルチアカウントで展開する際は、$3,000/月の料金がアカウントごとに積算される可能性があります。Firewall ManagerでShield Advancedポリシーを全アカウントへ展開する場合、事前の費用試算が必須です。

コスト最適化の実践

ポリシースコープの絞り込みによって、不要なコストを削減できます。

• OUターゲティング: 本番環境OUのみをポリシー対象とし、開発・サンドボックスOUを除外することで、保護リソース数と関連コストを削減できます。
• リソースタグフィルタリング: Environment: productionタグの付いたALBのみWAFポリシーを適用し、開発ALBを除外します。タグポリシーと組み合わせることで、タグ付けルールの徹底とコスト管理を両立できます。
• ポリシー統合: 同一スコープに複数のWAFルールグループを適用したい場合は、1つのWAFポリシー内で複数のルールグループを定義し、ポリシー本数を最小化します。

不要になったポリシーを放置すると$100/月が継続的に課金されます。月次のコストレビュー時にCost Explorerでサービス別コストを確認し、利用実績のないポリシーを削除する運用習慣が重要です。

CloudFrontを使用する場合はus-east-1にのみWAFポリシーを配置すれば十分で、他リージョンへのポリシー展開は不要です。すべてのリージョンに同一ポリシーを展開するのではなく、ワークロードが実際に存在するリージョンのみに絞ることでコストを最適化できます。

6-3. トラブルシュート

Firewall Managerの運用でよく発生するエラーと対処方法を示します。

トラブル1: ポリシーを作成しても対象アカウントに適用されない

原因として最も多いのは、対象アカウントでAWS Configが有効化されていないケースです。Firewall ManagerはConfigを使ってリソースを検出するため、Configが無効なアカウントはポリシー適用対象として認識されません。

対処: AWS Configアグリゲーターで各アカウントのConfig有効化状態を確認し、未有効アカウントにConfig有効化のStackSetを展開します。StackSetsを使うことで、Organizations全体へ一括展開できます。

トラブル2: 委任管理者を設定したが権限エラーが発生する

Firewall Manager管理者として委任管理者アカウントを設定する際、手順の実行者を誤ると権限エラーになります。aws fms associate-admin-account --admin-account <account-id> はOrganizations管理アカウントから実行する必要があります。委任管理者アカウントのコンソールで設定しようとするとエラーになります。

対処: 設定コマンドをOrganizations管理アカウントのAWS CLIプロファイルで実行していることを確認します。設定後、委任管理者アカウントのFirewall Managerコンソールでポリシー作成が可能になっていることを確認します。

トラブル3: 自動修復が繰り返し失敗する

自動修復が成功した直後から再び非準拠状態となる場合、対象チームが独自の設定変更によってオーバーライドしている可能性があります。

対処: CloudTrailでFirewall Managerの修復アクションと、その直後のリソース変更イベントを時系列で追跡します。繰り返し非準拠にするAPIコールの発生源（IAMロール・Lambda・IaCツール等）を特定し、そのロールに対してFirewall Manager管理ポリシーを上書きできないようアクセス制御を見直します。

トラブル4: スコープ指定の包含・除外ミスによる適用漏れ

アカウントIDリストによるスコープ指定では、新規追加されたアカウントが自動的に対象になりません。OUを指定する場合、そのOU配下に新規アカウントが追加されると自動的に対象になりますが、アカウントIDリストによる指定では新規アカウントは含まれません。

対処: スコープ指定はOUベースを推奨します。OUベースであれば、新規アカウントを対象OUに移動するだけで自動的にポリシーが適用されます。アカウントIDリストによる指定は、例外的な除外にのみ使用します。

トラブル5: ポリシー削除時に防御リソースが残存する

Firewall Managerポリシーを削除する際、デフォルトでは配信した防御リソース（WAFのWebACL等）が各アカウントに残存します。ポリシー削除時に「Delete resources created by this policy」を選択することで、Firewall Managerが作成したリソースを一括削除できます。このオプションを見落とすと孤立したWAFリソースが残り、WAF料金が継続発生します。

トラブル6: multi-admin環境での権限境界の混乱

複数の管理アカウントを設定したmulti-admin環境では、管理アカウントAのポリシーと管理アカウントBのポリシーが同一リソースに同時に適用されることがあります。両ポリシーの要件を満たさない限りそのリソースは非準拠として報告されるため、ポリシー間の整合性確認が必要です。

対処: multi-admin設定時には各管理アカウントの担当範囲（ポリシータイプ・OU）を明示したドキュメントを整備し、重複適用が意図的なものかを確認できるようにします。

IAM権限設計

Firewall Manager管理者アカウントで作業するユーザー・ロールには、AWSFMAdminFullAccessマネージドポリシーの付与を推奨します。ポリシーの読み取りのみを行う監査担当者にはAWSFMAdminReadOnlyAccessを付与し、最小権限を徹底します。メンバーアカウント側では、Firewall Managerが自動的にサービスリンクロール（AWSServiceRoleForFMS）を作成し、防御リソースの作成・修復に必要な権限を管理します。

サービスリンクロールの自動作成はFirewall Managerが初めてポリシーを適用する際に行われます。IAM権限の問題でロール作成に失敗した場合、ポリシー適用自体が完了しないため、事前に必要なIAM権限を確認してください。

7. 実戦統合パターン—WAF・Shield・Network Firewall横断統制とマルチアカウント基盤

本セクションでは、Firewall Managerを組織の防御基盤として活用するための実践的な統合パターンを解説します。個別の防御サービスとの連携から、大規模環境でのスケール設計まで、本番運用に直結する設計を網羅します。

7-1. エンタープライズ多層防御アーキテクチャ

エッジ/VPC/DNS層の3層統合

Firewall Managerを使った多層防御は、次の3つの防御層を統合することで実現します。

[インターネット]
↓
エッジ層: CloudFront + WAF（WAFポリシーで全CloudFront distributionに自動適用）
↓
VPC層: Network Firewall（Firewallポリシーで全VPCのサブネットに自動配備）
↓
DNS層: Route 53 DNS Firewall（DNS Firewallポリシーで全VPCに適用）
↓
[アプリケーション]

各層が独立して機能するため、エッジ層の攻撃をまず遮断し、すり抜けた攻撃をVPC層でインスペクション、DNSトンネリングやC2通信をDNS層でブロックするという多段フィルタリングが実現します。Firewall Managerはこの3層をOrganizations全体に対して一括適用します。各アカウントが個別に設定する運用と比べ、設定の一貫性と新規アカウントへの即時適用が保証されます。

Organizations OU構造ベースのポリシー設計

実践的な運用では、OU構造に合わせてポリシーの適用範囲を設計します。典型的な3段階設計を次に示します。

OU単位のポリシー設計では、IncludeMapでOUのARNを指定します。将来追加されるOUも自動でスコープに含まれるため、アカウント増加への追従が保証されます。ExcludeMapで特定のアカウント（テストアカウント等）を除外できます。

Security Hub/GuardDutyとのセキュリティツールチェーン統合

Firewall Managerの検知結果をSecurity Hubに送信することで、組織全体のセキュリティイベントを一元的に可視化できます。設定フローは次のとおりです。

1. Security Hubを組織の管理アカウントで有効化し、全メンバーアカウントへ自動有効化を設定
2. Firewall ManagerのポリシーでSNS通知を有効化し、非準拠イベントをEventBridgeへ転送
3. EventBridgeルールでSecurity Hub Findingsへ変換して連携

GuardDutyが脅威を検出した際、Firewall ManagerのWAFポリシーを自動更新してIPをブロックするパターンも有効です。GuardDuty FindingsからEventBridge→Lambda経由でFirewall ManagerのIPセットを動的に更新することで、自動対応基盤を構築できます。

# EventBridgeルール（GuardDuty検知からFMのIPセットを自動更新するLambda起動）
aws events put-rule \
  --name "GuardDutyToFMSIPSet" \
  --event-pattern '{
 "source": ["aws.guardduty"],
 "detail-type": ["GuardDuty Finding"],
 "detail": { "type": ["UnauthorizedAccess:EC2/MaliciousIPCaller"] }
  }'

WAF・Shieldの多層防御設計について詳しくは、既存のCloudFront WAF Shield多層防御記事を参照してください。

7-2. マルチアカウント基盤との連携

Landing Zone / Control Towerとの統合

AWS Control Towerを使ったLanding Zoneと連携することで、新規アカウント作成時に防御ポリシーが自動適用されます。Account Factory for Terraform（AFT）と組み合わせると、次の自動化フローが実現します。

1. Account Factoryでアカウントを作成（AFT経由でIaC定義から自動生成）
2. 指定したOUに自動配置（Control Tower機能）
3. Firewall ManagerのポリシースコープにOUが含まれる場合、自動的にポリシー適用を開始
4. AWS Config有効化（Control Towerが自動設定）→ Firewall Manager依存充足
5. WAF・Network Firewall・DNS Firewallエンドポイントの自動作成（Firewall Manager自動修復）

このフローにより、新規アカウント作成から防御設定完了までのリードタイムがゼロに近くなります。手動運用では避けられないセキュリティ設定の漏れを根本的に排除できます。

委任管理の集約と責務分割

大規模な組織では、Firewall ManagerのMulti-admin機能（最大10管理アカウント）を使って責務を分割します。

• セキュリティ基盤チーム: 全組織共通のWAF・Shield Advancedポリシーを管理
• ネットワークチーム: Network Firewallポリシー（VPCルーティング変更を伴う）を管理
• 各部門のセキュリティ担当: 自部門配下のOUのSGポリシーを管理

Multi-admin機能ではそれぞれの管理アカウントに担当範囲のポリシーだけを制御できる権限境界を設定します。例えば、ネットワークチームの管理アカウントにはNetwork Firewallポリシーのみ、セキュリティ基盤チームにはWAF・Shield Advancedポリシーのみを許可する形で責務を分離できます。

ゼロトラスト移行パス

従来の境界型防御からゼロトラストアーキテクチャへの段階的移行において、Firewall Managerは重要な役割を担います。移行ステップの例を次に示します。

1. フェーズ1: Firewall ManagerでSGポリシーのコンテンツ監査を有効化 → 過剰な許可ルールを可視化
2. フェーズ2: SGポリシーの自動修復で不正ルールを削除 → 最小権限の境界ルールを確立
3. フェーズ3: Network Firewallポリシーでマイクロセグメンテーションを段階適用
4. フェーズ4: DNSベースのゼロトラストアクセス（Route 53 Resolver DNS Firewallポリシー）
5. フェーズ5: AWS Verified Accessやプライベートアクセスパターンへの移行

各フェーズでFirewall Managerが中心的な役割を担うことで、段階的な移行と組織全体への一括適用が両立します。Network Firewallの詳細な設定パターンは、AWS Security 本番運用 Vol4で解説しています。

7-3. 大規模環境でのポリシー管理とスケール設計

タグ戦略とポリシースコープ

数百アカウントの環境では、タグベースのスコープ設計がスケーラビリティに直結します。OU構造だけでは表現できない横断的なグルーピングをリソースタグで実現します。推奨タグ設計の例を次に示します。

Key: security-tier Value: critical | standard | dev
Key: compliance Value: pci-dss | hipaa | soc2 | internal
Key: waf-policy Value: strict | standard | bypass-testing

Firewall ManagerのポリシースコープでResourceTagsを組み合わせると、「security-tier: criticalのALBにのみ高感度WAFルールを適用」「compliance: pci-dssのVPCにNetwork Firewallを強制」といった精緻な制御が可能です。タグを新規リソースへ付与した瞬間からFirewall Managerの評価対象となるため、タグ戦略と自動タグ付け（AWS Configルール＋Systems Manager）を組み合わせると保護漏れを防ぐ自動化ループを形成できます。

自動修復のスケール設計

自動修復を組織全体で一斉有効化すると、修復アクションが大量に同時実行されます。サービス影響を抑えるため、段階的なロールオーバー戦略を次に示します。

1. Step 1: 新規作成リソースのみ自動修復（既存への影響なし）
2. Step 2: ステージング環境OUに自動修復を適用 → 問題なければ拡大
3. Step 3: 本番OUに自動修復を適用（メンテナンスウィンドウ中に段階適用）

# 自動修復を後から有効化（既存ポリシーを段階的に修復モードへ移行）
POLICY_JSON=$(aws fms get-policy --policy-id "${POLICY_ID}" --query 'Policy' --output json)
UPDATED=$(echo "${POLICY_JSON}" | jq '.RemediationEnabled = true')
aws fms put-policy --policy "${UPDATED}" --region us-east-1

Organizations委任管理者との整合確認

マルチアカウント基盤の委任管理と統合する際、Firewall Managerの管理アカウントとOrganizationsの委任管理者との整合を事前に確認します。Firewall Manager管理アカウントは組織のマスターアカウント（管理アカウント）か、委任された管理者アカウントである必要があります。

# 現在のFirewall Manager管理者確認
aws fms get-admin-account --region us-east-1

# 委任管理者の設定確認（Organizations管理アカウントから実行）
aws organizations list-delegated-administrators \
  --service-principal fms.amazonaws.com

マルチアカウント基盤の構成管理の詳細については、マルチアカウント基盤 Vol2およびAWS Management & Governance 本番運用 Vol2を参照してください。

ポリシー棚卸しの定期運用

組織規模が拡大するにつれ、Firewall Managerのポリシー数も増加します。月次または四半期ごとに次の棚卸しを実施することで、過剰なポリシーや不要コストを防ぎます。

1. 適用対象ゼロのポリシーを特定し、不要であれば削除または統合する
2. 準拠率が継続して低いポリシーは、スコープ設計の見直しまたはルールの緩和を検討する
3. Network Firewallポリシーの未使用エンドポイントを確認し、コスト削減の余地を評価する

ポリシー棚卸しを定期化することで、組織のセキュリティ態勢を最新の脅威環境に合わせ続けることができます。

8. 詰まりポイントとアンチパターン・まとめ

Firewall Managerの本番運用では、横断統制ならではの落とし穴があります。本セクションでは、現場で頻出する詰まりポイントとアンチパターン、そして次のステップを示します。

8-1. よくある詰まりポイント

Firewall Managerの本番運用で現場が最初に詰まるのは「設定したはずなのに適用されていない」という状況です。横断統制特有の依存関係と挙動を理解しておくことで、多くのトラブルを事前に回避できます。

詰まりポイント1: AWS Config未有効化でポリシーが適用されない

症状: Firewall Managerでポリシーを作成・配信したが、リソースに適用されない。コンプライアンスダッシュボードにリソースが表示されない、または「不明」と表示される。

原因: 対象アカウント・リージョンでAWS Configが有効化されていないか、記録対象リソースタイプが不足している。Firewall ManagerはConfigのリソースインベントリを参照するため、Config未有効化環境ではリソースの存在を認識できない。

解決策: aws configservice describe-configuration-recorder-status --region [REGION] で各アカウント・リージョンのConfig状態を確認する。未有効化のアカウントはConfigを有効化し、Firewall Managerが必要とするリソースタイプを記録対象に追加する。Configの有効化後、リソースの初回スキャンが完了するまで数分〜数時間かかる場合があるため、即時反映を期待しないこと。

詰まりポイント2: 委任管理者の設定順序ミス

症状: aws fms associate-admin-account を実行すると OrganizationNotInAllFeaturesMode エラーが発生する。

原因: AWS Organizations全機能有効化（All features）が完了する前に委任管理者設定を試みた。または全機能有効化のリクエストを送ったが、すべてのメンバーアカウントがまだ承認していない状態。

解決策: aws organizations describe-organization --query 'Organization.FeatureSet' で "ALL" が返ることを確認してから委任管理者を設定する。全機能有効化への移行は全メンバーアカウントの承認が必要なため、完了まで数日かかる場合がある。承認状況はOrganizationsコンソールの「招待の管理」から確認できる。

詰まりポイント3: multi-admin設定後も既存ポリシーが見えない

症状: multi-admin機能を有効化し、新たな管理アカウントでFirewall Managerにアクセスすると、既存のポリシーが一切表示されない。

原因: multi-adminでは各管理アカウントはデフォルトで自分が作成したポリシーのみ参照可能。別の管理アカウントが作成したポリシーは見えない仕様。これはFirewall Managerのセキュリティ設計による意図的な動作。

解決策: 既存ポリシーの管理をデフォルト管理者（従来の委任管理者）に集約したまま維持するか、既存ポリシーを新管理アカウント配下に移管する手順を実施する。運用設計の段階で、どのアカウントがどのポリシーを管理するかを事前に決定しておくことが重要。

詰まりポイント4: スコープタグ設定ミスでリソースが対象外

症状: 特定リソースにポリシーが適用されない。Configには記録されているがFirewall Managerのコンプライアンス評価対象に現れない。

原因: ポリシースコープにリソースタグ条件を設定しているが、対象リソースにタグが付いていない、またはタグのキー・バリューが大文字小文字の不一致やスペルミスでマッチしていない。タグのキーは大文字小文字を区別するため、Environment: production と environment: production は異なるものとして扱われる。

解決策: Firewall Managerコンソールの「ポリシースコープ」設定でタグ条件を確認する。対象リソースのタグをAWS Resource Groups Tagging APIで正確なタグが付いているか検証する。組織全体のタグ命名規則を標準化し、Organizations Tag Policiesを活用してタグの一貫性を強制することをお勧めする。

詰まりポイント5: 自動修復が無限ループに陥る

症状: Firewall Managerが自動修復を繰り返し実行し続ける。Security Hubに同じ違反が何度も報告される。CloudTrailに修復アクションが連続して記録される。

原因: 自動修復で追加したルールや設定が、別のポリシーや既存設定と競合し、修復すると別の違反が発生するサイクルになっている。例として、Network Firewallのステートフルルールグループを自動修復で追加すると、既存のステートレスルールと競合して新たな違反が検知されるケース。

解決策: 自動修復を一時的に「検知のみ（view-only）」モードに変更して修復内容を確認する。修復ルールと既存設定の競合を手動で解消してから再度自動修復を有効化する。複数のFirewall Managerポリシーが同一リソースに適用されている場合は、ポリシー間の設定の整合性を確認する。

詰まりポイント6: Shield Advanced未加入でShieldポリシー作成失敗

症状: Firewall ManagerでShield Advancedポリシーを作成しようとするとエラーが発生する。または、ポリシーは作成できたがメンバーアカウントでShield Advancedの保護が適用されない。

原因: Firewall ManagerのShield Advancedポリシーは、対象アカウントがShield Advancedにサブスクライブしていることが前提条件。Firewall ManagerはShield Advancedを自動的に有効化しない。

解決策: 対象メンバーアカウントでShield Advancedサブスクリプションを事前に有効化する。Organizations全体に適用する場合はすべての対象アカウントでサブスクライブが必要。Shield Advanced費用（月$3,000〜）が発生するため、サブスクライブ前にコストとROIを評価する。

詰まりポイント7: サードパーティポリシーのMarketplace契約忘れ

症状: Palo Alto Networks、Fortinet等のサードパーティ製ファイアウォールのFirewall Managerポリシーを作成・配信したが、メンバーアカウントで防御リソースが作成されない。コンプライアンスダッシュボードに多数のNon-Compliantが表示される。

原因: サードパーティ製ファイアウォールのFirewall Managerポリシーは、メンバーアカウントでそのソフトウェアのAWS Marketplace契約が事前に必要。Firewall ManagerはMarketplace契約を自動的に行わない。

解決策: Firewall Manager導入前に、すべての対象アカウントでAWS Marketplace Private Marketplace等を使用してサードパーティソフトウェアの契約を完了させる。Organizations全体で一括承認できるMarketplace Private Offering機能の活用を検討する。

詰まりポイント8: ポリシー削除時の防御リソース残存

症状: Firewall Managerポリシーを削除した後も、各メンバーアカウントにWAF Web ACLやNetwork Firewallが残り続け、コストが発生し続ける。

原因: Firewall Managerポリシーを削除する際に「Firewall Managerが作成したリソースを残す」オプションが選択されていた。このオプションはFirewall Manager配下のリソースをOrphan（孤立）状態で残すため、削除後もコストが発生する。

解決策: ポリシー削除前に「削除時にFirewall Managerが作成したリソースを削除する」オプションを確認する。既にOrphanとなったリソースは各アカウントのコンソールまたはCloudFormationスタックから手動削除が必要。削除前に本番通信への影響がないことを確認してから実施する。

8-2. アンチパターン → 正解

以下に、Firewall Manager本番運用で頻出するアンチパターンとその正解アプローチを示します。

アンチパターン追記: AWS Configコスト見積もりをしないまま全アカウント有効化

全アカウント・全リージョンでのConfig有効化は、Firewall Managerの前提条件ですが、大規模Organizations（100〜1000アカウント）ではConfig料金が月額数万〜数十万円規模になることがあります。導入前にAWS Pricing Calculatorで試算し、不要なリソースタイプの記録を除外するコスト最適化を実施してから有効化することをお勧めします。

アンチパターン追記: 障害発生後に初めてview-onlyモードで設定を確認する

アンチパターン: 本番運用中に障害が発生してから、初めてFirewall Managerポリシーの設定を確認する。

問題: Firewall Managerは複数のポリシーが重なって適用されるケースがあり、意図しない設定が適用されている場合でも、コンプライアンスダッシュボードでは「準拠」と表示されることがある。障害発生後の調査では時間が限られており、複雑なポリシー構成の理解が困難になる。

正解: 定期的な運用レビューを設定し、view-onlyモードでのシミュレーション確認・ポリシー一覧の棚卸し・不要ポリシーの削除を月次で実施する。IaCでポリシーと差分を管理し、意図しない設定変更を検知できる体制を整える。

障害対応時のFirewall Manager切り分け手順

Firewall Managerが関係する障害発生時の初動手順を以下に示します。

1. 影響範囲の特定: どのアカウント・リソース・リージョンで障害が発生しているかを確認する
2. Firewall Manager関与の確認: コンプライアンスダッシュボードで対象リソースのポリシー適用状態を確認する
3. 自動修復の一時停止: 自動修復が原因の場合はポリシーをview-onlyモードに変更し、修復アクションを停止する
4. CloudTrail確認: 直近のFirewall Manager操作（ポリシー変更・自動修復実行）をCloudTrailで確認する
5. 個別防御サービスの確認: Firewall Managerポリシーに問題がない場合は、個別のWAF/Network Firewall設定を確認する

8-3. まとめと次のステップ

Firewall Manager本番導入前チェックリスト

Firewall Managerを本番環境へ導入する前に、以下のチェックリストを確認することをお勧めします。

前提条件の確認:
– [ ] AWS Organizations全機能有効化が完了している（FeatureSet: ALL）
– [ ] 信頼済みアクセスを有効化している（fms.amazonaws.com）
– [ ] 委任管理者アカウントを設置済みで、Organizations管理アカウントとは別アカウントになっている
– [ ] 全対象アカウント・全対象リージョンでAWS Configが有効化されている
– [ ] Configリソース記録にFirewall Managerが必要とするリソースタイプが含まれている
– [ ] Configコストの月次試算を実施し、承認を得ている

ポリシー設計と展開の確認:
– [ ] ポリシーのスコープ（対象OU・アカウント・リソースタグ）を設計済み
– [ ] 最初のポリシー展開はview-onlyモードで実施し、影響範囲を評価済み
– [ ] 自動修復の有効化前に、既存リソース設定との競合を確認済み
– [ ] ポリシー変更のIaC化とレビュープロセスを整備済み

通知・監視の確認:
– [ ] SNSトピックを設定し、コンプライアンス違反通知先を構成済み
– [ ] Security Hub統合を有効化し、Findingの集約先を設定済み
– [ ] EventBridgeルールを作成し、自動対応ワークフローと接続済み

コスト見積もりサマリー

Firewall Manager運用にかかるコストを事前に把握しておくことが重要です。

POC（概念実証）環境での試験的な運用から始め、コストを実測してから本番展開のスケールを決定することをお勧めします。

Vol1のまとめ

AWS Firewall Managerは、WAF・Shield Advanced・Security Group・Network Firewall・Route 53 DNS Firewallを組織横断で一元統制するオーケストレーターです。本記事で解説した重要ポイントを振り返ります。

• 前提条件の厳格さ: Organizations全機能有効化・委任管理者設定・全アカウント/全リージョンでのAWS Config有効化が必須。これを満たさないと、いかに優れたポリシーを作成しても適用されない
• multi-admin機能: 最大10管理アカウントで大規模組織のセキュリティチームに責務分割が可能。委任管理者（集中管理型）とmulti-admin（分散管理型）を組織規模と運用体制に応じて選択する
• 段階的な展開: 「検知のみ（view-only）」から「自動修復」への段階的移行が本番展開の安全策。自動修復を過信せず、ポリシーの影響範囲を十分に評価してから有効化する
• コスト設計: Firewall Manager本体の費用に加え、AWS Config（全アカウント/全リージョン）・配下の防御サービス（WAF/Network Firewall/Shield Advanced等）のコストを事前に試算する
• 削除時の注意: ポリシー削除時にリソース残存オプションを誤ると、Orphanリソースが各アカウントに残り続け、継続的なコストが発生する

詰まりポイント9（追加）: Configコスト急増（全アカウント有効化後）

症状: Firewall Manager導入後の翌月にAWS Configの請求額が大幅に増加し、想定外のコストが発生した。特に記録対象リソースタイプを制限していない環境で顕著。

原因: Firewall Manager導入時に全アカウント・全リージョンでAWS Configを有効化したが、デフォルト設定では「すべてのリソースタイプを記録」が有効化される。EC2インスタンス・EBSボリューム・セキュリティグループ等のリソース数が多い環境では設定項目の記録数が急増する。

解決策: Configレコーダーの設定で記録対象リソースタイプをFirewall Managerが必要とするもの（WAFv2 WebACL・ELB LoadBalancer等）に絞る。不要なリソースタイプ（Lambdaのバージョン・S3の詳細設定等）を記録対象から除外する。AWS Configダッシュボードの「設定項目の記録数」を定期的に監視し、異常増加を検知する仕組みを整える。

Vol2予告

本記事（Vol1）では、Firewall Managerの前提基盤・multi-admin・ポリシータイプ概要・コンプライアンス監視・よくある詰まりポイントを解説しました。Vol2では以下のトピックを予定しています。

• WAFポリシーの高度設定（マネージドルールグループの最適化・カスタムルール管理・バージョニング）
• Network Firewallポリシーの実践（ステートフル/ステートレスルールグループの設計パターン）
• DNS Firewallポリシーの活用（ドメインリスト管理・許可リスト/ブロックリスト運用）
• 大規模Organizations（500+アカウント）でのFirewall Manager運用パターン
• Terraformによるポリシーのコード管理（IaC化の実践手順）

運用における優先事項

Firewall Manager本番運用を安定させるための優先事項を以下に示します。

1. Configの全アカウント有効化を自動化（Control TowerのCustomizations for Control Tower等）
2. 違反通知パイプライン構築（SNS → Slack/PagerDuty or EventBridge → Lambda → チケット起票）
3. 週次コンプライアンスレポートのS3自動保存（監査対応）
4. Firewall Manager操作の変更管理プロセス確立（ポリシー変更はIaC + PRレビュー）
5. 定期的なFirewall Manager費用レビュー（月次での不要ポリシーの棚卸し）

個別防御サービスとFirewall Managerの責務分担

Firewall Managerを導入した後も、個別の防御サービス（AWS WAF・Shield Advanced・Network Firewall等）の深い理解は欠かせません。Firewall Managerは「配信・強制・コンプライアンス監視」を担い、個別防御サービスは「実際の通信フィルタリング・攻撃検知・遮断」を担います。

この2層構造を理解することで、問題発生時のトラブルシュートが効率的になります。たとえばWAFポリシーが適用されているにもかかわらず攻撃が通過している場合、原因はFirewall Manager層（ポリシー配信側）ではなくWAF側（ルール設定・マネージドルールグループのバージョン等）にある可能性が高いと判断できます。

Firewall Manager本番運用 Vol2では、各ポリシータイプの高度設定と大規模運用の実践パターンを解説します。引き続きお読みいただけると幸いです。