# Amazon EC2 セキュリティグループの接続の追跡
セキュリティグループは、接続追跡を使用してインスタンスを出入りするトラフィックに関する情報を追跡します。ルールはトラフィックの接続の状態に基づいて適用され、トラフィックを許可するか拒否するかが判断されます。このアプローチでは、セキュリティグループはステートフルです。これは、セキュリティグループのアウトバウンドルールにかかわらず、インバウンドトラフィックに対するレスポンスがインスタンスから送信されることを許可することを意味します。逆も同じです。
例えば、自宅のコンピュータからインスタンスに対し netcat や同様の ICMP コマンドを開始する場合を考えます。この時、インバウンドセキュリティグループは、ICMP トラフィックを許可しているとします。接続に関する情報 (ポート情報を含む) が追跡されます。コマンドに対するインスタンスからのレスポンストラフィックは、新しいリクエストではなく確立済みの接続として追跡されます。また、セキュリティグループのアウトバウンドルールが、アウトバウンドの ICMP トラフィックを制限している場合でも、このトラフィックはインスタンスから外部に出力されることが許されます。
TCP、UDP、または ICMP 以外のプロトコルの場合は、IP アドレスとプロトコル番号のみが追跡されます。インスタンスが別のホストにトラフィックを送信し、そのホストが 600 秒以内に同じタイプのトラフィックをインスタンスに送信した場合、インスタンスのセキュリティグループはインバウンドセキュリティグループルールに関係なく、そのトラフィックを受け入れます。そのトラフィックが元のトラフィックのレスポンストラフィックとみなされるからです。
セキュリティグループルールを変更しても、そのルールで追跡された接続がすぐに中断されることはありません。セキュリティグループは、既存の接続がタイムアウトするまで引き続きパケットを許可します。トラフィックをすぐに中断するか、追跡状態に関係なくすべてのトラフィックをファイアウォールルールの対象にするには、サブネットにネットワーク ACL を使用します。ネットワーク ACL はステートレスであるため、レスポンスのトラフィックを自動的には許可しません。いずれかの方向のトラフィックをブロックするネットワーク ACL を追加すると、既存の接続が切断されます。詳細については、「*Amazon VPC ユーザーガイド*」の「[ネットワーク ACL](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html)」を参照してください。
**注記**
セキュリティグループは、「VPC \$12 IP アドレス」(「*Amazon Route 53 デベロッパーガイド*」の「[Amazon Route 53 Resolver とは](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver.html)」を参照)、または「AmazonProvidedDNS」(「*Amazon Virtual Private Cloud ユーザーガイド*」の「[DHCP オプションセットの使用](https://docs.aws.amazon.com/vpc/latest/userguide/DHCPOptionSet.html)」を参照) と呼ばれることもある Route 53 Resolver から送受信される DNS トラフィックに影響を及ぼすことはありません。Route 53 Resolver で DNS リクエストをフィルタリングしたい場合は、Route 53 Resolver DNS ファイアウォールを有効にできます (「*Amazon Route 53 デベロッパーガイド*」の「[Route 53 Resolver DNS ファイアウォール](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resolver-dns-firewall.html)」を参照)。
## 追跡されていない接続
すべてのトラフィックフローが追跡されるわけではありません。セキュリティグループのルールがすべてのトラフィック (0.0.0.0/0 または ::/0) の TCP または UDP フローを許可していて、片方の方向には任意のポート (0～65535) のすべての応答トラフィック (0.0.0.0/0 または ::/0) を許可するルールがある場合、そのトラフィックフローは[自動的に追跡される接続](#automatic-tracking)の一部でない限り追跡されません。追跡されていないフローのレスポンストラフィックは、追跡情報ではなく、レスポンストラフィックを許可するインバウンドルールまたはアウトバウンドルールに基づいて許可されます。
追跡されていないトラフィックフローは、そのフローを有効にするルールが削除または変更されるとすぐに中断されます。例えば、オープン (0.0.0.0/0) のアウトバウンドルールがあり、インスタンスへのすべて(0.0.0.0/0) のインバウンドの SSH (TCP ポート 22) トラフィックを許可するルールを削除した場合 (または接続を許可しないように変更した場合)、インスタンスへの既存の SSH 接続はすぐに中断されます。接続はそれまで追跡されていないため、この変更によって接続が切断されます。一方、最初に細かく SSH 接続を許可する (つまり、接続を追跡する) インバウンドルールがある場合、現在の SSH クライアントのアドレスからの新しい接続を許可しないようにルールを変更しても、既存の SSH 接続は追跡対象であるため中断されません。
## 自動的に追跡される接続
セキュリティ グループの構成で追跡が必要ない場合でも、次の方法で行われた接続は自動的に追跡されます。
+ Egress-Only インターネットゲートウェイ
+ Global Accelerator アクセラレーター
+ NAT ゲートウェイ
+ Network Firewall ファイアウォールのエンドポイント
+ Network Load Balancer
+ AWS PrivateLink (インターフェイス VPC エンドポイント)
+ AWS Lambda (Hyperplane Elastic Network Interface)
+ DynamoDB のゲートウェイエンドポイント – DynamoDB への各接続は 2 つの conntrack エントリを消費します。
## 追跡できる接続の最大数
Amazon EC2 では、インスタンスごとに追跡できる接続の最大数が定義されています。追跡が最大数に達すると、新しい接続が確立されることはないため、送受信されるパケットはすべてドロップされます。この場合、パケットを送受信するアプリケーションは正しく通信できません。`conntrack_allowance_available` ネットワークパフォーマンスメトリクスを使用して、そのインスタンスタイプでまだ利用可能な接続トラッキングの数を判断します。
インスタンスのネットワークトラフィックが追跡可能な接続の最大数を超えたために、パケットがドロップされたかどうかを判断するには、ネットワークパフォーマンスメトリクス `conntrack_allowance_exceeded` を参照します。詳細については、[EC2 インスタンスでの ENA 設定のネットワークパフォーマンスのモニタリング](monitoring-network-performance-ena.md)を参照してください。
Elastic Load Balancing を実行している際にインスタンスごとに追跡できる接続の最大数を超える場合は、ロードバランサーに登録されているインスタンスの数、あるいは登録されているインスタンスのサイズのいずれかをスケールすることをお勧めします。
## 接続追跡のベストプラクティス
トラフィックが特定のネットワークインターフェースからインスタンスに入り、別のネットワークインターフェースから外に出る、非対称ルーティングでは、フローを追跡した場合に、インスタンスが達成できるピークパフォーマンスが低下する可能性があります。
セキュリティグループで接続追跡が有効になっている場合にピークパフォーマンスを維持して接続管理を最適化するには、次の設定をお勧めします。
+ 可能であれば、非対称ルーティングトポロジーは避けてください。
+ フィルタリングにセキュリティグループを使用する代わりに、ネットワーク ACL を使用します。
+ 接続追跡でセキュリティグループを使用する必要がある場合は、可能な限り短い接続追跡のアイドル状態タイムアウトを設定します。接続追跡のアイドル状態タイムアウトの詳細については、次のセクションを参照してください。
+ Nitrov6 インスタンスではデフォルトのタイムアウト時間が短いため、存続期間の長い接続 (データベース接続プール、永続的な HTTP 接続、ストリーミングワークロードなど) を持つアプリケーションは、インスタンス起動時に適切な `TcpEstablishedTimeout` 値を設定する必要があります。
+ 存続期間の長い接続の場合は、接続を開いたままにして追跡状態を維持するために TCP キープアライブを 5 分未満の間隔で送信するように設定します。これにより、アイドルタイムアウトによる接続のドロップを防ぎ、接続の再確立のオーバーヘッドを削減できます。
Nitro システムによるパフォーマンスチューニングの詳細については、[Nitro System のパフォーマンスチューニングに関する考慮事項](ena-nitro-perf.md)を参照してください。
## アイドル接続追跡タイムアウト
セキュリティグループは、確立された各接続を追跡し、リターンパケットが期待どおりに配信されることを保証します。インスタンスごとに追跡できる接続の最大数があります。接続がアイドル状態のままになると、接続追跡が使い果たされることで接続が追跡されなくなり、また、パケットがドロップされる原因となります。Elastic Network Interface では、アイドル接続の追跡にタイムアウトを設定できます。
**注記**
この機能は、[Nitro ベースのインスタンス](instance-types.md#instance-hypervisor-type)でのみ使用できます。Nitrov6 世代インスタンスでアプリケーションをテストするには、本番環境にデプロイする前に、`350` 2 番目のデフォルトの接続追跡タイムアウトを短くする必要があります。
設定可能なタイムアウトは 3 つ用意されています。
+ **TCP 確立タイムアウト**: 確立された状態のアイドル TCP 接続のタイムアウト (秒単位)。
+ 最小: `60` 秒
+ 最大: `432000` 秒
+ デフォルト: [Nitrov6](https://docs.aws.amazon.com/ec2/latest/instancetypes/ec2-nitro-instances.html) インスタンスタイプ (P6e-GB200 を除く) の場合、`350` 秒。その他のインスタンスタイプ (P6e-GB200 を含む) の場合、`432000` 秒。
+ 推奨: `432000` 秒未満
+ **UDP タイムアウト**: 単一方向、または 1 つのリクエスト-レスポンストランザクションのみのトラフィックが発生した、アイドル状態にある UDP フローのタイムアウト (秒単位)。
+ 最小: `30` 秒
+ 最大: `60` 秒
+ デフォルト: `30` 秒
+ **UDP ストリームタイムアウト**: 複数のリクエスト-レスポンストランザクションが発生したストリームとして分類される、アイドル状態にある UDP フローのタイムアウト (秒単位)。
+ 最小: `60` 秒
+ 最大: `180` 秒
+ デフォルト: `180` 秒
以下のいずれかに当てはまる場合は、デフォルトのタイムアウトの変更が必要になる場合があります。
+ [Amazon EC2 のネットワークパフォーマンスメトリクスを使用して追跡接続をモニタリング](monitoring-network-performance-ena.md)している場合は、*conntrack\$1allowance\$1exceeded* および *conntrack\$1allowance\$1available* メトリクスにより、ドロップされたパケットと追跡された接続使用率をモニタリングできるようになります。これにより、スケールアップまたはスケールアウトアクションにより EC2 インスタンスの容量を事前に管理し、パケットのドロップが発生する前にネットワーク接続の需要を満たすことができます。EC2 インスタンスで *conntrack\$1allowance\$1exceeded* のドロップが観測された場合は、不適切なクライアントやネットワークのミドルボックスが原因で TCP/UDP セッションの使用期間が長くなりすぎることを考慮して、TCP 確立のタイムアウトを低く設定すると、メリットが得られる場合があります。
+ 通常、ロードバランサーまたはファイアウォールの TCP Established アイドルタイムアウトは、60 分～90 分の範囲に設定されています。ネットワークファイアウォールなどのアプライアンスからの、非常に多くの (10万件を超える) 接続を処理することが予想されるワークロードを実行している場合は、EC2 ネットワークインターフェイスでも同様のタイムアウトを設定することをお勧めします。
+ 非対称ルーティングトポロジを使用するワークロードを実行している場合は、TCP 確立アイドルタイムアウトを 60 秒に設定することをお勧めします。
+ 主に UDP を使用してリクエストを処理するサービス (例えば DNS、SIP、SNMP、Syslog、Radius) など、接続数が多いワークロードを実行している場合、「UDP ストリーム」のタイムアウトを 60 秒に設定すると、既存の容量のスケール対パフォーマンス比が向上し、グレーな障害を防ぐことができます。
+ Network Load Balancer を経由する TCP/UDP 接続では、すべての接続が追跡されます。TCP フローのアイドルタイムアウト値は 350 秒、UDP フローのアイドルタイムアウト値は 120 秒で、インターフェイスレベルのタイムアウト値により変化します。ロードバランサーのデフォルトよりもタイムアウトを柔軟にするために、ネットワークインターフェイスレベルでタイムアウトを設定することもできます。
以下の操作を行う際には、接続追跡のタイムアウト設定のオプションが用意されています。
+ [ネットワークインターフェイスの作成](create-network-interface.md)
+ [ネットワークインターフェイス属性の変更](modify-network-interface-attributes.md)
+ [EC2 インスタンスの起動](ec2-instance-launch-parameters.md#liw-network-settings)
+ [EC2 インスタンスの起動テンプレートの作成](ec2-instance-launch-parameters.md#liw-network-settings)
## 例
次の例では、セキュリティグループに TCP および ICMP トラフィックを許可するインバウンドルールと、すべてのアウトバウンドトラフィックを許可するアウントバウンドルールがあります。
**インバウンド**
| プロトコルのタイプ | ポート番号 | ソース |
| --- | --- | --- |
| TCP | 22 (SSH) | 203.0.113.1/32 |
| TCP | 80 (HTTP) | 0.0.0.0/0 |
| TCP | 80 (HTTP) | ::/0 |
| ICMP | すべて | 0.0.0.0/0 |
**アウトバウンド**
| プロトコルのタイプ | ポート番号 | 目的地 |
| --- | --- | --- |
| すべて | すべて | 0.0.0.0/0 |
| すべて | すべて | ::/0 |
インスタンスまたはネットワークインターフェイスに対して直接ネットワーク接続を確立した場合、追跡動作は次のようになります。
+ インバウンドルールでは 203.0.113.1/32 からのトラフィックのみ許可されるため、ポート 22 のインバウンドおよびアウトバウンド TCP トラフィック (SSH) は追跡されますが、必ずしもすべての IP アドレス (0.0.0.0/0) が追跡されるとは限りません。
+ インバウンドルールとアウトバウンドルールですべての IP アドレスからのトラフィックが許可されるため、ポート 80 (HTTP) のインバウンドおよびアウトバウンド TCP トラフィックは追跡されません。
+ ICMP トラフィックは常に追跡されます。
IPv4 トラフィックのアウトバウンドルールを削除すると、ポート 80 (HTTP) のトラフィックを含めすべてのインバウンドおよびアウトバウンド IPv4 トラフィックが追跡されます。IPv6 トラフィックのアウトバウンドルールを削除すると、IPv6 トラフィックでも同じことが起きます。