ANS-1.4AWS とハイブリッドネットワーク全体でログ記録とモニタリングの要件を定義する。

ヒントボタン

CloudWatch Internet Monitor がレイテンシや損失を検知すると自動で EventBridge イベントを発行できます。ルールで「遅延 300 ms かつ 5 分継続」を JSON パスでフィルタすれば該当イベントだけを捕捉でき、メトリクスアラームや Lambda を挟まずとも条件判定をマネージドに任せられる点がポイントです。たとえば detail.currentStatus や eventType など複数フィールドを AND 条件で組み合わせれば無駄な通知を防げ、再試行ポリシーも EventBridge 標準機能で設定できます。

外部 ITSM SaaS が要求する “X-API-KEY: xxxx” のような独自ヘッダーを付与する場合、SNS の HTTPS サブスクリプションは任意ヘッダー送信をサポートせず、Lambda を書けば実現可能でもコード管理やランタイム更新という運用負荷が残ります。EventBridge の API Destination と Connection ならコンソール設定だけでヘッダーを登録し、Secrets Manager に暗号化保管できるため追加開発ゼロで要件を満たせます。リトライ間隔やタイムアウトも GUI で細かく指定できるので可観測性も高いです。

設問は「追加開発やサーバー運用負荷を最小化」「HTTP ヘッダーによる API キー認証」「重複除外は先方が実施」という三条件が鍵です。Internet Monitor から EventBridge で条件フィルタし、そのままマネージド送信先に流す経路はサーバーレスでヘッダー設定が GUI で完結し、SNS の制約や Lambda 運用を回避して複数要件を同時に充足する最も効率的な解となります。

ヒントボタン

Application Load Balancer はログを最大 5 分間隔で Amazon S3 に直接配信でき、バケットポリシーでクロスアカウント書き込みを許可しつつ SSE-KMS をコンソール操作だけで有効化できるため、Kinesis Data Firehose や S3 Batch Operations といった中継サービスを介さずに暗号化済みデータを低コストで集約でき、さらに Multi-AZ から発生する 1 分あたり 10 万件規模のリクエストでも S3 の水平スケールが受け皿となるので追加運用は不要です。
Amazon Athena ではパーティション射影を使うと新しいパスをメタデータとして動的に解釈でき、Glue Crawler や MSCK REPAIR TABLE を回さなくても s3://bucket/AWSLogs/…/yyyy/mm/dd/ のような規則性ある階層を自動認識できるため、ログが配置されてからカタログ更新を待たずに 5 分以内で検索でき、日付キーを宣言するだけでスキャン量削減によるコスト最適化も実現します。
要求条件を並べてみると、暗号化は SSE-KMS、保管はクロスアカウントの Amazon S3、解析は Athena の 5 分以内応答、パーティション自動化は Partition Projection、低コスト運用は中継サービス削減とファイル即時可視化というポイントが同時に現れるため、これらをすべて満たすシンプルなパスを俯瞰して探すと、ロードバランサが直接バケットに書き込み Glue Data Catalog に静的定義を置くだけの案が最も整合します。

ヒントボタン

平均250MB/分、ピーク500MB/分という東西トラフィックのフローログを60秒以内に可視化するには、Network Firewall から直接ストリーミングできる経路が望ましいです。Kinesis Data Firehose は送信先に Amazon OpenSearch Service をネイティブに指定でき、1MBまたは60秒のバッファ条件を満たすたびに _bulk で自動書き込みを行います。シャードやワーカを手動管理せずともスケールアウトし、失敗時にはバックオフ付きリトライも標準で行われるため運用工数を大幅に抑えられます。

CloudWatch Logs Insights はクエリを最短1分ごとに実行できますが、EventBridge で起動した Lambda が _bulk API を呼ぶ実装ではバッファ調整や IAM、リトライの実装など細かな運用タスクが発生しがちです。S3 と AWS Glue のパイプラインもパフォーマンスは十分でも S3 の整合性ラグと Glue コンテナ起動時間があるため秒速の監査可視化には不向きです。Firehose は取り込んだログを流すだけで形式変換のための組み込み Lambda 変換も提供しており、ほぼ設定のみでリアルタイム性を確保できます。

要件は①60秒以内の取り込み遅延、②最大8.3MB/秒相当のピークトラフィック処理、③運用負荷最小化、の三つです。これらを同時に満たすには、Network Firewall がサポートする Kinesis Data Firehose 宛先機能でデータを Amazon OpenSearch Service へ直接ストリーム配信し、Firehose の自動スケールとマネージド運用に委ねる構成が総合的に最も合理的であると判断できます。

ヒントボタン

Site-to-Site VPN や Direct Connect、Transit Gateway をまとめて可視化したいときは Network Manager の Global Network が便利です。BGP で学習した経路の追加・削除・ブラックホールを数十秒で Route State Change として検知し、そのまま EventBridge に流せます。エージェント不要でコントロールプレーン完結、CloudWatch にメトリクスを送ればダッシュボードも即時更新できます。

VPC フローログはデータプレーンの実通信を後追いで記録するため、そもそもパケットが届かない経路切れを 60 秒以内に捕捉するのは難しく、Athena の分単位クエリはコストも増えます。AWS Config も評価間隔が数分単位でブラックホール判定ロジックを別途書く必要があります。制御面の状態をリアルタイムでイベントとして受け取れる仕組みと比べると運用は複雑になりがちです。

求められるのはリアルタイム検知・60 秒以内の通知・CloudWatch ダッシュボード自動反映・Direct Connect 追加後の拡張容易・運用負荷最小という複数条件です。Transit Gateway Network Manager が発する Route State Change を EventBridge で拾い SNS と CloudWatch に渡す構成なら、ネイティブ機能だけで全要件をシンプルに満たせるため総合的に最もバランスが取れています。

ヒントボタン

ヒント1
TLS ハンドシェイクの原因調査には ClientHello や ServerHello など L4/L7 ペイロードを含む完全なパケットが欠かせます。VPC フローログや Transit Gateway Network Manager はバイト数や ACCEPT／REJECT といったメタ情報のみで、ペイロードを保存できません。一方 VPC トラフィックミラーリングは Nitro 系 EC2 の ENI から流れるパケットをヘッダ＋データ部ごとコピーし、pcap と同等の深掘り解析を実現します。ミラー対象は ENI や CIDR 単位で絞れるため 10.0.0.0/16 内の必要最小限だけを捕捉して本番負荷を抑えられます。

ヒント2
1 ms 以上の遅延を避けるなら tcpdump などを EC2 内で回して EBS に書き込む方式はディスク I/O が競合しがちでリスクがあります。VPC トラフィックミラーリングは Nitro カードがコピーを別経路で吐き出す仕組みのため、本番パケットはほぼゼロインパクトで流れます。コピー先を Network Load Balancer にすれば 5,000〜20,000 pps のピークも背後の Zeek 解析ノードを水平スケールして受け止められ、可用性と拡張性を同時に確保できます。

ヒント3
60 日保管と ad-hoc 検索をシンプルにこなすなら、Zeek が JSON 化したログを Kinesis Data Firehose で CloudWatch Logs にストリーミングし保持期間をポリシー設定すると運用が楽です。CloudWatch Logs Insights なら TLS バージョンや SNI で即時絞り込み可能です。S3＋Athena も手段ですが、Firehose→CloudWatch は自動ローテーションや課金体系が直感的で日々の保守コストを抑えられます。

複数要件を俯瞰すると、フルペイロード取得・サブミリ遅延・60 日集中保管・低運用コストを同時に満たすのは VPC トラフィックミラーリングと Network Load Balancer、Zeek、Kinesis Data Firehose、CloudWatch Logs Insights を組み合わせた構成が最も整合的と言えるでしょう。

ヒントボタン

まず「90 日以内は Athena で高頻度に検索」という条件を満たすには、Athena が直接参照でき、かつリストア待ちが発生しない S3 Standard などオンラインストレージに当該期間のオブジェクトを置くことが鍵です。Glacier へ 30 日で移すと監査の即時性を損ないます。VPC Flow Logs はネイティブに S3 へ書き込めるため、CloudWatch Logs や Kinesis Data Firehose を追加する必然性があるかも整理してみましょう。さらに 5,000 万行／日でも S3 はオブジェクト課金のためコストが抑えられる点も留意してください。

次に 90 日を超える部分は「年 1 回程度の取得でよい」という前提からライフサイクルで Glacier Flexible Retrieval へ自動移行する設計が有効です。このクラスは取り出しが数分～数時間で済み、リクエスト料金も年 1 回なら軽微で済みます。Deep Archive はさらに安価ですが最大 12 時間の待機が発生するため緊急調査には向きません。ライフサイクルポリシーで 7 年後に自動削除を設定すれば、手動ジョブなしで保持義務とコスト最適化を同時に実現できます。

改ざん防止は SSE-S3 の暗号化だけでは不十分で、WORM を保証する S3 Object Lock Compliance モードが求められます。バケット作成時に有効化し保持期間を 7 年に設定すると、管理者権限でも削除・上書きができない状態が確立されます。VPC Flow Logs を直接そのバケットに保存し、ライフサイクルで 90 日後に Glacier Flexible Retrieval へ移行すれば、オンライン検索・長期保管・改ざん防止・運用負荷の各要件を無理なくバランスできる構成であることが総合判断として浮かび上がります。