VPCのパブリック・プライベートサブネットのシナリオ判断

通販サイトの公開、更新、S3接続の障害から、足りない経路と許可を特定します。構成図を読み、症状と修正箇所を結び付ける練習です。

この単元で学ぶこと

  • 症状からルートとアドレスの不足を特定する
  • 宛先に応じた出口を判断する
  • 公開範囲と障害依存を評価する

本文解説

1. 公開したつもりのEC2 Web用EC2をpublicと名付けたサブネットへ置いても、適用ルートにIGWがなければ意図した公開経路にはなりません。EIP、IGWの取付け、サブネットとの関連付け、許可を順に確認します。全SGを開ける対応は経路不足を解決しないうえ、不要な許可を増やします。

2. 公開経路はあるのに失敗 IGW経路と公開IPv4が確認できたら、SG、NACL、OS、アプリへ進みます。Webプロセスがlocalhostだけで待ち受けていれば、AWS側の経路変更だけでは直りません。名前解決で古い宛先が返っていないかも確認し、問題の層を一つずつ絞ります。

3. 更新通信を許す 内部アプリはインターネットからの着信不要ですが、OS更新を取りに行く必要があります。IPv4のzonal public NAT構成なら内部側はNATへ、NAT側はIGWへ向けます。EC2を公開サブネットへ移す以外の方法があると理解し、必要以上の公開を避けます。

4. S3だけの転送 内部バッチが同リージョンのS3へだけ大量転送する場合、Gateway Endpointと関連ルートを比較します。作成後も対象サブネットのルートやIAM・バケットポリシーが違えば失敗します。NAT費用を削減する狙いと、許可するバケットを絞る狙いを分けて検証します。

5. 戻りの遮断 外向きHTTPSは出ているのに応答が届かない場合、NACLの戻りルールにクライアント側の一時ポートが含まれるかを確認します。Security Groupの状態追跡と同じ感覚で戻り不要と判断しないことが重要です。方向別に送信元・宛先ポートを書き出します。

6. 一方のAZで障害 AZ-Aのzonal NATをAとBの双方で使う構成では、Aの障害時にBも更新先へ行けなくなる可能性があります。各AZで同じAZのNATへ向ける構成と、常時費用を比較します。単にサーバーが2AZにあるだけで必要な外部依存まで冗長になるわけではありません。

7. IPv6の見落とし IPv4の出口は閉じたのに通信が続く場合、DNSがAAAAを返しIPv6経路を使っていないか調べます。::/0と対応する制御を確認します。意図するのがIPv6外向きだけならEgress-only IGWを使い、IGWへの直接経路とは開始方向の要件を区別します。

8. 成功と拒否を確認 変更後はWeb入口への接続、内部アプリから必要宛先への接続を確かめます。同時に外部からDBへ直接接続できないこと等も確認します。通信成功だけを増やすことを目的にせず、要求された許可範囲と障害時の挙動を満たしたかを合否とします。

図解

症状と調べる場所
症状に応じた経路を追い、不要な全開放で隠さないようにします。

重要ポイント

  • 経路不足をSG全開放で直そうとしない
  • NAT側と内部側のルートを両方確認する
  • 2AZのEC2でも出口が一系統なら依存が残る

間違えやすい点

  • 名前解決成功を全通信成功と同一視しない
  • NACLの方向とポートを取り違えない
  • IPv4だけの制御でIPv6まで閉じたと報告しない

用語解説

到達性
必要な経路と許可のもとで宛先へ通信できる性質。
依存経路
サービスが動くために必要な外部通信の経路。
疎通確認
要求された接続が成立するかを実際に検証すること。

関連教材

参考資料

教材データに登録された参考リンクです。リンク先の内容や更新日は提供元でご確認ください。

確認問題の出題・採点や学習履歴の保存にはログインが必要です。