5.3接続のトラブルシューティングと最適化

「つながらない」ときは体系的に切り分けます。ルート → セキュリティグループ → NACL の順に確認し、フローログの REJECT で裏取りします。

5.3.1切り分けの順序

• ルートテーブル：宛先へのルートが存在するか（IGW/NAT/TGW/ピアリング/エンドポイント）。
• セキュリティグループ：ステートフル。インバウンドで許可すれば戻り通信は自動許可。
• NACL：ステートレス。インバウンドとアウトバウンドの両方を明示的に許可する必要がある。
• MTU/非対称ルーティング：大きなパケットはジャンボフレーム/MTU に注意、行きと戻りで経路が異なると遮断されることがある。

ANS-C01 の運用問題は MTU・非対称ルーティング・ハイブリッド固有の落とし穴を深く問います。MTU の境界を覚えます——VPC 内は最大 9001、インターネットゲートウェイ経由や VPC ピアリングは 1500、Transit Gateway は 8500、Site-to-Site VPN は最大 1500（IPsec オーバーヘッドで実効はさらに小さい）。経路上で小さい MTU を越えるとき、DF（Don’t Fragment）ビットが立っていると ICMP「Fragmentation Needed（Type 3 Code 4）」でパケットサイズ調整（パス MTU 探索）が行われますが、この ICMP を SG/NACL でブロックすると接続は確立するのに大きな転送だけ固まる典型障害になります。非対称ルーティングは、行きと戻りで別経路（例：行きは TGW、戻りは別の VPN）を通ると、ステートフルなファイアウォールや NAT が戻りパケットを「セッション不明」として落とすため発生します。インスペクション構成では行き戻りを同じアプライアンスに固定（アプライアンスモード）して対処します。Transit Gateway のアプライアンスモードを有効にすると、TGW が同一フローを同じ AZ のインスペクションエンドポイントに固定し、非対称を防ぎます。ハイブリッドでは、オンプレと VPC で DNS の双方向解決（Route 53 Resolver のインバウンド/アウトバウンドエンドポイント）が未設定だと名前解決だけ失敗する、重複 CIDR で TGW のルートが衝突する、といった切り分けも問われます。

5.3.2運用・通知・ガバナンスの in-scope サービス

ネットワークの運用では、イベント連携・通知・統制のサービスも問われます。構成変更や障害イベントを起点に自動対応するなら Amazon EventBridge がイベントをルールでフィルタしてターゲット（Lambda/SNS 等）へ配送し、スケジュール起動もできます。一斉通知（ファンアウト）は Amazon SNS（メール/SMS/HTTP へ pub/sub）、コンポーネント間の疎結合・バッファリングは Amazon SQS のキューで、両者の役割（通知 vs キュー）を区別します。 運用情報では、AWS 側の障害・メンテナンスが自分のリソースに与える影響を AWS Health Dashboard がパーソナライズ通知し、構成のベストプラクティス点検は AWS Trusted Advisor（自動の個別チェック）、6 つの柱での体系レビューは AWS Well-Architected Tool で行います。日常操作の GUI は AWS マネジメントコンソール、マルチアカウントのランディングゾーン自動構築とガードレール統制は AWS Control Tower が担います。

5.3.3この節のまとめ

• 切り分け＝ルート→SG（ステートフル）→NACL（ステートレス）
• 裏取り＝フローログの REJECT／Reachability Analyzer
• 連携＝EventBridge、通知＝SNS、キュー＝SQS、統制＝Control Tower/Trusted Advisor/Well-Architected