AWSネットワーク可観測性Vol1｜到達性分析・Flow Logs・Mirroring

1. ネットワーク可観測性の全体像と本記事の位置づけ

マルチアカウント環境でTransit GatewayやPrivateLinkによる接続基盤を構築した後、本番運用で必ず直面するのが「通信が到達しない」「想定外の経路でアクセスできてしまう」「どのフローがコストやレイテンシを生んでいるか分からない」という可観測性の課題です。本記事は、接続を「構築する」技術ではなく、構築済みのネットワークを「可視化・検証・トラブルシュートする」ための可観測性スタックを実践で設計する新シリーズVol1です。

本節（§1）では、本記事のゴール・想定読者像・既存記事との棲み分け・本シリーズが扱う3つのネットワーク可観測性能力・読み方ガイドを整理します。すでにネットワークトラブルシューティングの課題感をお持ちの方は§2から直接お読みいただけます。

ネットワーク可観測性の課題は、AWSの利用規模が大きくなるほど顕在化します。VPC数が増え、マルチアカウント構成が複雑化し、Transit Gatewayで接続するネットワークが広がるにつれ、「どのトラフィックがどこを通っているか」「なぜ特定の通信だけ到達しないか」「意図しない経路が開いていないか」を人手で把握することが難しくなります。AWSはVPC Flow Logs・Reachability Analyzer・Network Access Analyzer・Traffic Mirroring・CloudWatch Network Monitorなど、ネットワーク可観測性のためのフルマネージドサービス群を提供しており、本記事ではそれらを組み合わせた実践的な設計を解説します。

1-1. 本記事のゴール

本記事では、ネットワーク可観測性を実装する以下の3つの能力を身に付けることを目標とします。

① フローログ基盤の設計 — VPC Flow Logsによる通信の可視化

VPC Flow Logsの拡張フィールドと宛先（S3/CloudWatch Logs/Data Firehose）を設計し、Athenaでのパーティション分析まで含めた通信可視化基盤を構築します。どのIPが何のプロトコルで何バイト通信したかを、コスト効率よく長期保管・分析できる仕組みを整備することが目標です。NATの背後にある実際の送信元IPを把握する拡張フィールドの設計から、AWSサービス宛の通信を識別するフィールドの選定まで、ネットワーク可視化に特化した設計判断を解説します。

② 到達性・アクセス経路の検証 — Reachability AnalyzerとNetwork Access Analyzer

VPC Reachability Analyzerでポイント間の到達性をモデルベースで検証し、Network Access Analyzerでスコープ全体の意図しないアクセス経路を網羅的に検出します。本番環境へのパケット送信なしでネットワーク構成の正確性を継続検証する体制を設計します。CI/CDパイプラインへの組み込みや、定期的なコンプライアンス検証の自動化まで含めた運用設計を習得します。

③ パケット分析と性能監視 — Traffic MirroringとNetwork Monitor

Traffic Mirroringでパケットを深く分析し、CloudWatch Network MonitorとNetwork Managerでネットワーク性能とトポロジを継続監視します。フローメタデータだけでは見えない通信の内容や性能劣化の根本原因を特定する手法を習得します。2025年5月のOrganizations統合によるNetwork Flow Monitorのマルチアカウント対応や、2025年8月のNitro v4全インスタンスへのTraffic Mirroring対応など、最新のアップデートを踏まえた設計も含めて解説します。

1-2. 読者像とユースケース

本記事は、以下のような課題を抱えるエンジニアを主な読者として想定しています。

プラットフォームエンジニア・SRE

Transit Gateway・VPC・PrivateLinkによる接続基盤をすでに運用しており、「ネットワークの動作を可視化・検証・トラブルシュートしたい」と考えているプラットフォームエンジニアやSREを主な読者として想定しています。Transit Gatewayのルートテーブルやセキュリティグループの設定内容は把握しているが、「実際にどのトラフィックが流れているか」「どの経路で通信しているか」という可視性が不足していると感じている方に特に有用な内容です。

Flow Logsの拡張フィールド設計からAthena分析基盤の構築まで、継続的な運用監視の基盤整備を中心に解説します。スタートアップから大規模マルチアカウント環境まで、組織規模を問わず適用できる設計パターンを提供します。

ネットワーク担当・セキュリティエンジニア

マルチアカウント環境のセキュリティ統制を担うネットワーク担当やセキュリティエンジニアにとっては、Network Access Analyzerによるゼロトラスト検証（§4）とTraffic Mirroringによるパケット分析（§5）が中核となります。「意図しないアクセス経路が存在しないか」「ネットワーク侵入やラテラルムーブメントを検知できているか」という問いに答えるための実装ガイドとして活用できます。PCI DSS・SOC2・ISO27001等のコンプライアンス監査のエビデンス収集を自動化する手法も解説します。

インシデント対応担当

「接続できない」というアラートを受けた初動対応者にとっては、Reachability Analyzerによるモデルベース到達性分析（§3）がトリアージの第一手として有効です。データプレーンにパケットを一切送らずに構成上の問題を特定できるため、本番環境への二次被害なく原因箇所を絞り込むことができます。「構成に問題なし → アプリケーション層を調査」「構成に問題あり → ブロッキングコンポーネントを直接特定」という切り分けを数分で実施できるようになります。

前提とする技術知識として、AWSのVPC・サブネット・セキュリティグループ・ルートテーブルの基本操作を理解していることを想定します。Transit GatewayやPrivateLinkの詳細な設計知識まで必須ではありませんが、マルチVPCのネットワーク設計の概念を把握していると理解が深まります。

1-3. 既存記事との棲み分け

本記事は、既存の関連シリーズと明確に層が異なります。それぞれの関係を整理します。

「AWS Network本番運用」三部作との棲み分け

Transit Gateway・PrivateLink・VPC Lattice・IPAM・Cloud WANを扱う既存三部作は、AWSネットワークの接続を「どう構築するか」という設計・実装に特化しています。三部作が「どう繋ぐか」を扱うのに対し、本シリーズは「繋いだネットワークをどう可視化・検証するか」という可観測性・トラブルシューティングに集中します。接続基盤の設計・構築フェーズには既存三部作を、構築後の運用・観測フェーズには本シリーズを参照してください。

「AWS Observability」シリーズとの棲み分け

Application Signals・SLO・X-Ray・ADOTを扱う既存Observabilityシリーズは、アプリケーション/サービス層（L7/分散トレース）の可観測性を対象としています。本シリーズはL3/L4のネットワーク層（IPフロー・到達性・パケット転送）の可観測性に特化しており、対象レイヤーが異なります。アプリケーションの応答時間が遅い場合にアプリ層の観点で調べるときは既存Observabilityシリーズ、ネットワーク経路・パケット転送・フロー統計の観点で調べるときは本シリーズを使い分けてください。

CloudWatch Logs汎用ログ分析記事との棲み分け

CloudWatch Logsの汎用ログ分析を扱う既存記事は、アプリケーションログ・システムログ・Lambda実行ログなど広範なログソースへの対処法を解説しています。本記事§2は、CloudWatch Logsが選択肢のひとつとなるVPC Flow Logsを、ネットワーク可視化という特定の文脈に絞って詳しく解説します。「Flow Logsの拡張フィールドを設計してAthenaで分析したい」という場合は本記事§2を、「CloudWatch Logsの一般的な操作・Insights・メトリクスフィルタ」の場合は既存記事を参照してください。

1-4. 本記事が扱う3つのネットワーク可観測性能力

ネットワーク可観測性を実践的に構築するには、目的の異なる複数の能力を組み合わせる必要があります。本記事では以下の3軸でスタックを構成します。それぞれの能力は独立して使えますが、組み合わせることで「常時観測 → 変化検知 → 詳細解析」という段階的なトラブルシューティングを実現できます。

能力① — 常時監視: 通信の継続的な記録と分析

VPC Flow Logs（§2）とCloudWatch Network Monitor・Network Flow Monitor（§6）が担う領域です。本番ネットワークで常時発生するすべての通信フローを記録し、異常なトラフィックパターン・コスト増加の原因・障害時の通信記録として活用します。Flow Logsは通信メタデータ（送信元/宛先IP・ポート・プロトコル・バイト数・フラグ）を記録し、Hive互換パーティション＋Parquet形式でS3に保管することでコスト効率よく長期保管・分析できます。

Network Flow MonitorはEC2/EKSとAWSサービス（S3・RDS・DynamoDB）間のRTT・パケットロス・転送量をニアリアルタイムで可視化し、アプリケーション性能劣化のネットワーク層切り分けを支援します。2025年5月のOrganizations統合により、マルチアカウント環境での統一的な性能可視化が可能になっています。

能力② — 検証: 到達性と経路の継続的な証明

Reachability Analyzer（§3）とNetwork Access Analyzer（§4）が担う領域です。ネットワーク構成が「意図通りに設定されているか」を継続的に検証します。「繋がるべき経路が存在するか（Reachability Analyzer）」と「繋ぐべきでない経路が存在しないか（Network Access Analyzer）」という2方向の問いに答えます。どちらのツールもコントロールプレーンのモデルを評価するため、本番環境へのデータプレーン影響がゼロです。

インフラ変更のCI/CDパイプラインに組み込むことで、構成ミスが本番へ反映される前に検知できます。Network Access Analyzerはセキュリティコンプライアンス監査（PCI DSS・SOC2・ISO27001）のエビデンス収集にも活用できます。

能力③ — 深掘り: パケットレベルの精密診断

Traffic Mirroring（§5）が担う領域です。常時監視や到達性検証で特定できない問題——例えば「構成は正しいが謎のタイムアウトが発生する」「ネットワーク侵入の痕跡を証拠として保全したい」——に対し、パケットの中身まで踏み込んで診断します。フローメタデータ（VPC Flow Logs）だけでは把握できない通信の内容や、TCPリトランスミッション・ウィンドウ縮小などのパケットレベルのシグナルを分析します。コスト影響が大きいため、インシデント調査時のオンデマンド有効化が基本の運用スタイルです。

以下に3つの能力の特性比較を整理します。

この3層を適切に使い分け、組み合わせることで、「何が起きているか」「構成は正しいか」「根本原因は何か」を網羅的に把握できる可観測性スタックを実現します。§7では、これら3軸を統合した実戦的な可観測性スタック設計を解説します。

1-5. 記事の読み方

§2でフローログ基盤を、§3〜§4で到達性・アクセス経路の検証を、§5でパケット分析を、§6で性能・トポロジ監視を扱い、§7で可観測性スタックを統合した実戦パターン、§8でつまずきとアンチパターンを整理します。各章は独立した一工程として読める構成ですが、§7の統合パターンはすべての章を通読することで最大限に活用できます。

状況別の推奨起点を以下に整理します。

1. ネットワークトラブル対応中 → §3（Reachability Analyzer）から着手して構成上の問題を特定
2. セキュリティ監査・コンプライアンス対応 → §4（Network Access Analyzer）を優先して意図しない経路を網羅検証
3. パケット証拠保全・IDS/IPS統合 → §5（Traffic Mirroring）を参照してパケット分析基盤を設計
4. フローログ基盤の新規構築 → §2から順に読み進めるのが最も体系的な学習経路
5. 可観測性スタックの全体設計 → §7（統合設計）を読んだ後に各§で詳細を確認

つまずきやすいポイントとアンチパターンは§8にまとめています。読み進める中で設定に迷った場合は§8を参照することで、よくある誤設定の原因と対処を迅速に確認できます。

2. VPC Flow Logs設計 — 拡張フィールド・宛先・Athena分析

ネットワーク可観測性の土台は、すべての通信を記録するVPC Flow Logsです。CloudWatch Logsを使った汎用ログ分析を扱う既存記事がアプリケーションログ全般を対象とするのとは異なり、本節はVPC Flow Logsをネットワーク可視化の文脈に限定して解説します。拡張フィールドの選定理由・宛先（S3/CloudWatch Logs/Data Firehose）の設計・Hive互換パーティションによるAthena統合・Data Firehose+Lambdaタグエンリッチ・コスト最適化を扱います。

フローログはすべての通信フロー（ACCEPT/REJECT）のメタデータを記録しますが、デフォルト設定のままでは分析に必要な情報が不足します。NATの背後にある実際の送信元IPを把握できず、AWSサービス宛の通信を識別できず、コストの高いテキスト形式でS3に保存されてしまいます。本節では、これらの課題を解決する設計判断を解説します。

2-1. 拡張フィールドの設計と選定理由

VPC Flow Logsはデフォルトフィールドセット（version/account-id/interface-id/srcaddr/dstaddr/srcport/dstport/protocol/packets/bytes/start/end/action/log-status）に加え、カスタムフォーマットで拡張フィールドを自由に選択できます。

デフォルトフィールドの限界

デフォルトフィールドのsrcaddr・dstaddrはENIレベルのIPアドレスを記録します。NAT GatewayやネットワークロードバランサーがSNATを行う環境では、srcaddrがNATのIPになるため、実際の通信元アプリケーションのIPが隠れてしまいます。また、S3やDynamoDBなどのAWSサービスへの通信かどうかも、デフォルトフィールドだけでは判断できません。

主要拡張フィールドと選定理由

以下の拡張フィールドを分析目的に応じて選択します。

pkt_srcaddrフィールドを必ず選定すべき理由

NATゲートウェイ（NATGW）を使用するVPC構成では、プライベートサブネットのEC2からインターネットへの通信は、NATGWがSNATを行ってパブリックIPに変換します。この場合、デフォルトフィールドのsrcaddrにはNATGWのプライベートIPが記録され、実際に通信しているEC2のIPがわかりません。pkt_srcaddrを追加すると、NATの背後にある元のEC2のプライベートIPが記録されるため、「どのインスタンスが大量にアウトバウンド通信をしているか」「どのEC2が外部との不審な通信をしているか」を正確に特定できます。

pkt_dst_aws_serviceフィールドの活用

pkt_dst_aws_serviceフィールドには、通信の宛先がS3・DynamoDB・CloudFront・EC2などのAWSサービスである場合にサービス名が記録されます。このフィールドを活用することで、「S3へのデータ転送がコスト増加の原因か」「DynamoDBへのアクセスが増加しているワークロードはどれか」を、IPアドレスではなくサービス名で直接集計・分析できます。

カスタムフォーマット設定例

VPC Flow Logsのカスタムフォーマットは以下の形式で設定します。フィールドはスペース区切りで指定し、VPCコンソールまたはAWS CLIから設定できます。

${version} ${account-id} ${interface-id} ${srcaddr} ${dstaddr}
${srcport} ${dstport} ${protocol} ${packets} ${bytes}
${start} ${end} ${action} ${flow-direction} ${log-status}
${vpc-id} ${subnet-id} ${instance-id} ${tcp-flags} ${type}
${pkt-srcaddr} ${pkt-dstaddr}
${pkt-src-aws-service} ${pkt-dst-aws-service}
${traffic-path} ${az-id}

CLIで既存のFlow Logにカスタムフォーマットを設定する場合は、一旦削除して再作成する必要があります（既存Flow Logのフォーマット変更は非対応）。Terraform等のIaCで管理することで、フォーマット変更のトレーサビリティを確保できます。

2-2. 宛先の設計（S3 / CloudWatch Logs / Data Firehose）

VPC Flow Logsの宛先はCloudWatch Logs・Amazon S3・Amazon Data Firehose（旧Kinesis Data Firehose）から選択し、同時に複数宛先へ配信できます。用途に応じて使い分けを設計します。

CloudWatch Logs

CloudWatch Logsを宛先にした場合、フローログはロググループへ数分以内に配信されます。CloudWatch Logs Insightsを使ったアドホッククエリ、メトリクスフィルタを使ったリアルタイムアラート（例：特定ポートへのREJECTが閾値を超えたらSNS通知）に適しています。保持期間は1日から10年まで設定でき、コストはデータ取り込み量と保存量に基づく従量課金です。大量のフローを長期保管する場合はコストが高くなるため、リアルタイム分析用に限定してS3と併用するのが一般的な設計です。

Amazon S3

長期保管と大規模分析にはS3が最適です。Hive互換パーティション形式（account/service/region/year/month/day/hour）とApache Parquet形式を組み合わせることで、Athenaでのクエリコストを大幅に削減できます。ログはZIP圧縮のテキスト形式か、圧縮Parquet形式のいずれかで保存できます。S3 ライフサイクルルールと組み合わせて、古いログをS3 Glacierへ移行するコスト最適化も容易に実現できます。

Amazon Data Firehose（旧Kinesis Data Firehose）

Data Firehoseを宛先にした場合、Lambda変換を挟んでレコードを加工してからS3やOpenSearch Serviceへ配信できます。EC2インスタンスのタグ（環境/チーム/サービス名）をENI IDに紐付けてフローレコードにエンリッチする「タグエンリッチ」パターンが代表的な使い方です。バッファリングと変換のレイテンシ（数十秒〜数分）があるため、リアルタイムアラートにはCloudWatch Logsとの併用を推奨します。

複数宛先への同時配信

VPC・サブネット・ENIごとに複数のFlow Log設定を作成できます。例えば、同一VPCに対してCloudWatch Logs宛の設定（リアルタイムアラート用）とS3宛の設定（長期保管・Athena分析用）を同時に設定できます。ただし、フローログの作成数が増えるほどELIGIBLEなENIへの記録オーバーヘッドが増加するため、必要最低限の宛先数に絞ることが推奨されます。

以下に宛先別の特性を整理します。

2-3. Hive互換パーティションとAthena統合

S3宛先ではHive互換パーティション形式を選択することで、Athenaでのクエリコストを劇的に削減できます。

Hive互換パーティション構造

Hive互換フォーマットを選択すると、S3のオブジェクトキーは以下の形式で生成されます。

s3://[bucket]/AWSLogs/[account-id]/vpcflowlogs/[region]/
  [year]/[month]/[day]/[hour]/
  [account-id]_vpcflowlogs_[region]_[flow-log-id]_[timestamp].log.gz

per-hourパーティション（[year]/[month]/[day]/[hour]）を有効にすることで、時間単位でのクエリ絞り込みが可能になります。Athenaのテーブル定義でPARTITIONED BY (year STRING, month STRING, day STRING, hour STRING)として設定し、MSCK REPAIR TABLE vpc_flow_logs;を実行することで新規パーティションを取り込めます。新しいログが届くたびに定期的にMSCK REPAIRを実行するか、S3イベント通知+LambdaでADD PARTITION DDLを自動実行する仕組みを構築すると運用が楽になります。

Apache Parquet形式の利点

テキスト形式（GZIP圧縮TSV）をParquet形式に変換することで、Athenaのクエリコストを大幅に削減できます。Parquetは列指向フォーマットであり、SELECT srcaddr, dstaddr, bytesのように特定の列だけを読み取るクエリでは、テキスト形式と比較してスキャン量が数分の1〜10分の1になります。Parquet形式はData Firehoseの変換Lambda、AWS Glue ETLジョブ、またはAthena CTAS（CREATE TABLE AS SELECT）クエリで生成できます。

VPCコンソールのAthena統合

VPCコンソールには、Flow LogsのAthena統合機能が組み込まれています。対象のFlow Logを選択して「Athena統合の設定」を実行すると、Athenaデータベース・ワークグループ・S3ストレージ場所・パーティション付きテーブルを一括作成するCloudFormationテンプレートが生成されます。このCFNテンプレートをデプロイすることで、手作業でのDDL記述なしにAthena分析環境を即座に構築できます。

Athenaクエリ例 — 拒否されたトラフィックの送信元集計

SELECT
 pkt_srcaddr,
 dstaddr,
 dstport,
 protocol,
 SUM(bytes)AS total_bytes,
 COUNT(*)  AS flow_count
FROM vpc_flow_logs
WHERE year  = '2024'
  AND month = '01'
  AND action = 'REJECT'
GROUP BY pkt_srcaddr, dstaddr, dstport, protocol
ORDER BY flow_count DESC
LIMIT 50;

year・monthパーティション列をWHERE句で明示することがAthenaコスト削減の要点です。パーティション指定なしにスキャンすると全期間のデータを読み込むため、コストが跳ね上がります。pkt_srcaddrを使うことでNATの背後の実送信元IPを集計できます。

2-4. Data Firehose＋Lambdaによるタグエンリッチ

VPC Flow Logsはネットワーク層の情報（IP・ポート・バイト数）を記録しますが、「どのサービス/チーム/環境のEC2か」という業務コンテキストは含まれません。Data Firehose＋Lambda変換を組み合わせることで、この情報を動的に付与（タグエンリッチ）できます。

Lambda変換の仕組み

Data Firehoseを宛先にしたFlow Logsのレコードは、設定したLambda関数に渡されます。Lambda関数はBase64デコードしたレコードを解析し、interface-idやinstance-idからEC2のタグを参照してエンリッチしたレコードを返します。Lambda関数が返したレコードはData Firehoseのバッファリングを経てS3に書き出されます。

タグエンリッチの主なユースケース

• コスト配賦: ENI/インスタンスIDをEC2タグ（Environment/Team/ServiceName）で拡張し、チーム別・サービス別のネットワーク通信コストを集計
• 環境識別: VPC IDやサブネットIDをタグから「production/staging/development」に変換してAthenaクエリを簡素化
• セキュリティ分類: タグ（data-classification/security-level）を付与してインシデント対応時の影響範囲判断を自動化
• 名前解決: ENI IDをEC2インスタンス名に変換して、クエリ結果の可読性を大幅に向上

エンリッチ後のレコード構造例

{
  "srcaddr": "10.0.1.100",
  "pkt_srcaddr": "10.0.1.100",
  "dstaddr": "203.0.113.50",
  "dstport": 443,
  "protocol": 6,
  "bytes": 12345,
  "action": "ACCEPT",
  "enriched_src_instance_name": "web-app-01",
  "enriched_src_environment": "production",
  "enriched_src_team": "platform",
  "enriched_src_service": "frontend-api"
}

エンリッチ後のレコードをS3のParquet形式で保管し、AthenaでWHERE enriched_src_team = 'platform'のようなクエリを実行することで、チームごとのネットワーク通信コストや異常な通信パターンを素早く特定できます。

2-5. コスト最適化設計

VPC Flow Logsはすべての通信フローを記録するため、高トラフィック環境では無設計のまま使うとコストが膨らみます。以下の最適化を設計段階で組み込みます。

パーティション絞り込みによるAthenaスキャン削減

Athenaはyear/month/day/hourのパーティション列をWHERE句で指定することで、スキャン対象のS3オブジェクトを絞り込めます。パーティション指定なしで全期間のデータをスキャンすると、1TB以上のデータ読み取りが発生してコストが大きく跳ね上がります。クエリテンプレートに必ずパーティション条件を含めることを組織のルールとして設定し、コスト超過を防止します。

Parquet形式によるスキャン量削減

テキスト（GZIP圧縮TSV）からParquetに変換するだけで、列指向の選択的読み取りによりAthenaのスキャン量を50〜90%削減できます。Athenaの料金は1TB当たり5USDのスキャン課金のため、スキャン量の削減は直接コスト削減に繋がります。Data Firehoseで直接Parquet出力、またはAWS GlueでETL変換する構成を採用します。

S3ライフサイクルルールによるデータ階層化

Flow Logsは時間が経つほど参照頻度が下がります。S3ライフサイクルルールを設定し、30日後にS3 Intelligent-Tiering、90日後にS3 Glacier Instant Retrievalへ移行することで、長期保管コストを削減します。Athenaはすべてのストレージクラスのオブジェクトをクエリ対象にできますが、Glacierは取り出しコストが発生するため、頻繁に参照する直近データ（30日以内）はS3 Standard（またはS3 Intelligent-Tiering）に置くよう設計します。

CloudWatch Logsの保持期間設定

CloudWatch Logsを宛先にしている場合、保持期間を無制限のままにするとログ保存コストが増加し続けます。Flow Logsの場合、インシデント調査に必要な期間（一般的に30〜90日）を保持期間として設定し、それ以降は自動削除または定期的にS3へエクスポートする設計を採用します。

コスト最適化の優先順位

コスト最適化を段階的に導入する際は、①Hive互換パーティション設定（Athenaスキャン削減・最優先）→②Parquet変換（さらなるスキャン削減）→③ライフサイクルルールの設定（保管コスト削減）の順序で実施することが推奨されます。

3. VPC Reachability Analyzer — 到達性のモデルベース検証

「通信が届かない」原因をトラブルシューティングする際、最初に直面するのが「実際にパケットを送って確認する」か「構成を見て判断する」かという選択です。本番環境で任意のパケットを流すことはリスクを伴いますが、VPC Reachability Analyzerはデータプレーンにパケットを一切送ることなく、ネットワーク構成のモデルから到達性を検証する設定分析ツールです。本節では、モデルベース分析の仕組み・対応リソースと制約・分析結果の解釈・運用設計・料金とresource exclusionを扱います。

Reachability Analyzerは2021年にGAとなり、以来継続的に機能が拡張されています。2025年5月のresource exclusionの導入はその最新の拡張の一つであり、今後もAWSのネットワーク可観測性戦略の中核として機能拡張の継続が期待されます。

3-1. モデルベース分析の仕組みと本番無影響の原理

VPC Reachability Analyzerは、AWSのコントロールプレーンに記録されているネットワーク構成（ルートテーブル・セキュリティグループ・ネットワークACL・VPCエンドポイントポリシー・Transit Gatewayルートテーブルなど）を入力として、ネットワーク構成のモデルを内部で構築し、そのモデル上でソースから宛先への到達性を解析します。

この分析はデータプレーン（実際のパケット転送）を一切使用しません。ICMPによるpingやTCPによる接続確認といった従来の疎通確認と異なり、実際のパケットがネットワーク機器を経由することがないため、以下のような本番環境での障壁を一切回避できます。

• セキュリティグループやネットワークACLでICMP/TCPが拒否されていても分析可能です
• ファイアウォールや侵入検知システム（IDS）にアラートを生成しません
• 分析中の帯域消費がゼロで、本番ワークロードへの影響がありません
• デプロイ直後・構成変更後のリソースも、構成さえ存在すれば即座に検証できます

コントロールプレーンの構成のみを評価するこのアプローチは、本番環境のネットワーク変更前の事前検証や、障害発生時の迅速な原因特定において特に有効です。

3-2. 対応リソースと制約事項

Reachability Analyzerで指定できるソース（分析開始点）および宛先（到達確認の対象）は以下のリソースです。

ソースおよび宛先として指定可能なリソース：

• EC2インスタンス
• ネットワークインターフェース（ENI）
• VPCエンドポイント
• Transit Gateway
• Internet Gateway
• VPN Gateway（Virtual Private Gateway）
• VPC Peering Connection

宛先のみ指定可能なリソース：

• IPアドレス（IPv4）

ソースと宛先の間には重要な制約があります。両者は必ず同一リージョンに存在する必要があり、異なるリージョン間の到達性分析は現時点でサポートされていません。また、異なるVPC間の到達性を分析する場合は、そのVPC同士がVPC PeeringまたはTransit Gateway経由で接続されている必要があります。接続されていないVPC間は分析対象に指定できません。

これらの制約を踏まえた分析設計のポイントとして、マルチリージョン構成ではリージョンごとに個別に分析を実施すること、また複数のVPCにまたがる経路はTransit Gatewayのルートテーブルが正しく構成されていることを前提として分析することが挙げられます。

3-3. 分析結果の解釈 — hop-by-hop詳細とブロッキングコンポーネント

分析が完了すると、ソースから宛先への到達性が「到達可能（Reachable）」または「到達不可能（Not Reachable）」として判定されます。それぞれの場合で提供される情報が異なります。

到達可能（Reachable）の場合

ソースから宛先まで仮想ネットワークパスがhop-by-hopで詳細に表示されます。経由するネットワーク機器（ENI・ルートテーブル・NAT Gateway・Transit Gateway・VPCエンドポイントなど）が順番にリストされ、各hopでどのルートエントリやセキュリティグループルールが適用されているかを確認できます。この情報は、想定した経路通りにトラフィックが流れているかを構成レベルで検証するのに役立ちます。

到達不可能（Not Reachable）の場合

通信をブロックしているコンポーネントを特定します。ブロッキングコンポーネントとして検出されるのは次のようなものです。

• セキュリティグループのインバウンド/アウトバウンドルール（許可ルールが存在しない場合）
• ネットワークACLのデナイルルール
• ルートテーブルの不備（デフォルトルートの欠如、ブラックホールルート等）
• VPCエンドポイントポリシーによるアクセス拒否
• Transit Gatewayのルートテーブルにおけるルート欠如
• インターネット向け経路でのInternet Gateway非接続

分析結果には、ブロッキングコンポーネントのリソースIDとタイプが含まれており、どのリソースが通信を拒否しているかを直接特定できます。従来「ping不可→セキュリティグループを目視確認→ルートテーブルを目視確認→ネットワークACL確認…」という手動確認プロセスを、一度の分析で大幅に短縮できます。

3-4. 運用設計 — ユースケース別頻度とCI/CD統合

Reachability Analyzerは、インタラクティブなトラブルシューティングだけでなく、インフラ変更のCI/CDパイプラインへの組み込みにも適しています。

① インフラ変更時の事前・事後検証

TerraformやAWS CDKによるデプロイ前後にCLIで自動実行し、想定する接続経路（例：アプリケーションサーバー→RDSエンドポイント、Lambda→VPC内プライベートサービス）が到達可能であることをゲートチェックとして確認します。変更前後で分析を走らせ、変更後の到達性喪失を即座に検知できます。

デプロイパイプラインでは、分析結果が「到達不可能」の場合はパイプラインをFAILで停止させ、次のデプロイステージへ進まないよう制御します。これにより、構成ミスが本番環境へ反映される前に修正できる安全網を構築できます。

② 障害発生時のトリアージ

「通信が届かない」という障害報告を受けた初動として、問題のソース・宛先間でReachability Analyzerを実行し、構成上の問題か（分析結果が「到達不可能」）、構成は正しいが他の要因か（分析結果が「到達可能」→アプリケーションレイヤーの問題等）を即座に切り分けられます。手動確認よりも迅速かつ体系的にブロッキング箇所を特定できます。

③ ゴールデンパスの定期検証

本番環境で必須の通信経路（例：ECSタスク→Amazon RDS Private Endpoint、EC2→S3 VPCエンドポイント）をリストアップし、スケジュール実行で定期的に分析することで、構成のドリフト（誰かが意図せずセキュリティグループルールを変更した等）を自動検知する継続監視体制を構築できます。AWS Config のCustom Ruleとして実装し、到達性がReachableからNot Reachableに変化したタイミングでアラートを発報する設計にすると、構成変更によるデグレードを変更直後に検出できます。

3-5. 料金設計とresource exclusion（2025年5月対応）

Reachability Analyzerは1回の分析あたり0.10 USDの従量課金です。月の分析回数がコストに直結するため、ユースケース別の実行頻度を設計することが重要です。料金はパスあたりではなく、分析1回あたりで課金されます。同じパスに対して複数回分析した場合は実行回数分の費用がかかります。

CI/CDパイプラインで自動実行する場合、デプロイ頻度に分析数が連動します。検証するゴールデンパスの数（例：10経路）×月次デプロイ回数（例：50回）の場合、月500回で50 USDとなります。コスト最適化の観点では、検証対象の経路をクリティカルパスに絞り込むか、変更頻度の低い基盤部分は週次・日次ベースに頻度を下げることが有効です。

2025年5月に導入されたresource exclusionは、分析時に特定のネットワークリソースを除外して到達性を評価する機能です。例えば、メンテナンス中のNAT Gatewayを一時除外し、そのリソースを迂回した場合の到達性を仮想的に評価するといった用途に使えます。また、規模が大きい環境でTransit Gatewayのルートテーブルを絞り込んで評価したい場合にも活用できます。resource exclusionにより、大規模環境や特定の分析シナリオに合わせた柔軟なスコープ設定が可能になります。

3-6. マルチアカウント環境・ピアリング構成での注意点

Transit GatewayやVPC Peeringを通じた複数VPC間の接続構成では、Reachability Analyzerが特に有効な場面と、設計上の注意点があります。

Transit Gateway経由の分析：

複数VPCをTransit Gatewayでハブ&スポーク型に接続している環境では、VPC-A内のEC2インスタンスからVPC-B内のRDSへの到達性をReachability Analyzerで分析できます。この際、Transit Gatewayのルートテーブルに適切なルートが存在し、アソシエーションとプロパゲーションが設定されていることが前提です。分析が「到達不可能」を返した場合、Transit Gatewayのルートテーブルの不備（特定のVPCアタッチメントへのルートが存在しない等）がブロッキングコンポーネントとして特定されます。

VPC Peering経由の分析：

VPC Peering接続を通じた到達性分析でも同様に機能します。Peering接続が確立されていても、送信元VPCのルートテーブルにPeering経由のルートが存在しないケース、または宛先VPCのセキュリティグループが送信元VPCのCIDRからのトラフィックを許可していないケースが、「到達不可能」の典型的な原因です。

クロスアカウント分析の設計：

異なるAWSアカウント間を跨ぐ到達性分析は、Transit Gatewayを介した同一リージョン内の構成であればサポートされます。クロスアカウントのTransit Gatewayアタッチメントが確立されている場合、アカウントAのリソースからアカウントBのリソースへの到達性を分析できます。ただし、分析するアカウントから相手アカウントのリソースへのアクセス権限（Resource Access Manager等での共有設定）が必要な点に留意してください。

セキュリティグループの参照ルール：

セキュリティグループのインバウンドルールに「別のセキュリティグループID」を参照する設定（SG-to-SGルール）がある場合、Reachability Analyzerはこの参照関係を正しく解釈して到達性を評価します。異なるVPC間のSG参照はVPC Peeringが前提となるため、Peering接続が未確立の場合はSGルールが存在していても「到達不可能」と判定されます。

3-7. 分析APIとCLIによる自動化の実装

Reachability AnalyzerはAWS CLIおよびSDKから操作できます。CI/CDパイプラインや自動化スクリプトへの組み込み時に知っておくべき操作フローを整理します。

分析の実行は、ネットワークインサイトパス（Network Insights Path）とネットワークインサイト分析（Network Insights Analysis）の2ステップで構成されます。まずソースと宛先を定義したパスを作成し、そのパスへの分析を実施します。

# パスの作成（例：EC2インスタンス → ENI）
aws ec2 create-network-insights-path--source <source-resource-id>--destination <destination-resource-id>--protocol TCP--destination-port 3306

# 分析の実行
aws ec2 start-network-insights-analysis--network-insights-path-id <path-id>

# 分析結果の取得
aws ec2 describe-network-insights-analyses--network-insights-analysis-ids <analysis-id>

分析が完了するまで数秒から数十秒かかる場合があります。NetworkPathFound: trueが返れば到達可能、falseであればExplanationsフィールドにブロッキングコンポーネントの詳細が含まれます。

CI/CDパイプラインへの組み込みでは、分析完了を待つポーリングループを実装し、結果に応じてパイプラインを成功/失敗で終了させる構成が一般的です。分析が頻繁でない場合は、作成済みのパスIDを再利用して分析のみを繰り返し実行することでコストと手間を削減できます。

resource exclusionを活用する場合のCLI操作では、--filter-in-arnsオプションに除外対象リソースのARNを指定して分析します。除外するリソースはNAT GatewayやTransit Gatewayアタッチメントなど、分析スコープから一時的に外したいコンポーネントを選択します。resource exclusionで除外されたリソースは分析から省かれるため、「そのリソースが存在しない場合の到達性」を仮想的に評価でき、代替経路の設計検証や段階的なインフラ移行時の接続性確認に役立ちます。

分析パスは一度作成すれば繰り返し再利用できます。同じソース・宛先ペアに対して週次・月次で継続的に分析する場合は、パスIDを変数として管理し、分析のみをスケジュールすることで運用コストを抑えられます。分析パスを削除すると関連する分析結果も削除されるため、監査証跡として分析結果を保持したい期間中はパスを削除しないよう注意が必要です。

なお、Reachability Analyzerで「到達可能」と判定された場合でも、アプリケーション層（L7）での問題（データベースの認証設定・SSL/TLS証明書の検証・アプリケーション独自のアクセス制御等）を原因として通信に失敗する場合があります。Reachability AnalyzerはL3/L4のネットワーク層の構成のみを評価するツールであるため、「到達可能」はあくまでネットワーク経路に問題がないことを意味します。L7の問題は、各サービスのログ（CloudWatch Logs・RDS Performance Insights等）と組み合わせて切り分けることが重要です。

4. Network Access Analyzer — アクセス経路の網羅的検証

Reachability Analyzerが「繋がるべきものが繋がるか」を検証するのに対し、Network Access Analyzerは「繋がるべきでないものが繋がっていないか」をゼロトラストの観点で網羅検証します。本節では、ネットワークアクセススコープの設計・Findingsの活用・ゼロトラスト文脈での継続検証・Reachability Analyzerとの詳細な使い分けを扱います。

Network Access Analyzerは、単なるセキュリティチェックツールではなく、ネットワーク設計の「意図」をコードとして定義し、継続的に検証するInfrastructure as Security（IaS）を実践するためのプラットフォームでもあります。スコープ定義がそのまま組織のネットワークアクセスポリシーのコードとなり、分析実行がポリシー準拠の自動テストとなります。

4-1. ネットワークアクセススコープの設計とFindings

Network Access Analyzerは、ネットワークアクセススコープと呼ばれる定義を使って、AWSネットワークリソース間の意図しないアクセス経路を特定します。スコープは「どのリソースから」「どのリソースへ」の経路が存在してはならないかを定義するもので、定義したスコープに違反する経路が検出されるとFindingsとして報告されます。

スコープの定義では、トラフィックの出入口（スコープの起点と終点）をリソースタイプ・タグ・CIDR範囲等で指定します。例えば「インターネット向けのInternet Gatewayから直接到達できるリソース」をスコープとして定義すれば、意図せずインターネットに公開されているエンドポイントをFindingsとして網羅的に検出できます。

スコープは一度定義するとAWS上に保存されます。保存されたスコープは繰り返し再実行でき、定期スキャンに同一のスコープを使い回すことで設計の一貫性を保てます。スコープはAWS CLIまたはコンソールから管理でき、タグを付与して環境別（本番/開発）に整理することが推奨されます。

Findingsが生成されると、それぞれのFindingにアクセス経路の詳細（どのリソースを経由してどこに到達できるか）が記録されます。レビューして意図した設計の場合はFindingをアーカイブして次回の分析から除外できます。意図しない設計の場合は経路を遮断する修正を実施し、修正後に再分析してFindingが解消されたことを確認します。

ネットワークアクセススコープの検査対象リソース：

• セキュリティグループ・CIDRブロック・プレフィックスリスト
• ネットワークインターフェース（ENI）・EC2インスタンス
• ロードバランサー（ALB/NLB）
• VPC・サブネット
• VPCエンドポイント（Interface型・Gateway型）
• Transit Gateway
• NAT Gateway
• Internet Gateway
• VPN Gateway
• VPC Peering Connection
• Network Firewall

これだけ広範なリソースを対象とすることで、複雑なマルチVPC・マルチアカウント環境においても、意図しないアクセス経路の見落としを防ぎます。

4-2. ゼロトラスト文脈での活用と継続的コンプライアンス検証

Network Access Analyzerは、ゼロトラストアーキテクチャの「すべてのアクセスを検証し、最小権限に留める」原則を、ネットワーク層で実践するツールとして位置づけられます。

ゼロトラストアーキテクチャでは、VPN内だからといってすべての通信を信頼するのではなく、それぞれのリソース間のアクセスが明示的に許可された設計であることを継続的に検証します。Network Access Analyzerのスコープ定義とFinding管理がこの継続検証を自動化します。

具体的なユースケースとして次のようなものがあります。

セキュリティコンプライアンス監査の自動化：

PCI DSS・SOC2・ISO27001等のコンプライアンス要件では「本番データベースへのインターネットからの直接アクセスが存在しないこと」「DMZを経由しないバックオフィス直接通信が存在しないこと」といったネットワークアクセス要件が定義されます。これらの要件をNetwork Access Analyzerのスコープとして定義し、定期実行することで、コンプライアンス監査のエビデンス収集を自動化できます。

スコープ定義そのものがコンプライアンス要件のドキュメントとなり、分析実行が自動化された準拠テストとなります。監査担当者に「スコープ定義」と「Findings=0の分析結果」を提示することで、ネットワーク層のコントロールが有効に機能していることを客観的に証明できます。

マルチアカウント環境での経路統制：

AWSマルチアカウント構成では、Transit Gatewayのルートテーブルや共有VPCの設定ミスによって、本来分離されるべきワークロード間（本番/開発/セキュリティ等）の経路を意図せず開通させてしまう場合があります。Network Access Analyzerをアカウントレベルで実行し、クロスアカウントの意図しない経路をFindingsとして検出する体制を整えます。

インフラ変更後のセキュリティ回帰テスト：

Terraform等でインフラを変更した後に、Network Access Analyzerを実行してFindingsが新規に発生していないかを確認します。CI/CDパイプラインにNetwork Access Analyzerの実行を組み込み、Findingsの増加を変更のゲートチェックとして使うことで、セキュリティ回帰を変更直後に検出できます。

4-3. Reachability AnalyzerとNetwork Access Analyzerの詳細比較

2つのAnalyzerは補完関係にあります。それぞれが異なる問いに答えるツールであり、どちらか一方で済むものではありません。以下に主要な比較軸を整理します。

使い分けの判断フロー：

「特定のEC2インスタンスからRDSへの接続が取れない」→ Reachability Analyzerでポイント間の到達性を分析し、ブロッキングコンポーネントを特定します。

「本番VPCでインターネットから直接到達できるリソースが存在しないことを証明したい」→ Network Access Analyzerでスコープ（Internet Gateway→本番VPC内のリソース）を定義し、Findingsがゼロであることを確認します。

「インフラ変更後、意図しない新規の経路が開通していないか確認したい」→ Network Access Analyzerを変更前後に実行し、Findingsの差分を確認します。

ゼロトラストアーキテクチャを実践する環境では、Reachability Analyzerで「繋がるべき経路が正しく繋がっているか」を検証しながら、Network Access Analyzerで「繋ぐべきでない経路が存在しないか」を継続検証する両輪の体制が理想的です。

4-4. 運用設計 — スコープ設計と定期検証の自動化

Network Access Analyzerを継続的なセキュリティ検証に活用するには、スコープの設計と定期実行の仕組みを整備することが重要です。

スコープ設計のポイント：

スコープは「ビジネス上の意図」を反映させて設計します。例えば「本番データストア（RDS/DynamoDB）に対して、Webレイヤーの承認済みサービス以外から直接アクセスできる経路が存在しないこと」をポリシーとして持つ場合、そのポリシーをそのままスコープ定義に翻訳します。初回の分析ではFindingsが多数発生しますが、設計上意図した経路はアーカイブして整理することで、次回以降の分析で本当に意図しない経路のみが残ります。

定期実行の設計：

Network Access AnalyzerはAWS CLIまたはSDKから実行できるため、EventBridgeのスケジュールルールでLambdaを定期起動し、自動的に分析する仕組みを構築できます。Findingsが新規に発生した場合はSNSでアラートを発報し、セキュリティ担当へ通知します。この自動化により、手動での定期確認を排除し、常に最新の構成に基づいたセキュリティ検証を継続できます。

4-5. Findingsのライフサイクル管理と継続運用

Network Access Analyzerの継続的な活用には、Findingsを適切に管理してノイズを減らし、真に意図しない経路のみが残る状態を維持することが重要です。

Findingsのトリアージとアーカイブ：

初回分析では、既知の設計（例：管理用踏み台サーバーからのインバウンド経路、CloudFront→ALBの公開経路など）もFindingsとして検出されます。これらは「意図した設計」として確認し、アーカイブ操作を実施します。アーカイブされたFindingは次回以降の分析では新規Findingとして扱われないため、ノイズが除去されます。アーカイブ解除の理由（いつ、誰が、なぜアーカイブしたか）をコメントとして記録しておくことで、将来の監査時に設計意図の根拠として使えます。

Findingsの重要度分類：

検出されたFindingsはすべてが同等の重要度ではありません。インターネット向けのInternet Gatewayから本番データベースへの直接経路はクリティカルですが、開発環境内のサービス間経路は軽微な場合があります。スコープ設計の段階で検出対象を重要度の高い経路（本番・機密データ・規制対象）に絞ることで、Findingsの質を高めて対応工数を最小化できます。

マルチアカウント構成でのOrganizations統合：

AWS Organizationsを使用したマルチアカウント環境では、管理アカウントまたはDelegated Administratorとして指定したアカウントからNetwork Access Analyzerを組織全体に適用できます。単一の分析スコープで複数アカウントにまたがるリソースを対象とした経路検証が可能になり、組織横断のセキュリティ統制を効率的に実施できます。

定期実行とFindingゼロの維持：

成熟した運用では「Findingsゼロ」の状態を継続的に維持することを目標とします。インフラ変更後に新規Findingが発生した場合は、変更内容と照合して意図した変更かどうかを確認し、意図した場合はアーカイブ、意図しない場合は修正します。このサイクルを定期的に実施することで、組織のネットワークアクセスポリシーへの継続的な準拠を証明できます。定期監査の頻度は、変更の多い環境では週次、安定した環境では月次が目安となります。

レポーティングとコンプライアンスエビデンス：

Network Access Analyzerの分析結果はコンプライアンス監査のエビデンスとして活用できます。「分析日時・スコープ定義・Findings数（アクティブ/アーカイブ）」の記録を定期的に取得して保管し、監査時に「この期間を通じてNetworkAccessAnalyzerのアクティブFindingsがゼロであった」ことを証明するドキュメントとして使います。AWS Security Hubと統合することで、FindingsをSecurity HubのFindingsとして一元管理する構成も可能です。

4-6. スコープ設計のベストプラクティスと実装例

実際の環境でNetwork Access Analyzerを有効活用するため、スコープ設計のベストプラクティスをパターン別に整理します。

パターン①：インターネット公開範囲の網羅検証

Internet Gatewayからの受信トラフィックが到達できる全リソースをスコープとして定義し、意図していないリソース（例：本番DBのENI、管理コンソール用EC2）が含まれないことを確認します。Findingsとして検出されたリソースについて、意図した公開リソース（ALB等）はアーカイブし、意図しないリソースは経路を遮断する修正を実施します。

パターン②：本番/開発環境間の分離検証

マルチアカウント構成で本番VPCと開発VPC間に通信経路がないことを継続検証します。Transit Gatewayのルートテーブルには本番↔開発間のルートを設定しないことを前提とします。設定ミスや意図しない変更でルートが追加された場合でも、Findingsとして即座に検出できます。

パターン③：PrivateLinkによるサービス公開範囲の検証

PrivateLinkで公開するサービスへのアクセス経路が、VPCエンドポイントを介した承認済みのコンシューマーVPCからのみ存在することを検証します。承認していないVPCからサービスへのアクセス経路が存在する場合、スコープ違反としてFindingsに表示されます。

これらのパターンを組み合わせることで、環境固有のセキュリティポリシーをNetwork Access Analyzerのスコープとして体系的に実装できます。スコープは変更可能なため、ビジネス要件の変化に合わせて更新し、常に最新のポリシーを反映した状態を維持することが運用上の重要なポイントとなります。

Network Access Analyzerのスコープ変更は既存のFindingsに影響しません。スコープを変更して再分析すると、新しいスコープに基づいた新規Findingsが生成されます。スコープの変更前後でFindingsを比較することで、変更によってどの経路が検証対象になり、どの経路が対象外になったかを把握できます。スコープ設計の変更は、セキュリティポリシーの意図的な変更を反映させる場合（新しいサービスの公開を許可する等）と、誤検知を減らすためのスコープ絞り込みの2種類があります。いずれの場合も変更理由を記録し、定期的な見直しサイクルで最新の状態を維持します。

5. Traffic Mirroring — パケットレベルのディープ分析

Flow Logsがメタデータ（送信元/宛先/ポート/バイト数/フラグ）を記録するのに対し、Traffic Mirroringはパケットの中身そのもの（ペイロードを含む全フレーム）をコピーして分析アプライアンスへ転送します。アプリケーション層のコンテンツ解析・不正通信の証拠保全・パケットレベルのパフォーマンス診断など、フローメタデータでは不可能なディープパケット検査を実現します。本節では、対応インスタンス・ミラーターゲット種別・フィルタ設計・VXLANカプセル化・コスト設計・代表的なユースケースを扱います。

5-1. 対応インスタンスとミラーソース

Traffic Mirroringのソースには、モニタリング対象インスタンスのElastic Network Interface（ENI）を指定します。2025年8月のアップデートでNitro v4世代の全インスタンスタイプに対応し、対応範囲が大幅に拡大しました。

加えて一部の非Nitroインスタンスも引き続きサポートされています。具体的には、C4・D2・G3・I3・M4・P2・P3・R4・X1が対象です。これ以外の非NitroインスタンスはTraffic Mirroringをサポートしないため、導入前にインスタンス世代を確認する必要があります。

ミラーソースとなるENIは、EC2インスタンスに付与されたプライマリまたはセカンダリのネットワークインターフェースです。ECSタスクやEKS Podに付与されたENIもソースとして指定できます。同一VPC内の複数ENIを同一のミラーセッションでまとめてミラーリングできないため、ENIごとに個別のトラフィックミラーセッションを作成します。

なお、ミラーソースENIと分析アプライアンスが同一インスタンスに存在する場合、自己ミラーリングのループが発生しないようにフィルタ設計で除外ルールを設けることが必要です。

5-2. ミラーターゲットの種別と選択指針

ミラーターゲットは、コピーしたトラフィックの送付先を指定するコンポーネントです。以下の3種類から選択します。

ENIターゲット

単一の分析アプライアンスインスタンスのENIを直接指定します。構成がシンプルで検証環境や小規模構成に適していますが、アプライアンスが単一障害点となるため、高可用性を確保するには追加の仕組みが必要です。

NLBターゲット（Network Load Balancer）

複数の分析アプライアンスインスタンスを配置したNLBを指定します。ミラーリングされたパケットはNLBのUDPリスナーで受信され、複数のアプライアンスへの負荷分散と高可用性を実現します。本番環境では最も一般的な構成です。

GWLBエンドポイントターゲット（Gateway Load Balancer Endpoint）

Gateway Load Balancerエンドポイント（GWLBe）を指定し、UDPリスナーで受信します。複数アカウントにまたがるサードパーティのセキュリティアプライアンス（IDS/IPSなど）フリートへ透過的にトラフィックを送付する際に適しています。AWS Marketplaceのセキュリティアプライアンスと組み合わせるシナリオでよく選択されます。

ターゲット選択の指針としては、単一アカウント内での軽量な分析にはENI、スケーラブルな本番環境にはNLB、マルチアカウントのセキュリティ統制にはGWLBeを選択するのが基本です。

5-3. ミラーフィルタとパケットトランケーション

Traffic Mirroringでは、フィルタルールセットを使って転送するトラフィックを細かく制御できます。フィルタルールには、優先度・イングレス/エグレス方向・アクション（受け入れ/拒否）・プロトコル・送信元/宛先CIDRおよびポート範囲を指定します。

フィルタの代表的な活用例として以下が挙げられます。

• 特定ポート（443/80等）のHTTPS/HTTPトラフィックのみを対象にし、不要なバックグラウンド通信を除外します。
• 社外IPアドレス（非RFC1918アドレス）からのイングレスのみをキャプチャし、外部脅威の検知に集中します。
• 既知の監視エージェント通信（SNMPやSSH等）を除外ルールで排除し、分析ノイズを低減します。
• 特定サブネット間の東西トラフィックのみをフィルタリングし、ラテラルムーブメントの検知に特化します。

パケットトランケーションは、転送するパケットを先頭Nバイトに切り詰める機能です。TLSペイロードの詳細内容が不要でTCPヘッダ情報のみを分析する場合など、帯域とストレージコストを抑えながら必要な情報を取得するシナリオに有効です。先頭64バイトを取得するだけでEthernetヘッダ・IPヘッダ・TCPヘッダの全フィールドを包含でき、接続メタデータの詳細分析には十分な場合があります。

フィルタとパケットトランケーションを組み合わせることで、分析アプライアンスへの転送量を大幅に削減でき、コスト抑制と処理性能向上を同時に実現できます。

5-4. VXLANカプセル化とセキュリティグループ設計

ミラーリングされたトラフィックは、VXLANプロトコル（RFC 7348）でカプセル化されてミラーターゲットへ転送されます。VXLANカプセル化はUDPポート4789を使用します。このポートはオリジナルのフレームをUDPペイロードにカプセル化して転送するための標準的な仕組みです。

ミラーターゲットのセキュリティグループへのUDP 4789許可漏れが、設定上の最も多いつまずきポイントです。ミラーセッションを作成してもトラフィックが分析アプライアンスに届かない場合の第一チェックポイントとして認識してください。

ミラーターゲットのセキュリティグループに設定するインバウンドルールの例を示します。

プロトコル : UDP
ポート範囲 : 4789
ソース  : ミラーソースENIが属するサブネットのCIDR
説明 : VXLANトラフィック（Traffic Mirroring）

NLBターゲットを使用する場合はNLBのセキュリティグループに、GWLBeターゲットを使用する場合はGWLBe側のルールに同様の許可を設定します。

さらに、分析アプライアンスインスタンス自体のセキュリティグループにも、ターゲット（NLBまたはGWLBe）が属するサブネットCIDRからのUDP 4789イングレスを許可するルールが必要です。NLBのIPアドレスは固定IPではないため、NLBが配置されるサブネットのCIDRを許可ソースとして指定するのが一般的な設計です。

また、ミラーセッションはクロスリージョンをサポートしないため、ソースとターゲットを同一VPC内またはVPC Peeringで接続された同一リージョン内に配置します。

5-5. コスト設計とサンプリング戦略

Traffic Mirroringの料金は、ミラーセッションを作成したENIの数と実際に転送されたミラーリングトラフィックのデータ量に基づく従量課金です。全トラフィックを常時ミラーリングすると、本来のEC2通信コストと同等かそれ以上のコストが発生します。

コスト爆発を防ぐための設計指針を以下に整理します。

フィルタによるスコープ絞り込み

分析に必要なプロトコル・ポート・方向のみをフィルタで許可し、不要なトラフィックを転送しません。常時監視が必要な通信（外部からのイングレスHTTPS等）に限定するだけで転送量を数分の一に抑えられます。全許可（all traffic）のフィルタはアンチパターンです。

パケットトランケーションの活用

ペイロード内容が不要な場合はパケットを先頭64〜128バイトに切り詰め、帯域とストレージを削減します。フロー分析主体の用途では、フルペイロードキャプチャは不要なことが多いです。

必要時のみのオンデマンド有効化

インシデント調査やセキュリティ検証が必要なときだけTraffic Mirroringセッションを作成し、不要になったら削除するオンデマンド運用が最もコスト効率に優れます。自動化にはEventBridge + Lambdaを組み合わせたトリガー起動が有効で、GuardDutyのFindingをトリガーにTraffic Mirroringを自動起動するパターンがよく使われます。

ミラーセッション数の最適化

複数のソースENIから同一のミラーターゲット（NLB等）へ向けることで、アプライアンスを共有してコストを分散できます。ただし、アプライアンスの処理能力との兼ね合いで過負荷にならないよう、セッション数と帯域を設計します。

5-6. 代表的なユースケース

Traffic Mirroringが威力を発揮する主なユースケースを整理します。

セキュリティ脅威の検知と証拠保全

IDS/IPSアプライアンスへのミラーリングにより、ネットワーク侵入・C2（コマンドアンドコントロール）通信・ラテラルムーブメントをパケットレベルで検知します。疑わしい通信のフルパケットキャプチャは法的証拠として保全でき、インシデントレスポンスに不可欠な証跡となります。

アプリケーションパフォーマンス診断

TCPリトランスミッション・RSTパケット・大きなTCPウィンドウ縮小など、Flow Logsでは見えないパケットレベルのシグナルを分析することで、ネットワーク起因のレイテンシ問題の根本原因を特定できます。アプリケーションのタイムアウトやエラーレートが上昇した際、アプリ層とネットワーク層の切り分けに有効です。

コンプライアンス・規制対応

PCI-DSSやHIPAAなど特定のコンプライアンスフレームワークでは、ネットワークトラフィックの詳細な監査ログが要求されます。Traffic Mirroringは、フローメタデータだけでは満たせない詳細なトラフィック記録要件への対応に活用できます。

マルウェア通信の事後解析

セキュリティインシデント後、感染の疑いがあるEC2インスタンスの通信を遡ってパケット単位で解析することで、マルウェアのC2通信パターンや情報漏洩の痕跡を特定できます。Flow Logsの接続ログと組み合わせて分析の起点を絞り込み、Traffic Mirroringのキャプチャデータで詳細を確認する段階的アプローチが効果的です。

5-7. CLIによるミラーセッション管理とモニタリング

Traffic MirroringはAWS CLIおよびSDKから操作できます。マネジメントコンソール以外での管理が必要なCI/CDや自動化環境での操作フローを確認しておくことが重要です。

ミラーセッションの作成は、ミラーフィルタ（create-traffic-mirror-filter / create-traffic-mirror-filter-rule）、ミラーターゲット（create-traffic-mirror-target）、セッション（create-traffic-mirror-session）の順に3ステップで行います。セッション削除（delete-traffic-mirror-session）は即時反映されるため、オンデマンド有効化/無効化の自動化に適しています。

CloudTrail監査との連携

Traffic Mirroringの操作（セッション作成・削除・フィルタ変更）はCloudTrailに記録されます。誰がいつどのENIにミラーセッションを設定したかの監査ログが自動的に取得でき、セキュリティインシデント時の調査や変更管理に活用できます。

CloudWatchメトリクスによる監視

ミラーターゲットのネットワークインターフェースのトラフィック量（NetworkIn/NetworkOut）をCloudWatch Metricsで監視することで、ミラーリングが正常に動作しているかを確認できます。予期しないトラフィック量の急増はコスト超過の兆候として検知できます。

異常検知のアラーム設計

ミラーセッションが存在するにもかかわらずターゲットENIのNetworkInがゼロの場合、VXLANポート（UDP 4789）の疎通不良を示している可能性があります。この状態をCloudWatchアラームで検知し、セキュリティグループの設定ミスを早期発見できます。

5-8. 分析アプライアンスの選択

ミラーリングされたトラフィックの受信・解析には、用途に応じたアプライアンスを選択します。

オープンソースでは、Suricata（IDS/IPS）やZeek（旧Bro、ネットワーク動作分析）がTraffic Mirroringと組み合わせてよく使われます。どちらもVXLANデカプセル化に対応しており、EC2インスタンス上でのセルフ管理型デプロイが可能です。商用アプライアンスの場合は、AWS Marketplaceで提供されるGWLB対応のIDS/IPS製品をGWLBeターゲットと組み合わせる構成が一般的です。

分析アプライアンスはインラインではなく帯域外（out-of-band）で動作するため、アプライアンス自体の障害がトラフィックに影響を与えません。これはインライン型のNFW（Network Firewall）とは異なる大きな利点であり、監視機能のためのダウンタイムなしでのアプライアンス更新が可能です。

AWS Marketplaceでは、Network Traffic Analysis（NTA）カテゴリの製品がGWLBターゲットに対応しており、Traffic Mirroringとシームレスに統合できます。

6. CloudWatch Network Monitor・Network Manager — 性能・トポロジ監視

到達性とパケットの可視化に加え、ネットワーク性能とトポロジを継続的に監視するのがCloudWatch Network MonitorとNetwork Managerです。本節では、Network Flow Monitorのマルチアカウント対応・CloudWatch Network Monitorとの使い分け・Internet Monitorの位置づけ・Network Managerのトポロジ可観測性を扱います。

6-1. CloudWatch Network Flow Monitor — ワークロード間の性能可視化

Network Flow Monitorは、AWSコンピュートリソースとAWSサービス間のネットワーク性能をニアリアルタイムで可視化するサービスです。EC2インスタンスやEKS Podと、Amazon S3・Amazon RDS・Amazon DynamoDB・Elasticacheなどのマネージドサービス間のフロー性能を対象とし、通信の遅延・パケットロス・到達性を継続的に計測します。

2025年5月のOrganizations統合によるマルチアカウント対応

2025年5月のアップデートで、AWS Organizations統合によるマルチアカウント監視が追加されました。これにより、複数のAWS組織アカウントにまたがるワークロードのネットワークフロー性能を、統一されたオンボーディング手順と単一の統合ビューで把握できます。

従来は各アカウントで個別にNetwork Flow Monitorを設定し、アカウントをまたぐ性能問題の把握が困難でした。Organizations統合では、管理アカウントまたは委任管理者アカウントから組織全体を一括オンボーディングし、マルチアカウントにわたるフロー性能ダッシュボードを提供します。

可視化できる性能メトリクス

Network Flow Monitorが収集する主要なメトリクスは以下の通りです。

• 往復遅延（RTT）: クライアントとサーバー間の往復レイテンシ。EC2↔RDS間のデータベースアクセス遅延の検出に有効です。
• パケットロス率: ネットワーク輻輳や誤ったルーティングに起因するパケット損失率。アプリケーションの断続的なエラーの原因切り分けに使用します。
• データ転送量: フローごとのバイト数・パケット数の統計。ホットスポットの特定やコスト分析に活用できます。

Network Flow Monitorは「なぜアプリケーションがS3に対して断続的にタイムアウトするのか」「EKSクラスターとRDSインスタンス間のレイテンシがP99で跳ね上がっている原因はネットワーク層か」など、アプリケーションログだけでは判断できないネットワーク起因の障害切り分けに特に有効です。

6-2. CloudWatch Network Monitor — ハイブリッド接続監視

CloudWatch Network Monitor（2023年12月GA）は、オンプレミスとAWSクラウド間のハイブリッドネットワーク接続を監視するサービスです。Network Flow Monitorと名称が似ていますが、用途が異なります。

Network Monitorは、AWS内のエンドポイントにICMPまたはTCPプローブを設定し、ハイブリッド接続（AWS Site-to-Site VPN・AWS Direct Connect）の通信品質を継続的に計測します。プローブ結果はCloudWatch Metricsとして発行され、アラームやダッシュボードと組み合わせた運用監視を実現します。

2つのサービスの使い分けを整理します。

• CloudWatch Network Flow Monitor: AWSコンピュート↔AWSサービス間のフロー性能。Organizations統合でマルチアカウント対応（2025-05〜）。
• CloudWatch Network Monitor: オンプレミス↔AWSのハイブリッド接続の品質。プローブ（ICMP/TCP）による能動的計測。

6-3. Amazon CloudWatch Internet Monitor

Internet MonitorはNetwork MonitorおよびNetwork Flow Monitorとは独立したサービスで、AWSリソース（CloudFront・NLB・VPC等）からエンドユーザーへのインターネット経路の通信品質を監視します。

AWSのグローバルネットワークとISPが保持するインターネット経路データを活用し、どの地域のどのISP/ASで遅延やパケットロスが発生しているかをリアルタイムで可視化します。CloudFrontディストリビューションやNLBに関連付けることで、エンドユーザーの実際のパフォーマンス体験を地理・ISP別に把握できます。

Internet MonitorはL4/L3のネットワーク可観測性スタック（Flow Logs/Traffic Mirroring/Network Flow Monitor）とは位置づけが異なり、インターネットエッジからエンドユーザーへの最終マイルに焦点を当てた独立したサービスです。

6-4. Network Manager（Global Network）のトポロジ可観測性

AWS Network Managerは、AWS Transit Gatewayを中心としたグローバルネットワークのトポロジを可視化・監視するサービスです。

Global Networksダッシュボードの4つのビュー

Network Managerは、Global Networksとして登録したTGW・SD-WAN・オンプレミス接続を以下4種類のビューで可視化します。

• リソースビュー: VPC・TGW・VPN接続・Direct Connect Gatewayなどのネットワークリソース一覧と接続状態をリスト形式で確認します。
• 地理的ビュー（Geographic View）: リソースの物理的な地理的配置を世界地図上にマッピングし、リージョン間の接続トポロジを視覚的に把握します。
• トポロジビュー（Topology View）: TGWアタッチメント・VPC・VPN・Peeringなどの論理的な接続関係をグラフ構造で表示します。設定変更前のインパクト把握やトラブルシューティングの起点として活用できます。
• 論理的ビュー（Logical View）: SD-WANやオンプレミス側のデバイスとAWS接続を、業務単位のセグメントとして論理的に表現します。

CloudWatchイベント転送と15か月統計

Network ManagerはCloudWatch Metricsへイベントを転送し、最大15か月分のネットワーク統計データを保持します。TGWアタッチメントごとのバイト数・パケット数・パケットドロップ率などのメトリクスを時系列で追跡でき、長期的な容量計画やトレンド分析に活用できます。

EventBridgeイベントとアラーム連携

Network Managerはネットワーク状態の変化を以下のカテゴリでEventBridgeイベントとして発行します。

• トポロジ変更: TGWアタッチメントの追加・削除・ルートテーブルの変更
• ルーティング更新: TGWルートテーブルのルート追加・削除・変更
• ステータス更新: VPN接続・Direct Connect接続のUP/DOWN状態変化

これらのEventBridgeイベントをLambdaやSNSと組み合わせることで、ネットワークトポロジの変化を即時通知するアラートシステムを構築できます。CloudWatchアラームとの連携により、TGWのパケットドロップ率が閾値を超えた場合の自動アラーム発報も実現します。

6-5. 性能・トポロジ監視サービスの使い分け

本節で扱った監視サービスは、監視対象レイヤーと用途が異なります。

• Network Flow Monitor: AWSコンピュート↔AWSサービス間フローの性能。アプリ性能問題のネットワーク起因切り分けに使用します。
• CloudWatch Network Monitor: オンプレミス↔AWSハイブリッド接続の品質。VPN/Direct Connect品質の継続検証に使用します。
• Internet Monitor: エンドユーザー↔AWSエッジ間のインターネット通信品質。地域・ISP別のユーザー体験品質把握に使用します。
• Network Manager: TGW中心のグローバルトポロジの可視化・変更検知。接続状態とトポロジの継続監視に使用します。

実際のマルチアカウント環境では、Network Flow Monitor（アプリ層のフロー性能）とNetwork Manager（トポロジ・接続状態）を組み合わせることで、「どの接続経路の」「どの性能指標が」「どう変化したか」を多層的に把握できます。

6-6. マルチアカウント可観測性の運用設計

本節で扱ったサービスを組み合わせて、マルチアカウント環境での統合的なネットワーク可観測性を設計する際の指針を整理します。

Organizations統合アーキテクチャ

Network Flow MonitorのOrganizations統合を活用する場合、管理アカウント（または専用の委任管理者アカウント）から組織全体のフロー性能を一元監視します。個別アカウントの開発者には自アカウントのフローのみ表示するロールを付与し、プラットフォームチームには全アカウントの統合ビューを付与するというロール設計が一般的です。

ネットワーク可観測性の階層設計

マルチアカウント環境では、以下の3層で可観測性を設計します。

• アカウント個別層: 各ワークロードアカウントでのVPC Flow Logs収集・Traffic Mirroringのオンデマンド起動・Reachability Analyzer実行
• ネットワークハブ層: Transit GatewayアカウントでのNetwork Manager Global Networks・TGWメトリクス・クロスアカウントNetwork Flow Monitor統合ビュー
• セキュリティ/観測集約層: セキュリティアカウントでのGuardDuty連携・S3へのFlow Logs集約・Athenaによるクロスアカウント分析

アラーム・通知設計

各サービスのCloudWatchアラームを集約し、EventBridge + SNS + Chatbot（Slack等）でエンジニアへ通知するパイプラインを構築します。Network ManagerのEventBridgeイベント（トポロジ変更/接続断）はネットワークインフラの変化として、Network Flow Monitorのアラーム（高レイテンシ/パケットロス増加）はアプリ影響として、それぞれ適切な通知先へルーティングします。

定期レポートとキャパシティプランニング

Network ManagerのCloudWatch 15か月統計を活用し、TGWアタッチメントの帯域利用率のトレンドを週次・月次で可視化します。帯域使用率が一定閾値（例：70%）を超えた際に自動レポートを生成し、キャパシティ増強の意思決定を支援する仕組みを構築できます。

6-7. CloudWatch Network Flow Monitor エージェント設計

Network Flow MonitorはVPC Flow Logsとは異なり、エージェントベースでデータを収集します。EC2インスタンスにエージェントをインストールし、フロー情報をサービスに送信する仕組みです。

エージェントのインストールとアップデート管理

AWS Systems Manager（SSM）Distributor を使ったエージェントの一括インストールが推奨されます。Auto Scaling Groupとの組み合わせでは、起動設定にエージェントインストールのユーザーデータを組み込み、スケールアウト時に自動的にモニタリングが有効化されます。

EKS環境でのエージェント設計

Amazon EKS環境では、DaemonSetとしてエージェントをデプロイし、ノード上のすべてのPodのフローを収集します。Fargateベースのワークロードはエージェントインストールが不要な方式でサポートされています。Node Groupのスケールや新しいノードの追加時にも自動的にエージェントがデプロイされるよう、DaemonSet管理を組み込んだCI/CDパイプラインを設計します。

データ保持期間とクエリ

Network Flow Monitorが収集したフロー性能データはCloudWatch Metricsに保存され、標準の保持期間（15か月）が適用されます。CloudWatch Metrics Insightsを使ったカスタムクエリにより、特定のワークロードペアのレイテンシトレンドや、組織全体でのパケットロス上位フローを検索・可視化できます。

6-8. 障害時のトリアージフロー

性能監視サービスを活用した障害時のトリアージフローを整理します。

1. アラーム受信: Network Flow MonitorのRTTアラームまたはNetwork ManagerのEventBridgeイベントで障害を検知します。
2. 影響範囲特定: Network Flow Monitorの統合ビューで、どのアカウント・フローで性能劣化が発生しているかを特定します。
3. トポロジ確認: Network Managerのトポロジビューで、影響を受けているフローが経由するTGW・VPC・VPN接続を可視化し、トポロジ変更と障害の相関を確認します。
4. 詳細分析: 必要に応じてReachability Analyzerで到達性を確認し、Traffic Mirroringでパケットレベルの詳細を取得します。

このフローにより、アプリケーション障害がネットワーク性能劣化に起因するか、構成変更によるトポロジ変化に起因するかを体系的に切り分けられます。

Network Flow MonitorのRTTやパケットロス値が正常範囲内であればネットワーク層は健全であり、アプリケーション層・データベース層の調査へ移行できます。逆にネットワーク指標の悪化が確認された場合は、Network Managerのタイムラインと照合することで変更起因か環境起因かを判別します。

このトリアージフローをRunbookとして整備し、チーム全体で共有することで、担当者によらず一貫したネットワーク障害対応ができる体制を構築します。

7. 実戦統合パターン — 可観測性スタック設計とマルチアカウント対応

§2〜§6で扱った各機能を、実際のマルチアカウント環境でどう組み合わせて「ネットワーク可観測性スタック」を構成するかを設計します。本節では、コスト効率を考慮した段階的可観測性スタック設計・マルチアカウント対応・ツール選択の判断指針を体系的に整理します。あらかじめ「どのツールをいつ使うか」の設計基準を持つことで、インシデント時にすばやく適切なツールへ誘導でき、調査時間を大幅に短縮できます。

個別のツール設計は§2〜§6で扱いましたが、実際の運用では複数のツールが連携することで可観測性の価値が最大化されます。Flow Logsが傾向を示し、Reachability Analyzerが構成の問題を特定し、Network Access Analyzerがセキュリティ経路を検証し、Traffic Mirroringが詳細を確認し、Network Monitorが性能を計測する、という5つの視点が揃って初めて「ネットワーク上で何が起きているか」を完全に把握できます。本節ではこの統合設計を実装します。

7-1. 段階的可観測性スタックの設計

ネットワーク可観測性の5つのツールは、コストとユースケースが大きく異なります。常時稼働させてコストをかけ続けるツールと、必要なときだけ起動するオンデマンドのツールを明確に分け、3段階のスタックとして整理することがコスト対効果を最大化する基本設計です。「常時記録・性能監視」「変更・インシデント対応」「ディープ調査」という3つの目的に対応した3層構造が、実際の運用で機能する設計パターンです。

第1層：常時稼働（低コスト・常設）— Flow Logs + Network Flow Monitor

常時稼働させておくべきは、VPC Flow Logs（S3+Parquet）とCloudWatch Network Flow Monitorの2つです。この2つは、ネットワーク可観測性の基礎となるベースラインとして常設し、他のツールを使う判断の起点として機能させます。

VPC Flow LogsをAmazon S3にHive互換Parquet形式で出力する構成は、1GBあたりのAthenaスキャンコストを最小化しながら、すべての通信メタデータを保持します。Flow LogsはVPC・サブネット・ENI単位で有効化でき、拡張フィールド（pkt_srcaddr・traffic_path・pkt_dst_aws_service等）を含むカスタムフォーマットを最初から設定しておくことが重要です。障害発生後にフォーマットを変えても過去データには反映されないため、拡張フィールドは「最初から全て取る」という方針が合理的です。コストの主体はS3ストレージ（0.023 USD/GB/月）とAthenaスキャン（5 USD/TB）であり、リアルタイム分析が不要な場合はCloudWatch Logsへの同時配信を避けることでコストを抑制できます。セキュリティ異常の即時検知が要件であれば、CloudWatch Logsへの配信とメトリクスフィルタ・アラームを組み合わせることも選択肢です。

CloudWatch Network Flow Monitorは、EC2・EKSとS3・RDS・DynamoDBなどのAWSサービス間のネットワーク性能を継続的にベースライン化します。ニアリアルタイムの性能異常を検出するセーフガードとして常設し、「性能劣化が起きている事実」を数値で確認してから詳細調査へ移る起点として機能します。2025年5月のアップデートでAWS Organizations統合に対応し、複数アカウントにまたがるワークロードの性能を委任管理アカウントから一元的に監視できるようになりました。

第2層：変更・インシデント対応（オンデマンド）— Reachability Analyzer + Network Access Analyzer

VPC Reachability AnalyzerとNetwork Access Analyzerは、インフラ変更時・インシデント発生時にオンデマンドで起動するツールです。常時実行するのではなく、「必要なタイミングで分析する」設計が費用対効果に優れます。

Reachability Analyzerは1回の分析あたり0.10 USDの従量課金です。CI/CDパイプラインに組み込んでインフラ変更（セキュリティグループ更新・ルートテーブル変更・NACL変更等）のたびに自動実行する、あるいはインシデント発生時に「通信が届かない理由」を即座に特定するべく起動するという使い方が典型的です。0.10 USD/回という料金は、手動のトラブルシューティングに費やすエンジニア工数と比較すれば十分に低コストであり、変更ごとの自動検証をためらう必要はありません。

Network Access Analyzerは、インフラ変更後のセキュリティコンプライアンス検証や、定期的なゼロトラスト監査のタイミングで実行します。一度スコープを定義すれば繰り返し再実行できるため、設計変更ごとにCIパイプラインから自動実行することで意図しない接続経路の混入を継続的に検証でき、定期的な監査コストを大きく削減できます。

第3層：深掘り調査（高コスト・短期）— Traffic Mirroring

Traffic Mirroringは、パケットレベルのディープ調査が必要なケースにのみ限定して起動し、調査完了後は速やかに無効化します。全インスタンスのENIを常時ミラーリングすると、ミラーリング先への転送コストと分析アプライアンスの処理コストが線形に増加するため、スコープを最小化する設計が不可欠です。

フィルタ（特定ポート・特定CIDRのみ）とパケットトランケーション（ヘッダーのみ抽出）を組み合わせてミラーリングするトラフィックを絞り込み、調査目的を達成したら即座に無効化することがコスト管理の基本です。Flow Logsで「大量のREJECTがある」「特定ENIからの転送バイトが異常に多い」「既知のアプリケーション通信とは異なるポートが頻出している」といった異常の傾向を把握した後、「パケットの中身を確認する必要がある」局面で初めてTraffic Mirroringへエスカレートするという判断フローが適切です。

7-2. マルチアカウント可観測性の設計

マルチアカウント環境では、各アカウントで個別に可観測性を設定するのではなく、集中管理を基本設計とします。ツールごとにマルチアカウント対応の仕組みが異なるため、それぞれの特性を理解して統合設計します。設計のゴールは「可観測性の抜け漏れをなくしつつ、運用コストを最小化する」ことです。

Network Flow Monitor — Organizations統合による一元管理

Network Flow Monitorは、2025年5月のアップデートでAWS Organizations統合に対応しました。管理アカウントまたは委任管理アカウントから組織全体のフロー性能データをオンボードでき、統合ビューですべてのメンバーアカウントにまたがるワークロードの性能を監視できます。個別アカウントでモニタリングを設定する必要がなく、新規アカウントの追加時も自動的に監視対象に加えられるため、大規模マルチアカウント環境での運用コストを削減します。

実際の設定では、委任管理アカウントのCloudWatch Network Monitorコンソールから「Organizations統合を有効化」を操作し、メンバーアカウントへのデータアクセスを許可するサービスリンクロールが自動作成されます。統合ビューで性能異常を検出したら、アカウントIDとフロー区間を起点に詳細調査へ移ります。委任管理アカウントにCloudWatchアラームとEventBridgeルールを集中配置することで、マルチアカウント全体の性能アラートを一元管理できます。

VPC Flow Logs — 中央集約アカウントのS3への集約

Flow Logsは、各アカウントのVPCから中央集約アカウントのS3バケットへ直接書き込む設計が、大規模環境では標準的です。S3バケットポリシーで各ワークロードアカウントのFlow Logsサービス（delivery.logs.amazonaws.com）からのオブジェクト書き込みを許可することで、各アカウントから追加設定なしにログを集約できます。

AWS GlueデータカタログとAthenaを集約アカウントに配置し、全アカウントのネットワーク通信を一元的に分析できます。Hive互換パーティション（account-id/region/year/month/day）を設計することで、特定アカウント・特定期間のデータを効率的にクエリでき、クロスアカウント分析の運用コストを最小化します。例えば、特定アカウントの特定日付のREJECTフローを集計するといったアカウント別の事後分析が、Athenaの単一クエリで完結します。

集約アカウントへのAthenaアクセス権限は最小権限原則に基づいて設計し、ネットワーク分析担当チームのIAMロールにのみクエリ実行を許可します。AWS CloudTrailによる操作証跡と組み合わせることで、誰がいつどのネットワーク分析をしたかの監査証跡も確保します。

Reachability Analyzer・Network Access Analyzer — クロスアカウントの制約と回避策

Reachability Analyzerは、同一リージョン内の同一VPCまたはPeering・TGW接続済みのVPCを分析対象とします。クロスアカウントのVPC Peering・Transit Gateway経由で接続されているリソースも分析できますが、ソースと宛先のリソースは同一リージョンに存在する必要があります。マルチアカウント・マルチリージョン構成では、リージョンごとに分析を実施し、結果を組み合わせて全体像を判断します。2025年5月のresource exclusionにより、分析から除外したいネットワークリソース（メンテナンス対象等）をスキップして実行できるようになりました。

Network Access Analyzerは、同一アカウント内のVPCリソースを対象としたスコープ検証が基本です。アカウントをまたぐアクセス経路の検証には、中央ネットワークアカウントに集約されたTGWやVPC Peering経由の接続に対して、接続点（TGW Attachment・Peeringエンドポイント）をスコープの起終点に設定することで対応します。「中央ネットワークハブ起点」のスコープ設計を基本とすることで、マルチアカウント環境でも意図しない通過経路を効率的に検出できます。

7-3. ツール選択判断指針

「ネットワークの何を知りたいか」を起点に、適切なツールを選択する判断指針を整理します。障害対応・セキュリティ検証・コスト最適化のいずれの場面でも、最初に「何を知りたいか」を明確にしてから対応するツールへ迷わず誘導することが、調査時間を短縮する基本です。5つの代表的なシナリオに対してツールを紐付けます。

「つながらない」→ Reachability Analyzer

「特定のEC2インスタンスからDBインスタンスへアクセスできない」「VPCエンドポイント経由のS3接続が失敗する」「TGW経由のVPC間通信が届かない」など、ポイント間の到達性が期待通りでない場合はReachability Analyzerから着手します。ネットワーク構成のモデルから到達性を即座に検証し、到達不可の場合はセキュリティグループ・ルートテーブル・NACLなど、具体的なブロッキングコンポーネントをhop-by-hopで特定します。パケットを送信しないため本番環境に影響を与えず、ルート変更後・セキュリティグループ更新後の接続確認にも活用できます。手動のping疎通確認に頼るよりも、設定ミスの根本原因を即座に特定できるReachability Analyzerへの誘導がコスト・時間の両面で合理的です。

「意図しない経路がないか確認」→ Network Access Analyzer

「新しいVPC Peeringを作成したが、意図しないアクセス経路が生まれていないか確認したい」「ゼロトラスト移行後に不要な接続経路が残っていないかスキャンしたい」「セキュリティ監査でアクセス経路の網羅的な洗い出しが求められている」という場合はNetwork Access Analyzerを使います。スコープ全体のFindingsを網羅的に生成し、想定外の接続が存在しないことをシステム的に確認します。CI/CDパイプラインからインフラ変更のたびに自動実行することで、アクセス経路の継続的な検証を自動化し、手動レビューの抜け漏れを排除できます。

「何が流れているか確認」→ VPC Flow Logs

「どの送信元からどの宛先へ・どのポートで・どれだけのバイト数が流れているか」を把握したい場合はVPC Flow Logsで事後分析します。常時記録されているため過去のトラフィックパターンを振り返れ、コスト分析（AWSサービス宛トラフィックの内訳をpkt_dst_aws_serviceで集計）・セキュリティ分析（REJECTフロー集計・異常な外部接続の検出）・容量計画（ENI別バイト数のトレンド把握）に幅広く活用します。

拡張フィールドをフル活用することで分析精度が大きく変わります。pkt_srcaddrでNATの背後の実送信元IPを把握し、pkt_dst_aws_serviceでDynamoDB・S3・EC2等のAWSサービス宛通信をサービス別に集計し、traffic_pathでIGW・VPCエンドポイント・Transit Gatewayなどどの経路を通過したかを特定できます。flow_direction（ingress/egress）と組み合わせることで、インバウンド・アウトバウンドそれぞれのトラフィックパターンを分離して分析できます。

「パケットの中身の詳細調査」→ Traffic Mirroring

「Flow LogsでREJECTが多発しているが原因が特定できない」「不審な通信パターンがあり、実際のペイロードを確認したい」「アプリケーション層のプロトコル異常を切り分けたい」という場合はTraffic Mirroringを起動します。フィルタ設定で対象ENI・特定ポート・特定CIDRに絞り込み、パケットキャプチャアプライアンス（Suricata・Zeek等）と組み合わせてディープパケット検査を実施します。調査対象を必要最小限に絞り、調査目的を達成したら速やかに無効化します。フィルタなしで大量のトラフィックをミラーリングするとコストが急増するため、「まずフィルタでスコープを絞ってから起動」を習慣にします。

「ハイブリッド接続の性能劣化」→ CloudWatch Network Monitor

「Direct Connect経由の拠点間通信でレイテンシが悪化している」「特定フローのスループットが低下している」「S3への書き込み速度が低下していて原因がネットワークかアプリか判別できない」など性能観点の問題はCloudWatch Network Monitorから診断します。ニアリアルタイムの性能メトリクスで劣化の発生有無とフロー区間を確認し、性能劣化がネットワーク層で実際に起きているという事実を数値として確認したうえで、必要に応じてTraffic MirroringやFlow Logsの詳細分析へエスカレートする判断を下します。CloudWatch Network Monitorの結果でネットワーク性能に問題がなければ、アプリケーション層（タイムアウト設定・コネクションプール等）に原因を絞り込むことができます。

以上が代表的な5つのシナリオです。実際の障害対応や運用では複数のツールを組み合わせる場面が多くなります。「つながらない」のでReachability Analyzerを実行したが、到達性に問題がないとわかった場合、次はFlow Logsで「実際に通信が届いているかどうか」をREJECTフロー集計で確認し、「通信は届いているがアプリが応答しない」のであればネットワーク層ではなくアプリ層の問題と切り分けられます。このように「まずReachability Analyzerで構成を確認」→「Flow Logsで実際の通信パターンを確認」→「必要ならTraffic Mirroringでペイロードを確認」という調査ステップを体系化しておくことで、インシデント対応時の迷いを排除できます。

7-4. 段階的スタック構築のロードマップ

可観測性スタックをゼロから導入する場合、すべてのツールを一度に有効化するのではなく、段階的に積み上げる進め方がリスクとコストの面で適切です。既存環境への段階的な追加も、同じ順序で行うことが推奨されます。以下の5つのステップは、実際に推奨される導入順序とポイントを整理したものです。各ステップで動作確認と効果測定をして、次のステップへ進む判断をします。

ステップ1: Flow Logsの拡張フィールド設定（第1週）

最初に行うべきは、全VPCのFlow LogsをS3（Hive互換パーティション＋Parquet）へ有効化することです。カスタムフォーマットにpkt_srcaddr・pkt_dstaddr・pkt_src_aws_service・pkt_dst_aws_service・traffic_path・flow_direction・az_idを含め、後から変えられない拡張フィールドを最初から取得しておきます。Athena統合をVPCコンソールから設定し、サンプルクエリ（上位転送バイト数のフロー集計・REJECTフローの送信元集計）で分析基盤が機能することを確認します。

ステップ2: Network Flow Monitorの有効化（第1〜2週）

Flow Logs基盤が安定したら、CloudWatch Network Flow Monitorを有効化します。マルチアカウント環境ではOrganizations統合を委任管理アカウントから有効化し、主要なワークロード（EC2↔RDS・EC2↔S3・EC2↔DynamoDB）のフロー性能をベースライン化します。30日間のベースライン蓄積後、異常値のしきい値をCloudWatchアラームで定義します。

ステップ3: Reachability AnalyzerのCI組み込み（第2〜3週）

IaCツール（AWS CloudFormation・Terraform等）によるインフラ変更パイプラインに、Reachability Analyzerの自動実行を組み込みます。変更前後の到達性を検証するステップをCIに追加することで、セキュリティグループ変更・ルートテーブル変更によるアクセス断を本番適用前に検出できます。最初は主要な接続パス（アプリサーバー→DBサーバー・アプリサーバー→VPCエンドポイント）から開始し、徐々に対象を拡張します。

ステップ4: Network Access Analyzerの定期監査（第3〜4週）

スコープを設計し、Network Access Analyzerの初回スキャンを実施します。Findingsを確認して既知の意図的な接続経路（許可リスト）と意図しない接続経路（是正対象）を仕分けし、是正対象の修正を完了させます。以降はCIパイプラインからの変更時自動実行と、四半期ごとの全体スキャンを定例化します。

ステップ5: Traffic Mirroringの運用化（随時）

Traffic Mirroringは、インシデント対応や深掘り調査の際にすぐ起動できるよう、事前に「起動手順書・フィルタテンプレート・ターゲット設定」を整備しておきます。常時有効化するのではなく、「起動→調査→無効化」というライフサイクルの手順を運用チームで共有し、コスト管理の観点でも月次でミラーリング設定の棚卸しをします。

8. つまずきポイント・アンチパターン・まとめ

§2〜§7でネットワーク可観測性スタックの実装を一通り扱いました。本節では、実際にVPC Flow Logs・Reachability Analyzer・Network Access Analyzer・Traffic Mirroring・Network Monitorを導入・運用する際によく遭遇するつまずきポイントをパターン化し、症状・原因・対処のセットで整理します。続いて、繰り返し見られる設計上のアンチパターンを「❌ 避けるべき設計」と「✅ あるべき設計」の対比形式で示し、最後に本Vol1のまとめと関連記事へのナビゲーションをお伝えします。

8-1. つまずきポイント

つまずき①：Flow Logs拡張フィールドを追加しなかったためNATゲートウェイ背後の実IPが特定できない

症状

VPCのNATゲートウェイ経由でインターネットへ通信するEC2インスタンスのフローログを確認したところ、送信元IPアドレスがNATゲートウェイのパブリックIPアドレスになっており、実際にどのインスタンスやコンテナからの通信か特定できなかった。セキュリティインシデントで送信元を特定しようとしたが調査が止まった。

原因

VPC Flow LogsのデフォルトフォーマットはV2フィールドのみで、srcaddrはNATゲートウェイのIPアドレスを記録します。パケットレベルの送信元IP（NATの内側の実IP）を記録する拡張フィールドpkt_srcaddr・pkt_dstaddrをカスタムフォーマットに含めていなかったため、NATゲートウェイ越えのトラフィックで実IPが見えなくなっていました。

対処

カスタムフォーマットにpkt_srcaddr・pkt_dstaddr・pkt_src_aws_service・pkt_dst_aws_service・traffic_path・flow_directionを追加し、Flow Logsを再作成します。分析目的に合わせてaz_id・subnet_id・instance_id・tcp_flagsも追加すると、NATゲートウェイ越えや内部サービス間通信の可視性が大幅に向上します。既存Flow Logsは一度削除して再作成するか、拡張フィールドを含む新しいFlow Logsを並行して作成します。

つまずき②：AthenaのパーティションをHive互換フォーマットにしなかったためフルスキャンで高額請求

症状

S3に出力したVPC Flow LogsをAthenaでクエリしたところ、特定の日付のデータを絞り込むWHERE句を書いても毎回全データをフルスキャンし、1回のクエリで数十GBをスキャンして高額の請求が発生した。

原因

VPC Flow LogsのS3宛先でHive互換パーティション（AWSLogs/{accountId}/vpcflowlogs/{region}/{year}/{month}/{day}/ の形式）を有効にしなかったため、Athenaがパーティションプルーニングを活用できず、テーブル全体をスキャンする動作になっていました。また、Parquetフォーマットではなくプレーンテキストのままにしていたことも、スキャンデータ量の増大に寄与していました。

対処

S3宛先のFlow Logs設定でHive互換フォーマット（/year={year}/month={month}/day={day}/ パーティションキー形式）を有効化し、Apache Parquet形式での出力を選択します。既存テーブルはVPCコンソールのAthena統合機能でHive互換テーブルを再作成し、MSCK REPAIR TABLEでパーティションを登録します。year・month・day・hourのパーティション列をWHERE句に必ず含めるクエリ設計を徹底することで、スキャン量を数十分の一から数百分の一に削減できます。

つまずき③：Reachability Analyzerが同一リージョン制約のためクロスリージョン検証に使えない

症状

東京リージョンのVPCとバージニアリージョンのVPCの間のトランジット接続を検証しようとしてReachability Analyzerでクロスリージョンの経路分析を試みたが、ソースと宛先を指定したところエラーが発生し実行できなかった。

原因

VPC Reachability Analyzerはコントロールプレーンのモデルを使ってパス検証を行うため、ソースと宛先が同一リージョン内に存在し、かつ同一VPCまたはVPC Peering・Transit Gateway経由で接続されている必要があります。クロスリージョンのリソースは直接指定できません。

対処

クロスリージョン間の到達性検証は、各リージョンで独立したReachability Analyzerを実行し、Transit Gatewayのアタッチメント境界でリレー検証する手順に分割します。すなわち「東京リージョンのインスタンス → 東京側TGWアタッチメント」、「バージニア側TGWアタッチメント → バージニアリージョンの宛先」の2段階で分析し、TGW間のルーティングはNetwork Managerのトポロジビューと組み合わせて確認します。

つまずき④：Traffic MirroringでVXLAN（UDP 4789）のSGインバウンド許可を忘れてミラーパケットが届かない

症状

Traffic Mirroringのミラーセッションを作成し、ミラーターゲット（NLB）へトラフィックが送信されているはずなのに、分析アプライアンスがパケットを受け取れなかった。設定上は問題がなく見えるが、Wiresharkで何も届いていない。

原因

Traffic MirroringはミラーリングしたパケットをVXLANカプセル化（UDPポート4789）でミラーターゲットへルーティングします。ミラーターゲットのENIに紐づくセキュリティグループのインバウンドルールに、ミラーソース側のCIDRまたはSGからのUDPポート4789の許可が含まれていない場合、カプセル化されたミラーパケットはSGレイヤーでドロップされます。NLBをターゲットに使う場合でも、バックエンドの分析アプライアンスが所属するSGにUDP 4789インバウンドの許可が必要です。

対処

ミラーターゲット（ENI / NLBバックエンドのEC2・コンテナ）のセキュリティグループのインバウンドルールに「UDP 4789 / ソース: ミラーソースのCIDRまたはSG」を追加します。設定後にキャプチャが開始されない場合は、ミラーフィルタのルールが対象トラフィックと一致しているかをACCEPTルールの優先度とプロトコル設定で確認します。

つまずき⑤：Network Flow Monitorのマルチアカウント有効化漏れで一部アカウントのフローが集計されない

症状

Network Flow Monitorで組織全体のネットワーク性能をモニタリングしようとしたが、複数の子アカウントのEC2インスタンスとRDS間のフロー指標が管理アカウントの統合ビューに表示されなかった。管理アカウント側では有効化されているのに子アカウントのデータが欠落している。

原因

2025年5月のAWS Organizations統合によるマルチアカウント対応以降、Network Flow Monitorのマルチアカウントオンボーディングは管理アカウントまたはDelegated Administratorアカウントから明示的に実施する必要があります。対応を有効化していない子アカウントのフローデータは収集されず、統合ビューに表示されません。

対処

Organizations管理アカウントまたはDelegated Administratorとして指定したアカウントから、Network Flow MonitorのOrganizations統合オンボーディング手順を実行し、対象の子アカウントをすべて有効化します。有効化後、対象アカウントのEC2インスタンスにNetwork Flow MonitorエージェントがSSM経由でインストールされているか確認します。エージェントが起動していないインスタンスはフローデータを送信しないため、Systems Managerのインベントリでエージェントステータスを定期的に監視する設計を組み込みます。

つまずき⑥：Flow LogsをS3に出力したがparquet変換後のスキーマ不整合でAthenaクエリが失敗する

症状

VPC Flow LogsをS3にParquet形式で出力し、Athenaのテーブルを手動作成してクエリしたところ、HIVE_PARTITION_SCHEMA_MISMATCHやSYNTAX_ERRORが発生してデータが読めなかった。VPCコンソールのAthena統合機能を使わず独自にテーブルを定義したケースに多い。

原因

Flow LogsのParquetスキーマはカスタムフォーマットで選択したフィールドに依存します。手動でCREATE EXTERNAL TABLE文を定義する場合、Flow Logsに含まれるフィールドの数・型・順序がAthenaのテーブル定義と一致しないと読み込みに失敗します。また、拡張フィールドを後から追加するとスキーマが変わり、既存テーブル定義との齟齬を生じることがあります。

対処

テーブル定義はVPCコンソールの「Amazon Athenaとの統合」機能から自動生成されるCloudFormationテンプレートを使います。カスタムフォーマット変更後はテンプレートを再生成してテーブルを再作成します。独自定義を使う場合は、実際に出力されたParquetファイルのスキーマをAWS Glue Data Catalogのクローラーで自動検出し、テーブル定義と整合させます。

つまずき⑦：Reachability Analyzerで「到達可能」と判定されてもアプリケーション層の接続エラーが継続する

症状

Reachability Analyzerでソースとなるアプリサーバーから宛先のRDSインスタンスへの到達性を検証したところ「Reachable（到達可能）」の結果が返ってきたが、実際にはアプリケーションがデータベース接続エラーを出し続けていた。SGとルートテーブルの設定に問題はないと判断してしまい、原因究明に時間がかかった。

原因

VPC Reachability Analyzerはネットワーク構成のコントロールプレーンモデルのみを評価します。評価できるのはSG・NACL・ルートテーブル・VPCエンドポイントポリシーなど、L3/L4のネットワーク層の設定です。L7のアプリケーション層（データベースの認証設定・IAM認証・SSL/TLS証明書の検証・パラメータグループの設定等）で発生している問題はReachability Analyzerでは検出できません。

対処

Reachability Analyzerで到達可能と確認した後は、アプリケーション層の問題切り分けを別手段で行います。RDSの場合はCloudWatch Logs（エラーログ・スロークエリログ）やRDS Performance Insightsを確認し、接続数上限・認証エラー・SSL設定の問題を確認します。Reachability Analyzerは「ネットワーク層の設定に問題がない」ことを証明するツールとして使い、L7問題の原因特定にはサービス固有のログとメトリクスを組み合わせます。

8-2. アンチパターン

❌ アンチパターン①：全トラフィックを常時Traffic Mirroringで常時取得してコストが爆発する

❌ すべてのEC2インスタンスのENIにTraffic Mirroringを常時設定し、フィルタを「全トラフィック許可」にして常時ミラーリングを実施する。インスタンス数が増えるにつれてミラーリング用の転送コスト・NLBコスト・分析アプライアンスのトラフィック処理コストが乗算的に増大し、毎月数十万円規模の予期しない請求が発生した。

✅ Traffic Mirroringはセキュリティインシデント調査や特定の通信パターンのディープ分析が必要な限られた期間にのみ有効化します。フィルタルールで対象プロトコル・ポート・CIDRを絞り込み、パケットトランケーション（必要な先頭バイト数のみキャプチャ）を活用してデータ転送量を最小化します。常時の通信可視化はVPC Flow Logs（メタデータ）で賄い、Traffic Mirroringは「必要な時・必要な範囲」でオンデマンドに起動する設計を基本とします。

❌ アンチパターン②：Flow LogsでTCP/IPレベルのパケット内容を分析しようとする

❌ Flow LogsでSSLハンドシェイクの内容や、HTTPリクエストのURIパス・ヘッダを取得しようとする。「フローログにパケットの詳細が記録されているはず」という誤解から調査を進めてしまい、必要なデータが取れずに時間を消費した。

✅ VPC Flow Logsはネットワークフローのメタデータ（IPアドレス・ポート・プロトコル・バイト数・パケット数・アクション等）のみを記録します。HTTP/Sのヘッダ・URI・ペイロード、SSL/TLSの証明書情報、アプリケーション層のデータを取得したい場合はTraffic Mirroringでパケットをキャプチャし、Wireshark等の分析ツールで処理します。Flow Logsはトラフィックの量・方向・到達性の把握に、Traffic Mirroringはパケット内容の深掘りにと、目的に応じたツール選択を徹底します。

❌ アンチパターン③：「つながらない」障害を手動pingと試行錯誤のSG変更だけで調査する

❌ EC2インスタンス間の接続エラーが発生した際に、SGのルールを次々と「0.0.0.0/0」開放して試し、pingで疎通を確認するというトライアンドエラーを繰り返す。本番環境のSGを広く開けてしまい、セキュリティリスクが高まった上に根本原因の特定に長時間を要した。

✅ VPC Reachability Analyzerを使ってソースと宛先を指定し、到達性を分析します。到達不可の場合、ブロッキングコンポーネント（特定のSGルール・NACL・ルートテーブルエントリ等）が特定されるため、最小限の変更で根本原因に対処できます。パケットを実際には送信しないモデルベースの分析のため本番影響なく実行でき、SGを試験的に開放するリスクを取る必要がなくなります。

❌ アンチパターン④：すべてのVPC/サブネットのFlow LogsをCloudWatch Logsに出力して格納コストが肥大する

❌ すべてのVPCとサブネット単位でFlow LogsをCloudWatch Logsへ出力し、ロググループの保持期間も設定しないまま運用する。マルチアカウント・マルチリージョン環境では月間のCloudWatch Logsの格納・スキャンコストが急増し、気づいたときには大きな請求になっていた。

✅ 用途に応じた宛先設計を実施します。リアルタイムアラートやDashboardでの可視化が必要なトラフィック（セキュリティ監視対象のサブネット等）はCloudWatch Logsに出力しつつ保持期間を7〜30日に絞ります。長期保管と大規模Athena分析が目的のフローデータはS3（Hive互換パーティション＋Parquet）に出力し、S3 Intelligent-TieringとLifecycleポリシーを組み合わせます。全データを漫然とCloudWatch Logsに流すのではなく、組織のログ要件に合わせた宛先・保持期間の設計が継続的なコスト最適化の鍵です。

❌ アンチパターン⑤：構成変更後にReachability Analyzerを手動で不定期にしか実行しない

❌ Reachability AnalyzerはGUIから必要になったときだけ手動で実行する運用にしており、インフラチームがTerraformでSGやルートテーブルを変更した後に到達性が壊れても即座には気づかない。本番障害が起きてから初めて分析し、変更のどの時点で壊れたか特定に時間がかかった。

✅ 重要なフローの到達性分析はEventBridgeルール（AWS Config「設定変更時」トリガー）やCI/CDパイプラインのデプロイ後フックで自動実行します。AWS Config のCustom Ruleとして実装し、到達性がReachableからNotReachableに変化したタイミングでSNSアラートを発報する設計にすると、構成変更によるデグレードを変更直後に検出できます。継続的な到達性の自動検証が運用上のセーフティネットになります。

8-3. まとめ

本Vol1では、接続構築済みのAWSネットワークを「可視化・検証・トラブルシュートする」ための可観測性スタックを3つの能力として実装しました。

① フローログ基盤（VPC Flow Logs）

拡張フィールドの設計・宛先の使い分け・Hive互換パーティションとParquet・Athena統合により、NATゲートウェイ越えの実IPを含む全通信のメタデータを継続的に可視化する基盤を構築しました。コスト最適化とパーティションプルーニングの設計が長期運用の鍵です。

② 到達性・アクセス経路の検証（Reachability Analyzer／Network Access Analyzer）

Reachability Analyzerでポイント間の到達性をモデルベース（本番影響なし）で検証し、Network Access Analyzerでスコープ全体の意図しないアクセス経路を網羅的に検出します。「繋がるべきものが繋がるか」と「繋がってはいけないものが繋がっていないか」の両方を継続的に自動検証するゼロトラスト運用の基盤となります。

③ パケット分析と性能監視（Traffic Mirroring／Network Monitor）

Traffic Mirroringでパケットレベルのディープ分析を実施し、Network Flow Monitorのマルチアカウント監視とNetwork Managerのトポロジ可観測性で性能とインフラ全体の状態を継続把握します。

本シリーズVol1が扱ったネットワーク可観測性は、接続基盤を「構築する」AWSネットワーク本番運用三部作（Transit Gateway・PrivateLink・VPC Lattice・IPAM・Cloud WAN）の上に重ねる可視化・検証レイヤーです。下記の関連記事と組み合わせることで、「構築」から「可観測性」まで一貫したネットワーク運用体制を実現できます。

関連：AWS Network本番運用 Vol1（Transit Gateway・接続構築編）を読む

関連：AWS Network本番運用 Vol2（接続拡張編）を読む

関連：AWSマルチアカウントガバナンス Vol2（Security Lake・委任管理・コスト）を読む