ANS-3.2ネットワークトラフィックをモニタリングおよび分析して、接続パターンのトラブルシューティングと最適化を行う。

ヒントボタン

pkt-srcawsservice と pkt-dstawsservice は VPC フローログの拡張フィールドでバージョン5を選択した時だけ利用できますが、デフォルト書式には含まれないため LogFormat で明示する必要があります。MaxAggregationInterval を 60 秒、traffic-type を ALL に設定して CloudWatch Logs に配信すれば、NAT Gateway から外向きだけでなく想定外の内向きフローも拾え、過去のバージョン2ログを保持したまま追加コストを最小化できます。

Transit Gateway Flow Logs で同じ情報を得る手もありますが、NAT Gateway を Transit Gateway 配下に移設すると Transit Gateway の使用料金が加算され、ルーティング再設計やセキュリティテストも必要です。さらに VPC トラフィックミラーリングで ENI を複製して外部アプライアンスで解析する方法はフルパケット保存用ストレージや解析基盤の運用が発生し、CloudWatch Logs だけで完結する現在の監視フローと比べコスト・工数が大幅に増える点を意識しましょう。

求められるのは CloudWatch Logs で簡単にクエリできる形で NAT Gateway 経由トラフィックの宛先 AWS サービスを可視化することです。ネットワーク構成を変えず、料金が増える要素を最小に抑えつつ目的のフィールドを得るには、VPC フローログをバージョン5に切り替え、カスタム LogFormat を指定するという総合判断が最もシンプルです。

ヒントボタン

ALB のアクセスログは設定で直接書き込めるのが Amazon S3 だけです。CloudWatch Logs や Kinesis に流す場合は転送用の仕組みを自前で用意しなければならず、5 万 req/秒級ではシャード数や転送コストが急増します。5 分以内に Athena で検索したいなら、取り込み部分が追加運用なしで水平スケールし、PUT 直後にデータが利用できる仕組みかどうかをまず見極めてみてください。

10 TB/日の生ログを Athena で効率良く検索するには、Parquet などの列指向フォーマットと圧縮が鍵になります。S3 イベント通知で AWS Lambda を呼び出して自動変換すれば遅延も数分以内に収まり、クエリのスキャン量を大幅に削減できます。さらに AWS Glue のパーティション投影を利用すると、date=YYYY/MM/dd/HH のように増え続けるプレフィックスを手動登録する必要がなくなり、将来ログ量が倍増しても運用負荷はほぼ一定で保てます。

90 日後にストレージコストを段階的に減らすには S3 Lifecycle で Standard から Glacier クラスへ自動移行する方法が最もシンプルです。CloudWatch Logs や Redshift は保存費やクラスター維持費が固定的に掛かりやすく、長期保管のコスト最適化には不向きです。取り込みから変換、分析、保管までを S3 を中心としたイベント駆動で自動化できる構成が、即時性・コスト最適化・運用最小化という三要件を俯瞰して最もバランス良いかを総合判断しましょう。

ヒントボタン

Direct Connect のプライベート VIF では CloudWatch に BitsIn／BitsOut メトリクスが 1 分粒度で登場するため、この統計期間を 60 秒、閾値をリンク容量の 80％にし連続 5 点を条件に Alarm を作成して SNS に飛ばせば、どの回線で輻輳が続いたかを最小構成で即時に把握でき、SampleCount や Flow Logs を解析する複雑な仕組みを用意するより運用が楽になります。

二本の 1 Gbps 専有ポートを既存のまま束ねて約 2 Gbps へ引き上げたい場合、AWS Direct Connect の Link Aggregation Group を作成し両ポートを同じ LAG に変換すれば、物理ケーブルを増やさずアクティブ–アクティブで帯域が合算され、BGP セッションも一つにまとまり設定や監視も一本化できるため、18 か月後の増速計画を追加作業なしで満たせます。ECMP だけでは物理上限は伸びない点も思い出してください。

監視は CloudWatch の 1 分メトリクスで簡潔に、拡張は Direct Connect LAG で物理帯域を倍に、という組み合わせが遅延検知と将来のトラフィック増加という二つのビジネス要件を同時に解決し、Athena や PrivateLink の追加構築、MTU 調整などの余計な運用や複数プレーンの管理を増やさずに済むという総合的な観点から最も適切なアプローチと言えます。

ヒントボタン

dx/BGPPeerDown が頻発する一方で ConnectionState は Available、dx/TxBytes・dx/RxBytes も平穏という状況は、Direct Connect ポートのごく短い瞬断が平均値に埋もれている可能性を示唆します。CloudWatch のデバイスレベル Telemetry を有効化し、dx/LightLevelTx と dx/LightLevelRx を秒単位で収集すれば、光パワー低下や光コネクタのゆらぎと BGP セッションフラップとの時系列相関を直接確認でき、設定変更なしに物理層の不安定さを切り分けられます。

オンプレミス側 ASN 65010 と AWS 側 ASN 7224 の BGP セッションで KeepAlive や Hold Timer を延ばす方法は、発生回数の数字を抑えても根本原因の品質劣化を隠してしまいがちです。API タイムアウトのように上位レイヤへ波及している場合は、まず CloudWatch Telemetry で CRC エラーや光レベルを取得し、BGP セッション断と付随イベントを精査することで、ルータ設定を変更せずとも真因を特定しやすくなり、手戻りと影響範囲を最小化できます。

Transit Gateway Reachability Analyzer や VPC フローログは VPC 内のルーティングやセキュリティポリシーの可視化に優れますが、今回のような L1〜L2 寄りの BGP ピアダウンには Direct Connect ポート統計の方が適合します。AWS ネットワーク層を俯瞰し、物理→BGP→ルーティング→アプリケーションの順でボトムアップに検証するという総合判断の視点でアクションを選ぶのが効率的です。

ヒントボタン

CloudWatch の bgpPeerDown が継続し VPC Flow Logs には AWS からオンプレミスへ向かう TCP/179 の SYN しか載らないという状況は、Direct Connect の物理層や Private VIF が生きている一方で戻りの SYN-ACK が遮断されている証拠です。境界ルータの access-list が三方向ハンドシェイクの最初のパケットだけを通して後続を落としていないか、ピア IP のペアで双方向に許可されているかを改めて点検してみてください。

BGP はコントロールプレーンで TCP/179 の完全な三方向ハンドシェイクが成立しない限り Open メッセージを送りません。Autostate の変更や Direct Connect Gateway の作り直しのような上位レイヤの設定をいじっても根本は解決しないため、オンプレミス側ルータのインバウンド・アウトバウンド ACL に AWS 側ピアアドレスとの TCP/179 を状態を問わず許可して保存するのが最小かつ確実な復旧策となります。

本問は CloudWatch、VPC Flow Logs、BGP プロトコル、Direct Connect という複数の要素を突き合わせて「どこでパケットが止まっているか」を論理的に切り分ける力を試しています。ネットワーク ACL の責任範囲、経路制御の影響範囲、変更工数とリスクを総合的に比較すると、境界ルータ側のアクセス制御を適切に緩和する判断が最も合理的だと導けるでしょう。

ヒントボタン

Direct Connect ゲートウェイから Transit Gateway を通って VPC へ流れるルートを素早く何度も調べるには、AWS Network Manager の Route Analyzer が便利です。GUI で起点を DXGW、宛先を 10.0.1.0/24 と指定すると、伝播ルートが図で示され、欠落箇所は Blocked として表示されるため、ブラックホール有無を数クリックで反復確認できます。

タイムアウト直前後 30 秒のドロップ原因を探す際は、VPC フローログを TrafficType=ALL かつ 1 秒集計で有効にし、CloudWatch Logs へ出力する方法が軽量です。ACCEPT・REJECT・BLACKHOLE のステータスと ENI、ルートテーブル ID が記録されるので、172.16.0.0/16 から EC2 への TCP443 通信だけをフィルタし、VPC 内でどの段階で拒否されたかを素早く把握できます。

トラフィックミラーリングや Network Firewall、CloudTrail は情報量や負荷が過大または目的外となりやすいため、本番影響とコストを抑えつつ GUI 操作で経路診断し、ログメタデータでドロップ分析できる Route Analyzer と VPC フローログの組み合わせが、複数要件を俯瞰した総合判断として最も合理的です。

ヒントボタン

CloudWatch の TunnelState が 30 秒ごとに Up/Down を繰り返し、VPN ログに NO_PROPOSAL_CHOSEN が出ている場合は AWS Site-to-Site VPN の IKE フェーズ 1／フェーズ 2 の proposal がオンプレミスと食い違っているのが典型的原因なので、AES256-SHA1・DH group14・14400 秒を AWS CLI の modify-vpn-tunnel-options で既存トンネルに適用して再ネゴシエーションを促すと速やかに安定します。
RTO 5 分と同時接続 5000 の SLA を守るには VPN 接続を作り直してルート伝播や Transit Gateway への再関連付けを行うよりも、既存 Virtual Private Gateway 配下トンネルの暗号パラメータだけを CloudWatch 監視を切らずに更新するほうがプロビジョニング待ちを回避でき、ダウンタイムも数十秒で済むため目標に適合しやすいです。
Reachability Analyzer や VPC フローログでの MTU 調査はデータプレーン診断には有効ですが、TunnelState が周期的に Down となる制御プレーン障害ではパラメータ不一致の解消が最優先となるため、複数要件を俯瞰した総合判断としては変更範囲の小さい設定合わせが最も合理的です。

ヒントボタン

Transit Gateway Network Manager の Route Analyzer は、TGW ルートテーブル・VPN/BGP・DirectConnect・VPC アタッチメント全体の到達性をエージェントレスで自動追跡し、Blackhole やルート伝播漏れを視覚化できます。解析を保存すると共有 URL が生成され、NetworkManagerReadOnlyAccess を割り当てた IAM グループに閲覧専用で渡すだけなので、10 名への情報共有も最小工数で実現できます。

VPC Reachability Analyzer は ENI 間の経路検証専用で Transit Gateway や Direct Connect 区間は対象外、VPC フローログには TGW 内部ドロップを示す Blackhole=1 が記録されず、トラフィックミラーリングは大量の ENI 設定と分析サーバ運用が必要です。これらの方法では「追加エージェント不要」「低運用負荷」の条件を満たしにくい点を整理しましょう。

15 の VPC と 3 本の Direct Connect を束ねる単一 TGW の経路健全性を俯瞰し、結果を権限分離した 10 名に安全かつ簡単に共有するには、TGW ネイティブの可視化ツールと保存・共有機構、そして IAM 読み取り専用ポリシーを組み合わせたアプローチがコスト・運用両面で最も合理的という総合判断になります。

ヒントボタン

Transit Gateway にはアプライアンスモードという“終点固定”機能があります。このモードを Inspection VPC のアタッチメントで有効にし、Prod VPC と Direct Connect アタッチメントをそれぞれ専用のルートテーブルに関連付け、10.0.0.0/16 と 172.16.0.0/16 をアプライアンス宛ての静的ルートで明示すると、行きも戻りも必ずファイアウォールを通過し対称ルーティングとステートフル検査を同時に満たせます。さらに必要な設定は三つのルートテーブルと二本の静的経路だけなので、CIDR を変えられない制約下でも運用負荷は最小限に抑えられます。

Transit Gateway の経路選択は最長一致が優先されるため、プロパゲーション任せでは Direct Connect から広報される 10.0.0.0/16 や 172.16.0.0/16 が 0.0.0.0/0 より優先され、復路がファイアウォールを素通りする恐れがあります。各アタッチメントが参照するルートテーブルで対象 CIDR を Inspection VPC 宛ての静的ルートにし、アプライアンスモードで TGW 内の次ホップ変更を抑止すれば、この最長一致の罠を回避できます。静的経路は少数で済むため自動集約よりもかえって保守が容易になり、非対称ルーティングによるセッション切断を根本から排除できます。

NAT Gateway で経路をたらい回しにしたり、ECMP マルチパスで負荷分散を試みても、最長一致や多経路転送の影響で復路が分岐しステートフル検査を失うリスクが残ります。CIDR 変更不可、Direct Connect 継続、運用負荷最小という複数要件を俯瞰すると、Transit Gateway のアプライアンスモードとルートテーブル分離で経路をピン留めする方式が最もシンプルかつ確実であり、要件を包括的に満たす総合解として導き出せます。

ヒントボタン

CloudWatch が示す Retransmit 増加は Path MTU Discovery 失敗の典型的サインです。オンプレ側 FW が ICMP type3 code4 を落とすため、EC2 から Site-to-Site VPN へ向かうパケットは 9001 バイトのまま送られ、VGW 手前でドロップされます。VPC 内部はそのままジャンボフレームを保ちつつ、オンプレ CIDR あて通信だけを 1500 バイトに収めると再送は収まりやすくなります。Linux では ip route で宛先別に mtu 値を指定できます。

解析クラスターは EC2 間で大容量をやり取りするため ENI MTU 9001 を残す意義が高いです。全インターフェースを 1500 に統一するとスループットが低下し、ビジネス要件に影響します。一方、VGW や Customer Gateway 側を調整しても FW が ICMP を遮断している限り PMTU Discovery は復帰せず、MSS クランプや DF ビット操作は UDP や ICMP の断片化問題が残る恐れがあります。OS レベルで宛先依存の mtu 1500 ルートを設定すれば VPC 設計や AWS 課金に影響を与えず夜間バックアップのみを安全に流せます。

求められるのは「VPC 内性能維持」「VPN 経路のドロップ解消」「追加コストなし」の同時達成です。AWS 側リソースをいじらずに済み、運用範囲が EC2 の OS 設定だけで完結する宛先 CIDR 向け route mtu 1500 は、複数要件を俯瞰したとき最もシンプルかつ実務的な落とし所といえます。

ヒントボタン

まず、NAT Gateway が 350 秒のアイドル状態でコネクションを破棄すると、その事象は VPC ネットワークの CloudWatch メトリクス IdleTimeoutCount に 1 ずつカウントされます。これに Amazon CloudWatch アラームを設定し Amazon SNS へプッシュすれば、決済 API との HTTPS セッションが切れた瞬間を開発チームが即座に把握でき、ログとの相関分析や再試行制御の改善にもすぐ着手できます。

一方、350 秒より長い無通信を避けるにはクライアント側が定期的にパケットを送ることが重要です。Amazon Linux 2 では sysctl の net.ipv4.tcp_keepalive_time を 240 秒前後に短縮し、さらに net.ipv4.tcp_keepalive_intvl や net.ipv4.tcp_keepalive_probes を調整することで、NAT Gateway のタイムアウトより前に軽量な TCP keep-alive を発生させ、TLS ハンドシェイクの再実行や遅延コストを防げます。

スケーラブルな NAT Gateway、観測を担う CloudWatch と SNS、そして EC2 の Linux カーネルパラメータという役割分担を整理すると、ミドルボックスのタイムアウトを監視しながらアプリ側で能動的にキープアライブを送る構成が、通知要件とコネクション維持要件を最もシンプルかつ堅牢に同時達成できる総合的な解決策となります。

ヒントボタン

5 分以内に送信元プライベート IP と宛先ポートを可視化したい場合、NAT Gateway の ENI に対して VPC フローログを有効化し CloudWatch Logs へ直接取り込むことで 1 分粒度のデータが数分以内に到着し、Logs Insights のクエリと Contributor Insights のトップ N 集計をダッシュボードに貼るだけでリアルタイム監視ができ、追加の Kinesis や自前解析基盤を用意する必要がありません。

13 か月間の長期保存と随時の SQL 解析を両立するには、CloudWatch Logs からの自動エクスポートで毎日 S3 にログを吐き出し、S3 ライフサイクルルールで 90 日後に Glacier Deep Archive へ階層移行するとストレージコストを極小化でき、Athena は必要なときだけ GZIP テキストに直接クエリを投げられるため Parquet 変換や常時 Firehose 運用が不要です。

監視遅延・保管コスト・運用負荷という三要素を俯瞰すると、VPC フローログ＋CloudWatch Logs による即時可視化と S3／Glacier Deep Archive への段階的保存を組み合わせた構成が、8 TB/日の通信量にもマネージドでスケールしつつ Athena でのオンデマンド分析を可能にする最もバランスの良い選択肢と判断できます。

ヒントボタン

Route 53 パブリックホストゾーンにはデフォルトで AWS/Route53 名前空間の DNSQueries メトリクスがあり、HostedZoneId ディメンションを付けて CloudWatch に送信されています。統計期間を 1 分に設定すればゾーン単位の QPM をリアルタイムに取得でき、内部で 15 秒間隔のサンプルを集約するため遅延もごく小さいです。しきい値さえ決めれば SNS と統合して PagerDuty 通知を行うだけで追加リソースは不要です。

Route 53 Resolver クエリログ、ALB アクセスログ、CloudFront 標準ログなどでも集計は可能ですが、前二者は VPC 内の DNS や HTTP レイヤの指標でありパブリックゾーンの外向きクエリ数とは性質が異なります。これらを CloudWatch Logs、Athena、Lambda、メトリクスフィルターで加工すると構成が複雑化し、リアルタイム性や運用コストも上がります。要件が「最小変更」であればネイティブメトリクスの活用が最短距離といえます。

今回の目的は「1 分粒度で急増を検知し、ゾーン単位で 30k QPM を超えたら PagerDuty へ通知」を既存の example.com／ALB 配置を触らずに実現することです。Route 53 が標準で出す DNSQueries をそのまま 30,000 のしきい値で CloudWatch Alarm に掛け、SNS 経由で PagerDuty に連携すれば、追加ログ収集やリソース新設なしでリアルタイム性・運用容易性・コストのバランスを同時に満たす総合的に最適な手段となります。

ヒントボタン

Site-to-Site VPN のトンネルダウンや BGP Keep-alive の途絶は Transit Gateway が標準で CloudWatch に TunnelState と BGPStatus メトリクスを 1 分粒度で送信しているため、しきい値を Down や 30 秒以内に設定した CloudWatch Alarm を作り Amazon SNS を経由して AWS Chatbot で Slack へ通知すればポーリングやコード無しでリアルタイム通知とコスト最小化を両立できます。
Transit Gateway を AWS Network Manager の Global Network に関連付けると Route Analyzer の履歴ビューで BGP によるプレフィックス広告やルート伝搬の変化を 24 時間さかのぼって時系列確認できるため、CloudWatch ダッシュボードにこの履歴ウィジェットと VPN トンネルメトリクスを並べれば障害発生後の分析を一画面で完結できます。
要件は 30 秒以内の自動通知と 24 時間分のメトリクス・ルート履歴を統合確認できるダッシュボードを運用とコストを最小に保ちながら実現することであり、CloudWatch と SNS／AWS Chatbot、Network Manager Route Analyzer、CloudWatch ダッシュボードを組み合わせるフルマネージド構成が複数要件を俯瞰し最もバランスの取れた判断となります。

ヒントボタン

スタティックルートで Virtual Private Gateway と Customer Gateway を結ぶ場合、フェイルオーバ検知は Dead Peer Detection 30 秒に限定されますが、BGP に移行すると keepalive／holdtime を秒単位で細かく設定でき、たとえば keepalive 3 秒・holdtime 9 秒なら Route Table の経路撤収が 10 秒以内に完了します。さらに BGP ECMP を用いて二本の Site-to-Site VPN を同時にアクティブ化すれば、トラフィックを平滑に分散しつつ片系断でもセッションを維持でき、決済システムのダウンタイムを大幅に抑えられます。

仮想プライベートゲートウェイ側の Dead Peer Detection タイマーは AWS API や CLI で変更できない固定値であるため、フェイルオーバ時間を短縮したいときは DPD に依存せずルーティングプロトコルそのものを活用するのが現実的です。IKE Phase1/2 ライフタイムを短くしても障害検知には寄与せず、逆に頻繁な再ネゴシエーションが運用負荷を高める可能性がある点も Site-to-Site VPN 設計の注意点として押さえておきましょう。

追加アプライアンスや Direct Connect を増設せず、コストを据え置いたまま RTO 10 秒を満たすには、既存の二本の IPsec トンネルを活かしながら BGP 動的ルーティングで検知時間を短縮し、ECMP でアクティブ-アクティブ運用を行う構成が、要件・制約・運用性を総合的に満たす最適解となります。

ヒントボタン

1つ目のヒント
Security Group はステートフルなためアウトバウンドを許可するとリターンパケットは自動で通過しますが、Network ACL はステートレスなので送信方向と受信方向を個別に評価します。VPC Flow Logs に action=REJECT が残る場合、ルートテーブルや VPN ではなく NACL がポート単位で遮断している可能性が高いことを思い出してください。今回 EC2 から syslog を UDP 514 で送信している点を踏まえ、NACL のアウトバウンドとインバウンドの両方にその通信が通る道があるか紙に書き出して整理すると原因が見えやすくなります。

2つ目のヒント
UDP でもクライアント側は 1024 番以上のエフェメラルポートを source として使用します。したがって EC2 から出るパケットは「source 1024-65535／destination 514」、戻りパケットはその逆という形になります。Network ACL ではアウトバウンド評価時に destination ポート、インバウンド評価時に destination ポートをチェックするため、現状ルールが「source ポートだけ開放」といった誤解で設定されていないか確認しましょう。インバウンド側は既に 1024-65535 が許可されているなら戻り通信は通過できる点もヒントになります。

3つ目のヒント
AWS Well-Architected Framework でも最小権限の原則が強調されています。許可したいフローは Site-to-Site VPN 越しに 10.0.10.0/24 宛の UDP 514 だけですから、Network ACL ではその CIDR とポートを絞った ALLOW を明示し、全宛先や広いポート範囲を許可するルールは整理するほうが安全です。送信元ポートを無駄に開けるのではなく宛先ポート側を狭めるという視点で見直すと、通信復旧とセキュリティ強化を両立できます。複数要件（通信成功・最小権限・ログ健全性）を俯瞰して最もバランスのよい修正を選びましょう。

ヒントボタン

到達性チェックを変更から15秒以内に走らせるには、変更通知をほぼリアルタイムで受け取れる仕組みが不可欠です。SecurityGroupやRouteTableの更新はCloudTrailに管理イベントとして数秒で記録され、EventBridgeルールで即時にLambdaを起動できるため、5分間隔のスケジュールやConfig評価より速く検知できます。このLambdaからAWS Reachability AnalyzerのStartNetworkInsightsAnalysis APIを呼び出せばテスト自体もAPI完結で済むためプロービング用EC2などを起動する必要がなく、時間面でもコスト面でも条件に合いやすくなります。

月額10USD未満というコスト制限を守るには、定常的にインスタンスやログクエリを回し続ける方式は避けたいところです。Athenaはスキャン量、Network Managerはプローブ回数、EC2は起動時間で料金がかさみがちですが、AWS Reachability Analyzerは1回0.10USD程度で済み、変更時に限定して3回実行する程度なら月額が数ドルで収まります。CloudTrail・EventBridge・Lambdaは定常料金ゼロ、SNSもメッセージ課金のみで条件を満たしやすい点に注目してください。

連続3回失敗したら直前のネットワーク設定を自動ロールバックするという条件は、Systems Manager Automationのrunbookで「aws:executeAwsApi」を使いSecurityGroupやRouteTableを直前のバージョンに戻すと簡潔に実装できます。失敗回数はLambda内でCloudWatch LogsやDynamoDBに保持すればカウントでき、SNS Publish APIで即座に通知を出せます。イベント検知からReachability Analyzer実行、ロールバック、通知までをサーバーレスで鎖のように繋げる構成が、検知速度・自動復旧・低コストという三つの要件をまとめて満たすかを俯瞰して判断してください。

ヒントボタン

VPC の Route Table や Security Group の変更は CloudTrail の管理プレーンイベントとして即座に発行されます。Trail を S3 や CloudWatch Logs に流すと数分の遅延が生じますが、EventBridge で直接受け取ればほぼリアルタイムで処理できるため、Transit Gateway 配下の VPN で経路が変わるたびに即時で疎通確認を走らせたい場合は「CloudTrail → EventBridge → 実行基盤」という流れが最も遅延の少ない構成になります。

到達性テストには VPC Reachability Analyzer の StartNetworkInsightsAnalysis API が最適です。Lambda から同期実行すると通常は数秒でステータスが success か failed で返るため、Step Functions の Wait やポーリングは不要です。Lambda で判定し Amazon SNS へ Publish、さらに Slack とは Chatbot や Webhook で連携すれば、変更検知から通知まで数十秒以内に完結し、課金は Lambda 実行と API 呼び出し分だけに抑えられます。

AWS Config の定期評価間隔、CloudWatch Logs Metric Filter の配送遅延、EC2 バスティオン維持コスト、Step Functions の状態遷移課金などを比較すると、月 300 回の高頻度トリガーで 5 分以内通知という要件を満たすうえで最小の運用負荷とコストを実現するのは EventBridge と Lambda を組み合わせ、Reachability Analyzer と SNS で検証・通知を行うシンプルなパターンである、という総合的な判断が導けるでしょう。

ヒントボタン

平均25Gbps・突発40Gbpsという高スループット環境では、本番パケットを処理する vCPU に余分な割り込みを起こさないことが鍵です。Nitro ハイパーバイザ上で ENI 単位に ASIC オフロードされる VPC Traffic Mirroring を利用すると、Network Load Balancer 配下の c5n インスタンスのカーネルや UDP API への影響を最小化でき、要件①「スループット影響ゼロ」を安全に満たせます。

解析ノードの c5n.xlarge が取り込めるのは 5Gbps までなので、200 台から合計を抑えるための帯域工夫が必須です。VPC Traffic Mirroring では Filter で UDP 全ポートを通しつつ PacketLength を 60 バイト程度に限定でき、IP／UDP ヘッダーのみを複製してペイロードを除外できます。これにより各 API はおよそ 500Mbps 相当のヘッダー量に圧縮され、要件②の制約内に収まります。

運用面では、ミラーターゲットとミラーフィルタを AWS CLI や CloudFormation で一度作成しておけば Auto Scaling で増減する ENI にも自動適用され、追加作業がほぼ発生しません。ルートやターゲットグループの再編成、pcap ローテーション、Gateway Load Balancer への経路変更といった手間を省きながら、NLB・VPC Traffic Mirroring・Elastic Network Interface のネイティブ機能だけで三つの要件を俯瞰した総合的に最適な構成と判断できます。

ヒントボタン

パケットレベルで東西トラフィックを捉えつつEC2 の CPU と帯域への影響を最小化するなら、ハイパーバイザーでコピー処理を行う VPC Traffic Mirroring が王道です。ミラー元に各インスタンスの ENI を指定すると 1 セッション 5 Gbps まで送信でき、要件の 1 Gbps を十分にカバーしながら VXLAN (UDP 4789) のカプセル化で IDS にそのまま届けられます。さらに集約先を後段でスケールアウト可能なリソースにしておけば、100 台規模でも負荷集中を避けられます。

クロスアカウントでミラーパケットを受け取る場合、AWS Resource Access Manager を使った Network Load Balancer 共有が公式にサポートされています。SecOps 側で作った NLB を RAM で Prod へ公開し、その ARN をミラーセッションに設定すれば追加の VPC ピアリングや Transit Gateway は不要です。NLB のターゲットグループに複数 IDS ノードを登録すればヘルスチェックで自動振り分けされ、高可用性と水平拡張という要件を同時に満たせます。

CPU 影響を抑える Traffic Mirroring、1 Gbps を余裕で超える帯域上限、ターゲットグループで冗長化できる Network Load Balancer、AWS RAM による正式なクロスアカウント共有という複数の観点を総覧すると、本番 VPC の ENI からミラーを開始して SecOps 側の NLB に VXLAN で転送し IDS クラスタへ流す構成が、全要件を最もバランス良く達成できると総合判断できます。

ヒントボタン

VPC トラフィックミラーリングは送信元 ENI でパケットを VXLAN カプセル化し UDP/4789 で流れるため、受信側も UDP を透過できる必要がありますが、Network Load Balancer はリスナーとターゲットグループを後から UDP/4789 に切り替えるだけで既存の DNS 名や AZ 配置を維持しつつ Suricata インスタンスへ転送でき、CloudWatch メトリクスやヘルスチェック設定もそのまま残せるので可用性運用に影響しません。
Gateway Load Balancer を導入すると VPC エンドポイントや GWLBe、ルートテーブル変更、GENEVE/6081 など追加構成が増えますが、現在の Network Load Balancer はマルチ AZ と L4 UDP 負荷分散を既に備え 20 Gbps でも十分処理できるため、プロトコルとポートを UDP/4789 に統一するだけの最小変更で Suricata にミラーパケットを届けられ、工数とコストを抑えつつスケール特性を維持できます。
Application Load Balancer や Classic Load Balancer は HTTP や TCP 向けで UDP を通せないことを踏まえると、TCP/80 でヘルスチェックを続けながら実データは UDP/4789 でパススルーできる Network Load Balancer が要件を満たしますので、可用性・スケーラビリティ・変更規模を俯瞰した総合判断として最もシンプルで拡張性の高い策と言えます。

ヒントボタン

1. VPC 内通信を 1 分粒度で大量収集するときは VPC フローログが基本機能です。最新機能では ENI 単位で S3 へ直接 JSON 出力ができ、CloudWatch Logs を経由しないため 5 TB/時クラスでも取り込み課金とスループット制限を抑えられます。複数 AZ、約1,000 台の EC2 からの並列 PUT は S3 が自然にスケールし、さらにキーを時間階層で分ければ後段分析も効率化できます。

2. 400 日保持と改ざん防止には S3 Object Lock を Compliance モードで設定し、ライフサイクルポリシーと Intelligent-Tiering を併用してアクセス頻度に応じた自動階層化を行うとコストと運用の両方が軽くなります。CloudWatch Logs に保持設定や Kinesis Data Firehose 転送を組み合わせる方式と比較すると、設定箇所の少なさと取り込み単価の差が際立ちます。

3. Athena で過去 1 時間だけを 30 秒以内に照会するには Glue データカタログのパーティション投影を year/month/day/hour 形式にし、S3 オブジェクトキーを同じ階層にそろえてスキャン量を最小化します。Spark や EFS を介在させる方法より遅延も管理項目も減るため、フロー収集・長期保存・高速検索という三要件を総合的に満たす構成が自然に浮かび上がるはずです。

ヒントボタン

内部向け Network Load Balancer は配置されたプライベートサブネットの ENI から応答を返し、その経路選択はサブネットの VPC ルートテーブルに依存します。Dual-Stack 環境でも IPv6 の戻りは同一ルールで処理されるため、2001:db8:55::/48 行きのエントリが無ければ応答パケットは破棄され、CloudWatch VPC Flow Logs に ActiveFlow が記録されず Reachability Analyzer に戻り経路不明が示される状況になります。

Virtual Private Gateway とオンプレミス側ルーターは Direct Connect 上で IPv6 BGP 広告が可能ですので、各サブネットに「宛先 2001:db8:55::/48、ターゲット VGW」の静的ルートを追加し、そのプレフィックスを DX 側でも受信・広告すれば往復の経路が揃います。設定変更はルートテーブルと BGP のみで済み、NAT64 やパブリック化など新規基盤を用意する必要がなく、運用負荷やセキュリティリスクを抑えられます。

要件は「既存の Dual-Stack 内部 NLB を維持」「TLS 3 万接続と 1 Gbps を現在の Direct Connect 帯域で処理」「閉域 IPv6 通信を継続」の三つです。サブネットルートと BGP を調整して戻り道を確保する方法がコスト、可用性、セキュリティいずれの観点でも最もバランスが取れており、複数要件を俯瞰した総合判断として最適といえるでしょう。

ヒントボタン

インターネット接続を禁じつつNAT Gateway新設も避けたい場合、EC2がCloudWatch Logsへ高速に書き込む経路として最もコスト効率が高いのはInterface型のVPCエンドポイントです。プライベートサブネットのルートに紐付ければトラフィックはAWS内で完結し、1秒1MBのログも5秒以内に転送可能、Internet Gatewayが不要なため外部リスクや帯域競合も抑えられます。

EC2に長期アクセスキーを残さない方針を守るには、インスタンスプロフィールでIAMロールを付与しSTSの一時クレデンシャルをCloudWatch Agentが自動取得する形が安全です。VPCエンドポイントポリシーは経路制御のみで認証は行わないため、logs:CreateLogGroup / logs:CreateLogStream / logs:PutLogEventsなど必要最小限のIAMポリシーで権限を絞り、最小権限と運用負荷の低減を同時に実現しましょう。

本問は「NATレスのプライベート送信」「アクセスキー残存禁止」「IAM最小権限」「高頻度ログ転送」「VPCフローログ分析」を統合的に設計できるかがポイントです。Interface型VPCエンドポイントでCloudWatch Logsへ接続し、EC2に限定的なCloudWatch Logs APIのみ許可するIAMロールを付与、CloudWatch Agentで送信、さらにVPC Flow Logsを有効化する構成がコスト・セキュリティ・性能の全要件を最もバランス良く満たします。