概要
VPC内を流れるIPパケットを「不正または不適切なコンテンツ」の観点で検査する場合、AWS上にはいくつかのアプローチが存在します。しかし、すべての監視手段がパケットの「中身」を見られるわけではありません。
VPC Flow LogsやNACLは通信のメタデータ（IPアドレス・ポート番号・バイト数など）を扱う仕組みであり、パケットのペイロード（実際のコンテンツ）を検査することはできません。一方、Host-based agentやEC2上のプロキシソリューション、AWS Network Firewallはパケットの中身まで確認できるディープパケットインスペクション（DPI）が可能です。
この記事では、VPCトラフィック検査における「メタデータ監視」と「コンテンツ検査」の違いを整理し、要件に応じた適切なアーキテクチャ選択の考え方についてまとめます。
この記事のメリット
- VPC Flow LogsやNACLなど各サービスが「何を取得できるか・できないか」を正確に理解できる
- ディープパケットインスペクション（DPI）が必要なユースケースで、適切なアーキテクチャを選択できる
- AWS Network FirewallやEC2プロキシなど、実際の構成パターンを比較できる
- 「検査要件に合ったソリューション選択」の判断軸が身につく
執筆者とキャラクター紹介
執筆者：土肥（とひ）
株式会社ジェニュインの代表であり元エンジニア。これまでオンプレミスと AWS 環境のインフラ業務を担当。AWS 認定資格の学習で得た知識を、ハンズオンとともに解説するのが得意。直近では新人の教育も行っており、これから技術を学ぶ方が納得できる解説を心がけています。基礎編・Cloud Practitioner の記事では、解説役としても登場します。
クラウドおさる
クラウドおさるはじめましてでござる。弊猿はクラウドおさる。IT インフラが異常に発達した猿山から、雲に乗って地上の AWS を学びに降りてきたのでござる。
クラウドおさる基礎編や Cloud Practitioner の記事では、とひさんに素朴な疑問をぶつける役でござるな。Security - Specialty などの記事では、要所でワンポイントや注意点をひとこと添えるでござる。
クラウドおさる猿山にもデータセンターや監視当番があって、地上で起きることはだいたい猿山にも同じ仕組みがあるのでござる。例え話がつい猿山に寄るのは、弊猿の癖でござる。
技術解説
メタデータ監視とコンテンツ検査の違い
VPCのトラフィック監視手段は大きく2つに分類できます。
メタデータ監視 通信の「誰が・いつ・どこに・どれだけ」を記録する仕組みです。通信が発生したという事実と通信先の情報はわかりますが、HTTPリクエストの中身やファイルの内容などペイロードの検査はできません。
コンテンツ検査（ディープパケットインスペクション） パケットのペイロードを実際に読み取り、URLパターン・シグネチャ・マルウェアパターンなどの基準で検査する仕組みです。「不正または不適切なコンテンツ」の検出にはこちらが必要です。
各アプローチの比較
| アプローチ | 検査対象 | コンテンツ検査 | 主なユースケース |
|---|---|---|---|
| VPC Flow Logs | 通信メタデータ（IP・ポート・バイト数） | ✗ | 通信ログの監査・異常トラフィックの検知 |
| NACL + NAT Gateway | IPアドレス・ポート番号 | ✗ | 特定IPやポートのブロック |
| CloudWatch Logs agent | OS・アプリケーションのログ | ✗ | アプリケーションログの収集・監視 |
| Host-based agent | OSネットワークスタックレベルのパケット | ✓ | エンドポイントIDS/IPS、マルウェア検知 |
| EC2プロキシ | HTTP/HTTPSのリクエスト・レスポンス | ✓ | URLフィルタリング、コンテンツポリシー適用 |
| AWS Network Firewall | ネットワーク・アプリケーション層 | ✓ | ステートフル検査、シグネチャベース検知 |
なぜVPC Flow Logsはコンテンツを閲覧できないのか
VPC Flow LogsはVPCのElastic Network Interface（ENI）レベルで通信を記録しますが、キャプチャする情報はネットワーク層（L3）とトランスポート層（L4）のヘッダー情報のみです。
記録されるフィールドの例：
- 送信元・宛先IPアドレス
- 送信元・宛先ポート
- プロトコル番号
- パケット数・バイト数
- 開始・終了時刻
- アクション（ACCEPT / REJECT）
アプリケーション層（L7）のペイロード、つまりHTTPのリクエストボディやURLのパスなどは含まれません。
Host-based agentによる検査
EC2インスタンスにIDS/IPSソフトウェアやエンドポイントセキュリティエージェントをインストールする方式です。
特徴:
- インスタンスのOSレベルでネットワーク通信を傍受し、ペイロードを検査できる
- 暗号化されたトラフィックも、TLS終端後の復号されたデータを検査できる（インスタンス内での処理のため）
- 各インスタンスに個別に設定が必要
代表的なソリューション:
- サードパーティのIDS/IPS・EDRエージェント
- Amazon GuardDuty ランタイムモニタリング（EC2・EKS・ECSのプロセス／ネットワーク挙動を検知）
Amazon Inspectorはエージェント（SSM Agent）を使いますが、行うのはソフトウェアの脆弱性スキャンとネットワーク到達性の分析であり、通信のペイロード検査ではありません。
EC2プロキシソリューション
VPC内にプロキシEC2インスタンスを配置し、すべてのアウトバウンドトラフィックをプロキシ経由でルーティングする方式です。
特徴:
- URLフィルタリングやコンテンツポリシーの適用が可能
- HTTPSトラフィックの検査にはSSL/TLSインスペクション（man-in-the-middle構成）の設定が必要
- ルートテーブルでプロキシEC2をデフォルトゲートウェイに設定し、トラフィックを集約する
構成時の注意点: プロキシEC2インスタンスは送受信するトラフィックの送信元・宛先が自分自身ではないため、Source/Destination Check（コンソールの「ソース/宛先チェック」）を無効化する必要があります。この設定をしないと、EC2は自分宛でないパケットを破棄してしまいトラフィックを転送できません。
実践
ここでは、VPCアウトバウンドトラフィックのコンテンツ検査を実現するパターンとしてEC2プロキシーの構成概要を説明します。
前提条件
- リージョン:
ap-northeast-1（東京） - 以下のリソースが作成済みであること
| リソース種別 | リソース名 | 用途 |
|---|---|---|
| VPC | inspection-vpc（10.90.0.0/16） | 検証用のVPC |
| サブネット | public-subnet（10.90.1.0/24） | プロキシEC2を置くパブリックサブネット |
| サブネット | private-subnet（10.90.2.0/24） | 検査対象のEC2を置くプライベートサブネット |
| ルートテーブル | private-rt | プライベートサブネットに関連付け済み |
| セキュリティグループ | proxy-sg | プロキシEC2に割り当て |
| EC2インスタンス | proxy-instance | パブリックサブネットで稼働するプロキシ |
EC2プロキシによる集約検査
構成概要
[プライベートサブネット] [パブリックサブネット]
EC2インスタンス群 → プロキシEC2（Squidなど） → インターネットゲートウェイ → インターネット設定手順
- プロキシEC2の準備
パブリックサブネットにEC2インスタンスを起動し、Squidなどのプロキシソフトウェアをインストールします。
- Source/Destination Checkを無効化
EC2コンソール → 左側ナビゲーションの「インスタンス」→ proxy-instance を選択 → 「アクション」→「ネットワーキング」→「ソース/宛先チェックを変更」を選択します。「送信元/送信先チェックを変更」ダイアログが開くので、「停止」にチェックを入れて「保存」をクリックします。
- ルートテーブルの変更
プライベートサブネットのルートテーブルで、デフォルトルート（0.0.0.0/0）の送信先をプロキシEC2インスタンスのENI IDに変更します。
- セキュリティグループの設定
プロキシEC2のセキュリティグループに、プライベートサブネットからのTCPポート80・443の受信を許可するルールを追加します。
- プロキシの設定ファイルでコンテンツポリシーを適用
Squidのsquid.confにブロック対象のURLパターンやドメインリストを記述します。
2で実施する「ソース/宛先チェック」を停止することで、プロキシーとなるインスタンスは自身のIPアドレス以外を宛先にしているトラフィックを処理することができます。
確認方法
プライベートサブネットのEC2インスタンスからcurlコマンドで外部URLにアクセスし、プロキシのアクセスログ（/var/log/squid/access.log）にリクエストが記録されることを確認します。ブロック対象のURLへアクセスすると、403 Forbiddenが返ることを確認できます。
—
要件別のアプローチ選択ガイド
| 要件 | 推奨アプローチ |
|---|---|
| パケットの中身（コンテンツ）を検査したい | Host-based agent / EC2プロキシ / AWS Network Firewall |
| 特定のドメインやURLをブロックしたい | EC2プロキシ（Squid） / AWS Network Firewall（ドメインリスト） |
| 既知の脅威シグネチャを検知したい | AWS Network Firewall（Suricataルール） |
| 管理コストを抑えてスケールしたい | AWS Network Firewall（マネージドサービス） |
| 通信の発生有無・通信先のIPを記録したい | VPC Flow Logs |
| 特定IPアドレスやポートをブロックしたい | NACL |
まとめ
VPC内のIPパケットをコンテンツの観点で検査するには、メタデータを記録するだけのサービスでは不十分です。以下の点が重要です。
- VPC Flow Logs はL3/L4のメタデータのみを記録し、ペイロードの検査はできない
- NACL はIPアドレス・ポート番号によるフィルタリングのみ対応し、コンテンツは検査できない
- CloudWatch Logs agent はOSやアプリのログを収集する仕組みであり、パケットデータを扱わない
- Host-based agent はインスタンス内部でネットワーク通信を傍受し、コンテンツ検査が可能
- EC2プロキシ はVPCのアウトバウンドトラフィックを集約し、URLフィルタリングやコンテンツポリシーを適用できる（ソース/宛先チェックの無効化が必須）
- AWS Network Firewall はマネージドサービスとしてステートフル検査・シグネチャ検知・ドメインフィルタリングを提供する
コンテンツ検査が必要な要件では、「メタデータしか取れないサービス」と「中身まで見られるサービス」の区別を意識してアーキテクチャを設計することが重要です。
