ある企業のプライベートサブネットにある EC2 インスタンスは、NAT ゲートウェイ経由で外部 API（HTTPS/443）へ正常に通信できていました。最近、サブネットにカスタムネットワーク ACL を関連付けたところ、

Question

ある企業のプライベートサブネットにある EC2 インスタンスは、NAT ゲートウェイ経由で外部 API（HTTPS/443）へ正常に通信できていました。最近、サブネットにカスタムネットワーク ACL を関連付けたところ、インスタンスからの外向き HTTPS リクエストは送信されるものの、応答が届かず通信がタイムアウトするようになりました。確認すると、NACL のアウトバウンドルールでは宛先ポート 443 が許可され、セキュリティグループのアウトバウンドは全許可、インバウンドは必要最小限に設定されています。通信を復旧させる最も適切な対応はどれですか。

Accepted Answer

正解: 関連付けたネットワーク ACL のインバウンドルールに、TCP のエフェメラルポート範囲 1024-65535 を許可するルールを追加し、NAT ゲートウェイ経由の戻りトラフィックを通過させる。ネットワーク ACL はステートレスであり、アウトバウンドで許可したトラフィックの戻りパケットも、インバウンドルールで明示的に許可しなければなりません。

外部 API からの応答はクライアント側のエフェメラルポート（Linux では一般に 1024-65535）宛に返ってくるため、NACL のインバウンドにこの範囲の TCP 許可を追加する必要があります。

選択肢1のセキュリティグループはステートフルで、アウトバウンドで許可した通信の戻りは自動的に許可されるため、インバウンド追加は不要であり原因の診断が誤り。
選択肢2の戻りトラフィックは宛先ポート 443 ではなくエフェメラルポート宛のため、443 の許可を追加しても応答は通過しない。
選択肢3のセキュリティグループはステートレスに変更できず、設定自体が不可能なため失格。

Answer

セキュリティグループのインバウンドルールに TCP のエフェメラルポート 1024-65535 を許可するルールを追加し、外部 API からの戻りトラフィックを明示的に有効化する — セキュリティグループはステートフルで、アウトバウンドで許可した通信の戻りトラフィックは自動的に許可されます。インバウンドへのエフェメラルポート追加は不要であり、タイムアウトの原因は SG ではなくステートレスな NACL にあるため診断が誤りです。

Answer

ネットワーク ACL のアウトバウンドで 443 を許可済みのため、インバウンドの拒否ルールの番号をより小さい番号に変更し、ポート 443 を明示的に許可するルールを追加する — 戻りトラフィックは送信元の 443 から発し、宛先はクライアントのエフェメラルポートです。NACL のインバウンドで 443 を許可しても応答パケットの宛先ポートと一致しないため通過できず、問題は解決しません。

Answer

セキュリティグループをステートレス動作に変更し、インバウンドとアウトバウンドの双方にエフェメラルポート範囲を明示的に許可して戻りトラフィックを通す — セキュリティグループは常にステートフルで動作し、ステートレスへ変更する設定オプションは存在しません。前提自体が成立しないため実行不可能であり、対応として失格です。

解説

解説