翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Network Load Balancers のターゲットグループ
各*ターゲットグループ*は、1 つ以上の登録されているターゲットにリクエストをルーティングするために使用されます。リスナーを作成するときは、デフォルトアクションのターゲットグループを指定します。トラフィックは、リスナー規則で指定されたターゲットグループに転送されます。さまざまなタイプのリクエストに応じて別のターゲットグループを作成できます。たとえば、一般的なリクエスト用に 1 つのターゲットグループを作成し、アプリケーションのマイクロサービスへのリクエスト用に別のターゲットグループを作成できます。詳細については、「[Network Load Balancer のコンポーネント](introduction.md#network-load-balancer-components)」を参照してください。
ロードバランサーのヘルスチェック設定は、ターゲットグループ単位で定義します。各ターゲットグループはデフォルトのヘルスチェック設定を使用します。ただし、ターゲットグループを作成したときや、後で変更したときに上書きした場合を除きます。リスナーのルールでターゲットグループを指定すると、ロードバランサーは、ロードバランサーで有効なアベイラビリティーゾーンにある、ターゲットグループに登録されたすべてのターゲットの状態を継続的にモニタリングします。ロードバランサーは、正常な登録済みターゲットにリクエストをルーティングします。詳細については、「[Network Load Balancer ターゲットグループのヘルスチェック](target-group-health-checks.md)」を参照してください。
**Topics**
+ [ルーティング設定](#target-group-routing-configuration)
+ [[Target type (ターゲットタイプ)]](#target-type)
+ [IP アドレスタイプ](#target-group-ip-address-type)
+ [登録済みターゲット](#registered-targets)
+ [ターゲットグループの属性](#target-group-attributes)
+ [ターゲットグループの正常性](#target-group-health)
+ [ターゲットグループの作成](create-target-group.md)
+ [ヘルス設定を更新する](modify-target-group-health-settings.md)
+ [ヘルスチェックを設定する](target-group-health-checks.md)
+ [ターゲットグループ属性を編集する](edit-target-group-attributes.md)
+ [ターゲットの登録](target-group-register-targets.md)
+ [ターゲットとして Application Load Balancer を使用する](application-load-balancer-target.md)
+ [ターゲットグループにタグを付ける](target-group-tags.md)
+ [ターゲットグループの削除](delete-target-group.md)
## ルーティング設定
デフォルトでは、ロードバランサーはターゲットグループの作成時に指定したプロトコルとポート番号を使用して、リクエストをターゲットにルーティングします。または、ターゲットグループへの登録時にターゲットへのトラフィックのルーティングに使用されるポートを上書きすることもできます。
Network Load Balancer のターゲットグループは、次のプロトコルとポートをサポートします。
+ **プロトコル**: TCP、TLS、UDP、TCP\$1UDP、QUIC、TCP\$1QUIC
+ **ポート**: 1 ～ 65535
ターゲットグループに TLS プロトコルが設定されている場合、ロードバランサーは、ターゲットにインストールした証明書を使用して、ターゲットと TLS 接続を確立します。ロードバランサーはこれらの証明書を検証しません。したがって、自己署名証明書または期限切れの証明書を使用できます。ロードバランサーは仮想プライベートクラウド (VPC) 内にあるため、ロードバランサーとターゲット間のトラフィックはパケットレベルで認証されるため、ターゲットの証明書が有効でない場合でも、中間者攻撃やスプーフィングのリスクはありません。
次の表は、リスナープロトコルとターゲットグループの設定のサポートされている組み合わせをまとめたものです。
| リスナープロトコル | ターゲットグループプロトコル | ターゲットグループの種類 | ヘルスチェックプロトコル |
| --- | --- | --- | --- |
| TCP | TCP \$1 TCP\$1UDP \$1 TCP\$1QUIC | インスタンス \$1 ip | HTTP \$1 HTTPS \$1 TCP |
| TCP | TCP | alb | HTTP \$1 HTTPS |
| TLS | TCP \$1 TLS | インスタンス \$1 ip | HTTP \$1 HTTPS \$1 TCP |
| UDP | UDP \$1 TCP\$1UDP | インスタンス \$1 ip | HTTP \$1 HTTPS \$1 TCP |
| TCP\$1UDP | TCP\$1UDP | インスタンス \$1 ip | HTTP \$1 HTTPS \$1 TCP |
| QUIC | QUIC \$1 TCP\$1QUIC | インスタンス \$1 ip | HTTP \$1 HTTPS \$1 TCP |
| TCP\$1QUIC | TCP\$1QUIC | インスタンス \$1 ip | HTTP \$1 HTTPS \$1 TCP |
## [Target type (ターゲットタイプ)]
ターゲットグループを作成するときは、そのターゲットの種類を指定します。ターゲットの種類は、ターゲットの指定方法を決定します。ターゲットグループを作成した後で、ターゲットタイプを変更することはできません。
可能なターゲットの種類は次のとおりです。
`instance`
インスタンス ID で指定されたターゲット。
`ip`
IP アドレスで指定されたターゲット。
`alb`
ターゲットは Application Load Balancer です。
ターゲットの種類が `ip` の場合、次のいずれかの CIDR ブロックから IP アドレスを指定できます。
+ ターゲットグループの VPC のサブネット
+ 10.0.0.0/8 ([RFC 1918](https://tools.ietf.org/html/rfc1918))
+ 100.64.0.0/10 ([RFC 6598](https://tools.ietf.org/html/rfc6598))
+ 172.16.0.0/12 (RFC 1918)
+ 192.168.0.0/16 (RFC 1918)
**重要**
パブリックにルーティング可能な IP アドレスは指定できません。
サポートされているすべての CIDR ブロックによって、次のターゲットをターゲットグループに登録できます。
+ AWS IP アドレスとポートでアドレス可能な リソース (データベースなど）。
+ Direct Connect または Site-to-Site VPN 接続 AWS を介して にリンクされたオンプレミスリソース。
ターゲットグループでクライアント IP の保存が無効化されている場合、ロードバランサーは Network Load Balancer の IP アドレスと一意のターゲット (IP アドレスとポート) の組み合わせごとに 1 分あたり約 55,000 の接続をサポートできます。これらの接続数を超えた場合、ポート割り当てエラーが発生する可能性が高くなります。ポート割り当てエラーが発生した場合は、ターゲットグループにさらに多くのターゲットを追加します。
共有 VPC で (参加者として) Network Load Balancer を起動した場合、登録できるのは、共有されているサブネット内のターゲットだけです。
ターゲットタイプが `alb` の場合、単一の Application Load Balancer をターゲットとして登録できます。詳細については、「[Network Load Balancer のターゲットとして Application Load Balancer を使用する](application-load-balancer-target.md)」を参照してください。
Network Load Balancer は、`lambda` ターゲットタイプをサポートしていません。Application Load Balancer は、`lambda` ターゲットタイプをサポートする唯一のロードバランサーです。詳細については、「*Application Load Balancer ユーザーガイド*」の「[ターゲットとしての Lambda 関数](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/lambda-functions.html)」を参照してください。
Network Load Balancer に登録されているインスタンスでマイクロサービスを使用している場合、ロードバランサーを使用してインスタンス間の通信を提供することはできません。ただし、ロードバランサーがインターネット向けであるか、インスタンスが IP アドレスで登録されている場合は除きます。詳しくは、「[ターゲットからそのロードバランサーへのリクエストが接続タイムアウトになる](load-balancer-troubleshooting.md#loopback-timeout)」を参照してください。
### リクエストのルーティングと IP アドレス
インスタンス ID を使用してターゲットを指定すると、トラフィックはインスタンスのプライマリネットワークインターフェイスで指定されたプライマリプライベート IP アドレスを使用して、インスタンスにルーティングされます。ロードバランサーは、データパケットの宛先 IP アドレスを書き換えてから、ターゲットインスタンスに転送します。
IP アドレスを使用してターゲットを指定する場合は、1 つまたは複数のネットワークインターフェイスからのプライベート IP アドレスを使用して、トラフィックをインスタンスにルーティングできます。これにより、インスタンスの複数のアプリケーションが同じポートを使用できるようになります。各ネットワークインターフェイスはそれぞれ独自のセキュリティグループを割り当てることができます。ロードバランサーは、宛先 IP アドレスを書き換えてから、ターゲットに転送します。
インスタンスへのトラフィックの許可の詳細については、[ターゲットセキュリティグループ](target-group-register-targets.md#target-security-groups) を参照してください。
### ターゲットとしてのオンプレミスリソース
Direct Connect または Site-to-Site VPN 接続を介してリンクされたオンプレミスリソースは、ターゲットタイプが の場合、ターゲットとして機能します`ip`。
![\[AWS Direct Connect または を使用して、Network Load Balancer をオンプレミスサーバーに接続します AWS Site-to-Site VPN。\]](http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/images/nlb-on-prem-resources.png)
オンプレミスのリソースを使用する場合、これらのターゲットの IP アドレスは、引き続き次の CIDR ブロックのいずれかから取得する必要があります。
+ 10.0.0.0/8 ([RFC 1918](https://tools.ietf.org/html/rfc1918))
+ 100.64.0.0/10 ([RFC 6598](https://tools.ietf.org/html/rfc6598))
+ 172.16.0.0/12 (RFC 1918)
+ 192.168.0.0/16 (RFC 1918)
詳細については Direct Connect、[「 とは」を参照してください Direct Connect。](https://docs.aws.amazon.com/directconnect/latest/UserGuide/)
詳細については AWS Site-to-Site VPN、[「 とは」を参照してください AWS Site-to-Site VPN。](https://docs.aws.amazon.com/vpn/latest/s2svpn/)
## IP アドレスタイプ
新しいターゲットグループを作成するときは、ターゲットグループの IP アドレスタイプを選択できます。これは、ターゲットとの通信、およびそれらのヘルスステータスのチェックに使用される IP バージョンを制御します。
お使いの Network Load Balancer のターゲットグループは、次の IP アドレスタイプをサポートしています。
**`ipv4`**
ロードバランサーは IPv4 を使用してターゲットと通信します。
**`ipv6`**
ロードバランサーは IPv6 を使用してターゲットと通信します。
**考慮事項**
+ ロードバランサーは、ターゲットグループの IP アドレスのタイプに基づいてターゲットと通信します。IPv4 ターゲットグループのターゲットはロードバランサーからの IPv4 トラフィックを受け入れる必要があり、IPv6 ターゲットグループのターゲットはロードバランサーからの IPv6 トラフィックを受け入れる必要があります。
+ `ipv4` ロードバランサーで IPv6 ターゲットグループを使用することはできません。
+ `dualstack` ロードバランサーの UDP リスナーで IPv4 ターゲットグループを使用することはできません。
+ IPv6 ターゲットグループを使用して Application Load Balancer を登録することはできません。
+ QUIC または TCP\$1QUIC プロトコルで IPv6 ターゲットグループを使用することはできません。
## 登録済みターゲット
ロードバランサーは、クライアントにとって単一の通信先として機能し、正常な登録済みターゲットに受信トラフィックを分散します。各ターゲットグループでは、ロードバランサーが有効になっている各アベイラビリティーゾーンで少なくとも 1 つのターゲットが登録されている必要があります。各ターゲットは、1 つ以上のターゲットグループに登録できます。
アプリケーションの需要が高まった場合、需要に対処するため、1 つまたは複数のターゲット グループに追加のターゲットを登録できます。設定したしきい値に関係なく、登録処理が完了し、ターゲットが最初の初期ヘルスチェックに合格するとすぐに、ロードバランサーは新しく登録したターゲットへのトラフィックのルーティングを開始します。
アプリケーションの需要が低下した場合や、ターゲットを保守する必要がある場合、ターゲットグループからターゲットを登録解除することができます。ターゲットを登録解除するとターゲットグループから削除されますが、ターゲットにそれ以外の影響は及びません。登録解除するとすぐに、ロードバランサーはターゲットへのトラフィックのルーティングを停止します。ターゲットは、未処理のリクエストが完了するまで `draining` 状態になります。トラフィックの受信を再開する準備ができると、ターゲットをターゲットグループに再度登録することができます。
インスタンス ID でターゲットを登録する場合は、Auto Scaling グループでロードバランサーを使用できます。Auto Scaling グループにターゲットグループをアタッチすると、ターゲットの起動時に Auto Scaling によりターゲットグループにターゲットが登録されます。詳細については、「*Amazon EC2 Auto Scaling ユーザーガイド*」の「[Auto Scaling グループへのロードバランサーのアタッチ](https://docs.aws.amazon.com/autoscaling/ec2/userguide/attach-load-balancer-asg.html)」を参照してください。
**要件と考慮事項**
+ インスタンスで使用されているインスタンスタイプが C1、CC1、CC2、CG1、CG2、CR1、G1、G2、HI1、HS1、M1、M2、M3、T1 のいずれかである場合、インスタンス ID でインスタンスを登録することはできません。
+ IPv6 ターゲットグループにインスタンス ID でターゲットを登録する場合、ターゲットにはプライマリ IPv6 アドレスが割り当てられている必要があります。詳細については、「*Amazon EC2 ユーザーガイド*」の「[IPv6 アドレス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-instance-addressing.html#ipv6-addressing)」を参照してください。
+ インスタンス ID でターゲットを登録する場合、インスタンスは Network Load Balancer と同じ VPC にある必要があります。ロードバランサー VPC (同じリージョンまたは異なるリージョン) とピア接続されている VPC にインスタンスがある場合、そのインスタンスをインスタンス ID で登録することはできません。このようなインスタンスは IP アドレスで登録できます。
+ ターゲットを IP アドレスで登録し、その IP アドレスがロードバランサーと同じ VPC にある場合、ロードバランサーは、到達可能なサブネットからターゲットがアクセスしていることを確認します。
+ ロードバランサーは、有効になっているアベイラビリティーゾーン内のターゲットのみにトラフィックをルーティングします。有効になっていないゾーン内のターゲットは使用されません。
+ UDP、TCP\$1UDP、QUIC、TCP\$1QUIC ターゲットグループの場合、インスタンスがロードバランサー VPC の外部に存在するか、インスタンスタイプとして C1、CC1、CC2、CG1、CG2、CR1、G1、G2、HI1、HS1、M1、M2、M3、T1 のいずれかを使用しているときは、IP アドレスでインスタンスを登録しないでください。ロードバランサー VPC の外部に存在するか、サポートされていないインスタンスタイプを使用するターゲットは、ロードバランサーからのトラフィックを受信できても、応答できない場合があります。
## ターゲットグループの属性
ターゲットグループは属性を編集することで設定できます。詳細については、「[ターゲットグループ属性を編集する](edit-target-group-attributes.md)」を参照してください。
次のターゲット グループの属性がサポートされています。これらの属性は、ターゲットグループタイプが `instance` または `ip` の場合にのみ変更できます。ターゲットグループタイプが `alb` の場合、これらの属性は常にデフォルト値を使用します。
`deregistration_delay.timeout_seconds`
登録解除するターゲットの状態が `draining` から `unused` に変わるのを Elastic Load Balancing が待機する時間。範囲は 0 ～ 3600 秒です。デフォルト値は 300 秒です。QUIC トラフィックの場合、値は常に 300 秒です。
`deregistration_delay.connection_termination.enabled`
ロードバランサーが登録解除タイムアウトの終了時に接続を終了するかどうかを示します。値は `true` または `false` です。新しい UDP/TCP\$1UDP ターゲットグループの場合、デフォルトは `true` です。それ以外の場合は、デフォルトは `false` です。この属性は QUIC トラフィックには適用されません。
`load_balancing.cross_zone.enabled`
クロスゾーンロードバランサーが有効かどうかを示します。値は `true`、`false` または `use_load_balancer_configuration` です。デフォルトは `use_load_balancer_configuration` です。
`preserve_client_ip.enabled`
クライアント IP の保存が有効かどうかを示します。値は `true` または `false` です。ターゲットグループの種類が IP アドレスで、ターゲットグループプロトコルが TCP または TLS の場合、デフォルトは無効です。それ以外の場合、デフォルトは有効です。UDP、TCP\$1UDP、QUIC、TCP\$1QUIC ターゲットグループのクライアント IP 保存を無効にすることはできません。
`proxy_protocol_v2.enabled`
Proxy Protocol バージョン 2 が有効になっているかどうかを示します。Proxy Protocol は、デフォルトで無効になっています。
`stickiness.enabled`
スティッキーセッションが有効かどうかを示します。値は `true` または `false` です。デフォルトは `false` です。この属性は QUIC トラフィックには適用されません。
`stickiness.type`
維持の種類です。有効な値は `source_ip` です。
`target_group_health.dns_failover.minimum_healthy_targets.count`
正常でなければならないターゲットの最小数。正常なターゲットの数がこの値を下回っている場合は、DNS でそのゾーンを異常とマークして、トラフィックが正常なゾーンにのみルーティングされるようにします。指定できる値は、`off` または 1 から最大ターゲット数までの整数です。`off` の場合、DNS フェイルアウェイは無効化されます。つまり、ターゲットグループ内のすべてのターゲットが異常であっても、ゾーンは DNS から削除されません。デフォルトは 1 です。
`target_group_health.dns_failover.minimum_healthy_targets.percentage`
正常でなければならないターゲットの最小割合。正常なターゲットの割合がこの値を下回っている場合は、DNS でそのゾーンを異常とマークして、トラフィックが正常なゾーンにのみルーティングされるようにします。指定できる値は、`off` または 1 から 100 までの整数です。`off` の場合、DNS フェイルアウェイは無効化されます。つまり、ターゲットグループ内のすべてのターゲットが異常であっても、ゾーンは DNS から削除されません。デフォルトは `off` です。
`target_group_health.unhealthy_state_routing.minimum_healthy_targets.count`
正常でなければならないターゲットの最小数。正常なターゲットの数がこの値を下回っている場合は、異常なターゲットを含むすべてのターゲットにトラフィックを送信します。指定できる値は、1～最大ターゲット数です。デフォルトは 1 です。
`target_group_health.unhealthy_state_routing.minimum_healthy_targets.percentage`
正常でなければならないターゲットの最小割合。正常なターゲットの割合がこの値を下回っている場合は、異常なターゲットを含むすべてのターゲットにトラフィックを送信します。指定できる値は、`off` または 1 から 100 までの整数です。デフォルトは `off` です。
`target_health_state.unhealthy.connection_termination.enabled`
ロードバランサーが異常なターゲットへの接続を終了するかどうかを示します。値は `true` または `false` です。デフォルトは `true` です。
`target_health_state.unhealthy.draining_interval_seconds`
異常なターゲットの状態が `unhealthy.draining` から `unhealthy` に変わるのを Elastic Load Balancing が待機する時間。範囲は 0～360,000 秒です。デフォルト値は0秒です。
**[注:]** この属性は、`target_health_state.unhealthy.connection_termination.enabled` が `false` の場合にのみ設定できます。
## ターゲットグループの正常性
デフォルトでは、ターゲットグループが少なくとも 1 つの正常なターゲットを持っている限り、そのターゲットグループは正常であると見なされます。フリートが大きい場合、トラフィックを処理する正常なターゲットが 1 つだけでは十分ではありません。代わりに、正常でなければならないターゲットの最小数または割合、および正常なターゲットが指定されたしきい値を下回ったときにロードバランサーが実行するアクションを指定できます。これはアプリケーションの可用性を向上します。
**Topics**
+ [異常な状態アクション](#unhealthy-state-actions)
+ [要件と考慮事項](#target-group-health-considerations)
+ [例](#target-group-health-examples)
+ [ロードバランサーの Route 53 DNS フェイルオーバーを使用する](#r53-dns-failover)
### 異常な状態アクション
以下のアクションに対して正常なしきい値を設定できます。
+ **DNS フェイルオーバー** – ゾーン内の正常なターゲットがしきい値を下回ると、そのゾーンのロードバランサーノードの IP アドレスが DNS で異常とマークされます。そのため、クライアントがロードバランサーの DNS 名を解決すると、トラフィックは正常なゾーンにのみルーティングされます。
+ **ルーティングフェイルオーバー** – ゾーン内の正常なターゲットがしきい値を下回ると、ロードバランサーは、異常なターゲットを含め、ロードバランサーノードで使用可能なすべてのターゲットにトラフィックを送信します。これにより、特にターゲットが一時的にヘルスチェックに合格しなかった場合に、クライアント接続が成功する可能性が高まり、正常なターゲットが過負荷になるリスクが軽減されます。
### 要件と考慮事項
+ アクションに両方のタイプのしきい値 (数と割合) を指定した場合、ロードバランサーはどちらかのしきい値を超えるとアクションを実行します。
+ 両方のアクションにしきい値を指定する場合、DNS フェイルオーバーのしきい値はルーティングフェイルオーバーのしきい値以上である必要があります。これにより、DNS フェイルオーバーはルーティングフェイルオーバーの有無にかかわらず発生します。
+ しきい値を割合として指定すると、ターゲットグループに登録されているターゲットの総数に基づいて、値が動的に計算されます。
+ ターゲットの合計数は、クロスゾーンロードバランサーがオフになっているかオンになっているかによって決まります。クロスゾーンロードバランサーがオフの場合、各ノードは独自のゾーン内のターゲットにのみトラフィックを送信します。つまり、しきい値は有効になっている各ゾーンのターゲット数に個別に適用されます。クロスゾーンロードバランサーがオンの場合、各ノードは有効なすべてのゾーンのすべてのターゲットにトラフィックを送信します。つまり、指定されたしきい値が有効になっているすべてのゾーンのターゲットの総数に適用されます。詳細については、「[クロスゾーンロードバランサー](edit-target-group-attributes.md#target-group-cross-zone)」を参照してください。
+ DNS フェイルオーバーが発生すると、ロードバランサーに関連するすべてのターゲットグループに影響します。特にクロスゾーンロードバランサーがオフになっている場合は、この追加のトラフィックを処理するのに十分な容量が残りのゾーンにあることを確認してください。
+ DNS フェイルオーバーでは、ロードバランサーの DNS ホスト名から異常のあるゾーンの IP アドレスを削除します。ただし、ローカルクライアントの DNS キャッシュには、DNS レコードの有効期限 (TTL) が期限切れになる (60 秒) まで、これらの IP アドレスが含まれる場合があります。
+ DNS フェイルオーバーでは、Network Load Balancer に複数のターゲットグループがアタッチされていて、ゾーン内で 1 つのターゲットグループが異常である場合、そのゾーン内の別のターゲットグループが正常であっても、DNS フェイルオーバーが発生します。
+ DNS フェイルオーバーでは、すべてのロードバランサーゾーンが異常と見なされると、ロードバランサーは異常なゾーンを含むすべてのゾーンにトラフィックを送信します。
+ DNS フェイルオーバーにつながる可能性のある正常なターゲットが十分にあるかどうか以外にも、ゾーンのヘルスなどの要因があります。
### 例
次の例は、ターゲットグループのヘルス設定がどのように適用されるかを示しています。
**シナリオ**
+ 2 つのアベイラビリティーゾーン A と B をサポートするロードバランサー
+ 各アベイラビリティーゾーンには 10 の登録済みターゲットが含まれています
+ ターゲットグループには、次のターゲットグループのヘルス設定があります。
+ DNS フェイルオーバー - 50%
+ ルーティングフェイルオーバー - 50%
+ アベイラビリティーゾーン B で 6 つのターゲットが失敗
![\[2 つのゾーンに対して有効になっているロードバランサー。AZ A には 10 個の正常なターゲットがあり、AZ B には 4 個の正常なターゲットと 6 個の異常なターゲットがあります。\]](http://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/images/tg-health-example.png)
**クロスゾーンロードバランサーがオフの場合**
+ 各アベイラビリティーゾーンのロードバランサーノードは、アベイラビリティーゾーンの 10 個のターゲットにのみトラフィックを送信できます。
+ アベイラビリティーゾーン A には 10 個の正常なターゲットがあり、これは正常なターゲットの必要な割合を満たしています。ロードバランサーは引き続き、10 の正常なターゲット間でトラフィックを分散します。
+ アベイラビリティーゾーン B には正常なターゲットが 4 つしかなく、これはアベイラビリティーゾーン B のロードバランサーノードのターゲットの 40% です。これは正常なターゲットの必要なパーセンテージを下回っているため、ロードバランサーは次のアクションを実行します。
+ DNS フェイルオーバー - アベイラビリティーゾーン B が DNS で異常とマークされています。クライアントはロードバランサー名をアベイラビリティーゾーン B のロードバランサーノードに解決できず、アベイラビリティーゾーン A は正常であるため、クライアントはアベイラビリティーゾーン A に新しい接続を送信します。
+ ルーティングフェイルオーバー - 新しい接続がアベイラビリティーゾーン B に明示的に送信されると、ロードバランサーは、異常なターゲットを含むアベイラビリティーゾーン B のすべてのターゲットにトラフィックを分散します。これにより、残りの正常なターゲット間でのシステム停止を防ぐことができます。
**クロスゾーンロードバランサーがオンの場合**
+ 各ロードバランサーノードは、両方のアベイラビリティーゾーンの 20 の登録済みターゲットすべてにトラフィックを送信できます。
+ アベイラビリティーゾーン A には 10 個の正常なターゲット、アベイラビリティーゾーン B には 4 個の正常なターゲット、合計 14 個の正常なターゲットがあります。これは両方のアベイラビリティーゾーンのロードバランサーノードのターゲットの 70% であり、正常なターゲットの必要な割合を満たしています。
+ ロードバランサーは、両方のアベイラビリティーゾーンの 14 個の正常なターゲット間でトラフィックを分散します。
### ロードバランサーの Route 53 DNS フェイルオーバーを使用する
Route 53 を使用して DNS クエリをロードバランサーにルーティングする場合は、同時に Route 53 によりロードバランサーの DNS フェイルオーバーを設定することもできます。フェイルオーバー設定では、ロードバランサー用のターゲットグループのターゲットに関する正常性チェックが Route 53 によって行われ、利用可能かどうかが判断されます。ロードバランサーに正常なターゲットが登録されていない場合、またはロードバランサー自体で不具合が発生している場合、Route 53 は、トラフィックを別の利用可能なリソース (正常なロードバランサーや、Amazon S3 にある静的ウェブサイトなど) にルーティングします。
例えば、`www.example.com` 用のウェブアプリケーションがあり、異なるリージョンにある 2 つのロードバランサーの背後で冗長なインスタンスを実行するとします。1 つのリージョンのロードバランサーは、主にトラフィックのルーティング先として使用し、もう 1 つのリージョンのロードバランサーは、エラー発生時のバックアップとして使用します DNS フェイルオーバーを設定する場合は、プライマリおよびセカンダリ (バックアップ) ロードバランサーを指定できます。Route 53 は、プライマリロードバランサーが利用可能な場合はプライマリロードバランサーにトラフィックをルーティングし、利用できない場合はセカンダリロードバランサーにルーティングします。
**ターゲットヘルスの評価の仕組み**
+ Network Load Balancer のエイリアスレコードで、ターゲットの正常性の評価が `Yes` に設定されていると、`alias target` 値で指定されたリソースの正常性が、Route 53 により評価されます。Route 53 はターゲットグループのヘルスチェックを使用します。
+ Network Load Balancer 内のターゲットグループがすべて正常な場合、Route 53 はそのエイリアスレコードを正常とマークします。ターゲットグループのしきい値を設定し、そのしきい値を満たすと、ヘルスチェックに合格します。あるいは、ターゲットグループが正常なターゲットを 1 つでも含んでいれば、そのターゲットグループはヘルスチェックに合格します。ヘルスチェックに合格すると、Route 53 はルーティングポリシーに従ってレコードを返します。フェイルオーバールーティングポリシーを使用すると、Route 53 はプライマリレコードを返します。
+ Network Load Balancer のターゲットグループにアタッチされたすべてのターゲットグループに異常がある場合、そのエイリアスレコードは Route 53 のヘルスチェックに失敗します (fail-open) 。ターゲットヘルスの評価を使用すると、フェイルオーバールーティングポリシーによってトラフィックがセカンダリリソースにリダイレクトされます。
+ Network Load Balancer のすべてのターゲットグループが空 (ターゲットが存在しない状態) の場合、Route 53 は対象のレコードを異常と見なします (fail-open)。ターゲットヘルスの評価を使用すると、フェイルオーバールーティングポリシーによってトラフィックがセカンダリリソースにリダイレクトされます。
詳細については、 AWS ブログの[「ロードバランサーターゲットグループのヘルスしきい値を使用して可用性を向上させる](https://aws.amazon.com/blogs/networking-and-content-delivery/using-load-balancer-target-group-health-thresholds-to-improve-availability/)」および *Amazon Route 53 デベロッパーガイド*の[「DNS フェイルオーバーの設定](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/dns-failover-configuring.html)」を参照してください。