翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# Application Load Balancer のターゲットグループ
ターゲットグループは、指定されたプロトコルとポート番号を使用して、登録済みのターゲット (EC2 インスタンスなど) ごとにリクエストをルーティングできます。1 つのターゲットを複数のターゲットグループに登録できます。ターゲットグループ単位でヘルスチェックを設定できます。ヘルスチェックは、ロードバランサーのリスナールールに指定されたターゲットグループに登録されたすべてのターゲットで実行されます。
各ターゲットグループは、1 つ以上の登録されているターゲットにリクエストをルーティングするために使用されます。各リスナーのルールを作成するときに、ターゲットグループと条件を指定します。ルールの条件が満たされると、トラフィックが該当するターゲットグループに転送されます。さまざまなタイプのリクエストに応じて別のターゲットグループを作成できます。たとえば、一般的なリクエスト用に 1 つのターゲットグループを作成し、アプリケーションのマイクロサービスへのリクエスト用に別のターゲットグループを作成できます。各ターゲットグループは 1 つのロードバランサーのみで使用できます。詳細については、「[Application Load Balancer のコンポーネント](introduction.md#application-load-balancer-components)」を参照してください。
ロードバランサーのヘルスチェック設定は、ターゲットグループ単位で定義します。各ターゲットグループはデフォルトのヘルスチェック設定を使用します。ただし、ターゲットグループを作成したときや、後で変更したときに上書きした場合を除きます。リスナーのルールでターゲットグループを指定すると、ロードバランサーは、ロードバランサーで有効なアベイラビリティーゾーンにある、ターゲットグループに登録されたすべてのターゲットの状態を継続的にモニタリングします。ロードバランサーは、正常な登録済みターゲットにリクエストをルーティングします。
**Topics**
+ [ルーティング設定](#target-group-routing-configuration)
+ [[Target type (ターゲットタイプ)]](#target-type)
+ [IP アドレスタイプ](#target-group-ip-address-type)
+ [プロトコルバージョン](#target-group-protocol-version)
+ [登録済みターゲット](#registered-targets)
+ [ターゲットオプティマイザ](#target-optimizer)
+ [ターゲットグループの属性](#target-group-attributes)
+ [ターゲットグループの正常性](#target-group-health)
+ [ターゲットグループの作成](create-target-group.md)
+ [ヘルスチェックを設定する](target-group-health-checks.md)
+ [ターゲットグループ属性を編集する](edit-target-group-attributes.md)
+ [ターゲットの登録](target-group-register-targets.md)
+ [Lambda 関数をターゲットとして 使用する](lambda-functions.md)
+ [ターゲットグループにタグを付ける](target-group-tags.md)
+ [ターゲットグループの削除](delete-target-group.md)
## ルーティング設定
デフォルトでは、ロードバランサーはターゲットグループの作成時に指定したプロトコルとポート番号を使用して、リクエストをターゲットにルーティングします。または、ターゲットグループへの登録時にターゲットへのトラフィックのルーティングに使用されるポートを上書きすることもできます。
ターゲットグループでは、次のプロトコルとポートがサポートされています。
+ **プロトコル**: HTTP、HTTPS
+ **ポート**: 1 ～ 65535
ターゲットグループが HTTPS プロトコルで設定されているか HTTPS ヘルスチェックを使用している場合に、HTTPS リスナーが TLS 1.3 セキュリティポリシーを使用すると、ターゲット接続には `ELBSecurityPolicy-TLS13-1-0-2021-06` セキュリティポリシーが使用されます。これ以外の場合には `ELBSecurityPolicy-2016-08` セキュリティポリシーが使用されます。ロードバランサーは、ターゲットにインストールする証明書を使用して、ターゲットとの TLS 接続を確立します。ロードバランサーはこれらの証明書を検証しません。したがって、自己署名証明書または期限切れの証明書を使用できます。ロードバランサーとそのターゲットは仮想プライベートクラウド (VPC) 内にあり、ロードバランサーとターゲット間のトラフィックはパケットレベルで認証されるため、ターゲットの証明書が有効でない場合でも、中間者攻撃やスプーフィングのリスクはありません。から出るトラフィック AWS にはこれらの同じ保護はなく、トラフィックをさらに保護するために追加の手順が必要になる場合があります。
## [Target type (ターゲットタイプ)]
ターゲットグループを作成するときは、そのターゲットの種類を指定します。それにより、このターゲットグループ内でターゲットを登録するときに指定するターゲットの種類が決定されます。ターゲットグループを作成した後で、ターゲットタイプを変更することはできません。
可能なターゲットの種類は次のとおりです。
`instance`
インスタンス ID で指定されたターゲット。
`ip`
ターゲットは IP アドレスです。
`lambda`
ターゲットは Lambda 関数です。
ターゲットの種類が `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 ブロックによって、次のターゲットをターゲットグループに登録できます。
+ ロードバランサー VPC (同じリージョンまたは異なるリージョン) にピアリングされている VPC 内のインスタンス。
+ AWS IP アドレスとポートでアドレス可能な リソース (データベースなど）。
+ Direct Connect または Site-to-Site VPN 接続 AWS を介して にリンクされたオンプレミスリソース。
**注記**
Local Zone 内にデプロイされた Application Load Balancer の場合、トラフィックを受信するには `ip` ターゲットが同じ Local Zone 内にある必要があります。
詳細については、[AWS 「ローカルゾーンとは」を参照してください。](https://docs.aws.amazon.com/local-zones/latest/ug/getting-started.html)
インスタンス ID を使用してターゲットを指定すると、トラフィックはインスタンスのプライマリネットワークインターフェイスで指定されたプライマリプライベート IP アドレスを使用して、インスタンスにルーティングされます。IP アドレスを使用してターゲットを指定する場合は、1 つまたは複数のネットワークインターフェイスからのプライベート IP アドレスを使用して、トラフィックをインスタンスにルーティングできます。これにより、インスタンスの複数のアプリケーションが同じポートを使用できるようになります。各ネットワークインターフェイスは独自のセキュリティグループを持つことができます。
ターゲットグループのターゲットの種類が `lambda` である場合、1 つの Lambda 関数を登録できます。ロードバランサーが Lambda 関数のリクエストを受け取ると、Lambda 関数を呼び出します。詳細については、「[Lambda 関数を Application Load Balancer のターゲットとして使用する](lambda-functions.md)」を参照してください。
Application Load Balancer のターゲットとして、Amazon Elastic Container Service (Amazon ECS) を設定できます。詳細については、「*Amazon Elastic Container Service デベロッパーガイド*」の「[Amazon ECS 用の Application Load Balancer を使用する](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/alb.html)」を参照してください。
## IP アドレスタイプ
新しいターゲットグループを作成するときは、ターゲットグループの IP アドレスタイプを選択できます。これは、ターゲットとの通信、およびそれらのヘルスステータスのチェックに使用される IP バージョンを制御します。
Application Load Balancer のターゲットグループは、次のタイプの IP アドレスをサポートしています。
**`ipv4`**
ロードバランサーは IPv4 を使用してターゲットと通信します。
**`ipv6`**
ロードバランサーは IPv6 を使用してターゲットと通信します。
**考慮事項**
+ ロードバランサーは、ターゲットグループの IP アドレスのタイプに基づいてターゲットと通信します。IPv4 ターゲットグループのターゲットはロードバランサーからの IPv4 トラフィックを受け入れる必要があり、IPv6 ターゲットグループのターゲットはロードバランサーからの IPv6 トラフィックを受け入れる必要があります。
+ `ipv4` ロードバランサーで IPv6 ターゲットグループを使用することはできません。
+ IPv6 ターゲットグループに Lambda 関数を登録できません。
## プロトコルバージョン
デフォルトでは、Application Load Balancer は HTTP/1.1 を使用してターゲットにリクエストを送信します。プロトコルバージョンを使用して、HTTP/2 または grPC を使用するターゲットにリクエストを送信できます。
次の表は、リクエストプロトコルとターゲットグループのプロトコルバージョンの組み合わせの結果をまとめたものです。
| リクエストプロトコル | プロトコルバージョン | 結果 |
| --- | --- | --- |
| HTTP/1.1 | HTTP/1.1 | 成功 |
| HTTP/2 | HTTP/1.1 | 成功 |
| gRPC | HTTP/1.1 | エラー |
| HTTP/1.1 | HTTP/2 | エラー |
| HTTP/2 | HTTP/2 | 成功 |
| gRPC | HTTP/2 | ターゲットが grPC をサポートしている場合は成功 |
| HTTP/1.1 | gRPC | エラー |
| HTTP/2 | gRPC | POST リクエストの場合は成功 |
| gRPC | gRPC | 成功 |
**gRPC プロトコルバージョンの考慮事項**
+ サポートされているリスナープロトコルは HTTPS だけです。
+ リスナールールでサポートされるアクションタイプは、`forward` のみです 。
+ サポートされているターゲットタイプは、`instance` と `ip` のみです。
+ ロードバランサーは、gRPC リクエストを解析し、パッケージ、サービス、メソッドに基づいて、適切なターゲットグループに gRPC 呼び出しをルーティングします。
+ ロードバランサーは、単項ストリーミング、クライアントサイドストリーミング、サーバーサイドストリーミング、および双方向ストリーミングをサポートします。
+ カスタムヘルスチェックメソッドには、`/package.service/method` という形式で指定する必要があります。
+ ターゲットからの正常な応答をチェックするときに使用する gRPC ステータスコードを指定する必要があります。
+ Lambda 関数をターゲットとして使用することはできません。
**HTTP/2 プロトコルバージョンの考慮事項**
+ サポートされているリスナープロトコルは HTTPS だけです。
+ リスナールールでサポートされるアクションタイプは、`forward` のみです 。
+ サポートされているターゲットタイプは、`instance` と `ip` のみです。
+ ロードバランサーは、単項ストリーミング、クライアントサイドストリーミング、サーバーサイドストリーミング、および双方向ストリーミングをサポートします。クライアント HTTP/2 接続あたりのストリームの最大数は 128 です。
## 登録済みターゲット
ロードバランサーは、クライアントにとって単一の通信先として機能し、正常な登録済みターゲットに受信トラフィックを分散します。各ターゲットは、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)」を参照してください。
**制限**
+ 同じ VPC に別の Application Load Balancer の IP アドレスを登録することはできません。もう一方の Application Load Balancer が、ロードバランサー VPC にピアリング接続されている VPC に含まれている場合は、その IP アドレスを登録できます。
+ ロードバランサー VPC (同じリージョンまたは異なるリージョン) とピア接続されている VPC にインスタンスがある場合、そのインスタンスをインスタンス ID で登録することはできません。このようなインスタンスは IP アドレスで登録できます。
## ターゲットオプティマイザ
ターゲットグループでターゲットオプティマイザを有効にできます。ターゲットオプティマイザを使用すると、ターゲットに対する同時リクエストの最大数を正確に適用できます。ターゲットにインストールして設定するエージェントの助けを借りて動作します。ターゲットオプティマイザを有効にするには、ターゲットグループのターゲットコントロールポートを指定します。このポートは、エージェントとロードバランサー間の管理トラフィックに使用されます。ターゲットオプティマイザは、ターゲットグループの作成中にのみ有効にできます。指定したターゲットコントロールポートは変更できません。詳細については、「[ターゲットオプティマイザ](target-group-register-targets.md#register-targets-target-optimizer)」を参照してください。
## ターゲットグループの属性
ターゲットグループは属性を編集することで設定できます。詳細については、「[ターゲットグループ属性を編集する](edit-target-group-attributes.md)」を参照してください。
ターゲットグループの種類が `instance` または `ip` である場合、以下のターゲットグループ属性がサポートされています。
`deregistration_delay.timeout_seconds`
ターゲットを登録解除する前に Elastic Load Balancing が待機する時間。範囲は 0 ～ 3600 秒です。デフォルト値は 300 秒です。
`load_balancing.algorithm.type`
ルーティングアルゴリズムは、リクエストをルーティングするときにロードバランサーがターゲットを選択する方法を決定します。値は `round_robin`、`least_outstanding_requests`、`weighted_random` のいずれかです。デフォルトは `round_robin` です。
`load_balancing.algorithm.anomaly_mitigation`
`load_balancing.algorithm.type` が `weighted_random` である場合のみ使用できます。異常緩和が有効になっているかどうかを示します。値は `on` または `off` です。デフォルトは `off` です。
`load_balancing.cross_zone.enabled`
クロスゾーンロードバランサーが有効かどうかを示します。値は `true`、`false` または `use_load_balancer_configuration` です。デフォルトは `use_load_balancer_configuration` です。
`slow_start.duration_seconds`
ロードバランサーが新しく登録されたターゲットに、ターゲットグループに対するトラフィックのシェアを直線的に増加させて送信する期間 (秒)。範囲は 30 ～ 900 秒 (15 分) です。デフォルトは 0 秒 (無効) です。
`stickiness.enabled`
スティッキーセッションが有効かどうかを示します。値は `true` または `false` です。デフォルトは `false` です。
`stickiness.app_cookie.cookie_name`
アプリケーション Cookie 名 アプリケーション Cookie 名に、ロードバランサーで使用するために予約されている `AWSALB`、`AWSALBAPP`、または `AWSALBTG` のプレフィックスを含めることはできません。
`stickiness.app_cookie.duration_seconds`
アプリケーションベースの Cookie の有効期間 (秒) この期間が過ぎると、Cookie は古いと見なされます。最小値は 1 秒で、最大値は 7 日間 (604800秒) です。デフォルト値は 1 日 (86400 秒) です。
`stickiness.lb_cookie.duration_seconds`
期間ベースの Cookie の有効期間 (秒) この期間が過ぎると、Cookie は古いと見なされます。最小値は 1 秒で、最大値は 7 日間 (604800秒) です。デフォルト値は 1 日 (86400 秒) です。
`stickiness.type`
維持の種類です。指定できる値は `lb_cookie` および `app_cookie` です。
`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` です。
ターゲットグループの種類が `lambda` である場合、以下のターゲット属性がサポートされています。
`lambda.multi_value_headers.enabled`
ロードバランサーと Lambda 関数との間で交換されるリクエストとレスポンスのヘッダーに、値のまたは文字列の配列が含まれるかどうかを示します。使用できる値は、`true` または `false` です。デフォルト値は `false` です。詳細については、「[複数値ヘッダー](lambda-functions.md#multi-value-headers)」を参照してください。
## ターゲットグループの正常性
デフォルトでは、ターゲットグループが少なくとも 1 つの正常なターゲットを持っている限り、そのターゲットグループは正常であると見なされます。フリートが大きい場合、トラフィックを処理する正常なターゲットが 1 つだけでは十分ではありません。代わりに、正常でなければならないターゲットの最小数または割合、および正常なターゲットが指定されたしきい値を下回ったときにロードバランサーが実行するアクションを指定できます。これはアプリケーションの可用性を向上します。
**Topics**
+ [異常な状態アクション](#unhealthy-state-actions)
+ [要件と考慮事項](#target-group-health-considerations)
+ [モニタリング](#target-group-health-monitoring)
+ [例](#target-group-health-examples)
+ [ロードバランサーの Route 53 DNS フェイルオーバーを使用する](#r53-dns-failover)
### 異常な状態アクション
以下のアクションに対して正常なしきい値を設定できます。
+ **DNS フェイルオーバー** – ゾーン内の正常なターゲットがしきい値を下回ると、そのゾーンのロードバランサーノードの IP アドレスが DNS で異常とマークされます。そのため、クライアントがロードバランサーの DNS 名を解決すると、トラフィックは正常なゾーンにのみルーティングされます。
+ **ルーティングフェイルオーバー** – ゾーン内の正常なターゲットがしきい値を下回ると、ロードバランサーは、異常なターゲットを含め、ロードバランサーノードで使用可能なすべてのターゲットにトラフィックを送信します。これにより、特にターゲットが一時的にヘルスチェックに合格しなかった場合に、クライアント接続が成功する可能性が高まり、正常なターゲットが過負荷になるリスクが軽減されます。
### 要件と考慮事項
+ ターゲットグループでターゲットオプティマイザを有効にする場合は、ターゲットグループのヘルスチェックポートを TARGET\$1CONTROL\$1DATA\$1ADDRESS のポートと同じに設定することをお勧めします。これにより、エージェントが異常である場合、ターゲットはヘルスチェックに失敗します。詳細については、「[ターゲットオプティマイザ](target-group-register-targets.md#register-targets-target-optimizer)」を参照してください。
+ ターゲットが Lambda 関数であるターゲットグループでは、この機能は使用できません。Application Load Balancer が Network Load Balancer または Global Accelerator のターゲットである場合は、DNS フェイルオーバーのしきい値を設定しないでください。
+ アクションに両方のタイプのしきい値 (数と割合) を指定すると、どちらかのしきい値に達したときにロードバランサーがアクションを実行します。
+ 両方のアクションにしきい値を指定する場合、DNS フェイルオーバーのしきい値はルーティングフェイルオーバーのしきい値以上である必要があります。これにより、DNS フェイルオーバーはルーティングフェイルオーバーの有無にかかわらず発生します。
+ しきい値を割合として指定すると、ターゲットグループに登録されているターゲットの総数に基づいて、値が動的に計算されます。
+ ターゲットの合計数は、クロスゾーンロードバランサーがオフになっているかオンになっているかによって決まります。クロスゾーンロードバランサーがオフの場合、各ノードは独自のゾーン内のターゲットにのみトラフィックを送信します。つまり、しきい値は有効になっている各ゾーンのターゲット数に個別に適用されます。クロスゾーンロードバランサーがオンの場合、各ノードは有効なすべてのゾーンのすべてのターゲットにトラフィックを送信します。つまり、指定されたしきい値が有効になっているすべてのゾーンのターゲットの総数に適用されます。詳細については、「[クロスゾーンロードバランサー](edit-target-group-attributes.md#modify-cross-zone)」を参照してください。
+ DNS フェイルオーバーが発生すると、ロードバランサーに関連するすべてのターゲットグループに影響します。特にクロスゾーンロードバランサーがオフになっている場合は、この追加のトラフィックを処理するのに十分な容量が残りのゾーンにあることを確認してください。
+ DNS フェイルオーバーでは、ロードバランサーの DNS ホスト名から異常のあるゾーンの IP アドレスを削除します。ただし、ローカルクライアントの DNS キャッシュには、DNS レコードの有効期限 (TTL) が期限切れになる (60 秒) まで、これらの IP アドレスが含まれる場合があります。
+ DNS フェイルオーバーでは、Application Load Balancer に複数のターゲットグループがアタッチされていて、ゾーン内で 1 つのターゲットグループが異常である場合、そのゾーン内で少なくとも 1 つの他のターゲットグループが正常であれば、DNS ヘルスチェックは成功します。
+ DNS フェイルオーバーでは、すべてのロードバランサーゾーンが異常と見なされると、ロードバランサーは異常なゾーンを含むすべてのゾーンにトラフィックを送信します。
+ DNS フェイルオーバーにつながる可能性のある正常なターゲットが十分にあるかどうか以外にも、ゾーンのヘルスなどの要因があります。
### モニタリング
ターゲットグループのヘルスを監視するには、「[CloudWatch metrics for target group health](load-balancer-cloudwatch-metrics.md#target-group-health-metric-table)」(ターゲットグループのヘルスの CloudWatch メトリクス) を参照してください。
### 例
次の例は、ターゲットグループのヘルス設定がどのように適用されるかを示しています。
**シナリオ**
+ 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/application/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 は、プライマリロードバランサーが利用可能な場合はプライマリロードバランサーにトラフィックをルーティングし、利用できない場合はセカンダリロードバランサーにルーティングします。
**ターゲットヘルスの評価の仕組み**
+ Application Load Balancer のエイリアスレコードでターゲットの正常性の評価が `Yes` に設定されている場合、Route 53 は `alias target` 値で指定されたリソースの正常性を評価します。Route 53 はターゲットグループのヘルスチェックを使用します。
+ Application Load Balancer にアタッチされたすべてのターゲットグループが正常である場合、Route 53 はエイリアスレコードを正常としてマークします。ターゲットグループのしきい値を設定し、そのしきい値を満たすと、ヘルスチェックに合格します。あるいは、ターゲットグループが正常なターゲットを 1 つでも含んでいれば、そのターゲットグループはヘルスチェックに合格します。ヘルスチェックに合格すると、Route 53 はルーティングポリシーに従ってレコードを返します。フェイルオーバールーティングポリシーを使用すると、Route 53 はプライマリレコードを返します。
+ Application Load Balancer にアタッチされたターゲットグループのいずれかが異常な場合、エイリアスレコードは Route 53 ヘルスチェックに失敗します (フェイルオープン)。を使用してターゲットの状態を評価する場合、フェイルオーバールーティングポリシーはトラフィックをセカンダリリソースにリダイレクトします。
+ Application Load Balancer にアタッチされたすべてのターゲットグループが空である (ターゲットがない) 場合、Route 53 はレコードが異常であるとみなします (フェイルオープン)。を使用してターゲットの状態を評価する場合、フェイルオーバールーティングポリシーはトラフィックをセカンダリリソースにリダイレクトします。
詳細については、 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)」を参照してください。