Application Load Balancer のターゲットグループ

ターゲットグループは、指定したプロトコルとポート番号を使用して、EC2インスタンスなどの個々の登録済みターゲットにリクエストをルーティングします。1 つのターゲットを複数のターゲットグループに登録できます。ターゲットグループ単位でヘルスチェックを設定できます。ヘルスチェックは、ロードバランサーのリスナールールに指定されたターゲットグループに登録されたすべてのターゲットで実行されます。

各ターゲットグループは、1 つ以上の登録されているターゲットにリクエストをルーティングするために使用されます。各リスナーのルールを作成するときに、ターゲットグループと条件を指定します。ルールの条件が満たされると、トラフィックが該当するターゲットグループに転送されます。さまざまなタイプのリクエストに応じて別のターゲットグループを作成できます。たとえば、一般的なリクエスト用に 1 つのターゲットグループを作成し、アプリケーションのマイクロサービスへのリクエスト用に別のターゲットグループを作成できます。各ターゲットグループは 1 つのロードバランサーのみで使用できます。詳細については、「Application Load Balancer のコンポーネント」を参照してください。

ロードバランサーのヘルスチェック設定は、ターゲットグループ単位で定義します。各ターゲットグループはデフォルトのヘルスチェック設定を使用します。ただし、ターゲットグループを作成したときや、後で変更したときに上書きした場合を除きます。リスナーのルールでターゲットグループを指定すると、ロードバランサーは、ロードバランサーで有効なアベイラビリティーゾーンにある、ターゲットグループに登録されたすべてのターゲットの状態を継続的にモニタリングします。ロードバランサーは、正常な登録済みターゲットにリクエストをルーティングします。

目次

• ルーティング設定
• [Target type (ターゲットタイプ)]
• IP アドレスタイプ
• プロトコルバージョン
• 登録済みターゲット
• ターゲットグループの属性
• ルーティングアルゴリズム
• ターゲットグループの正常性
• Application Load Balancer のターゲットグループを作成する
• Application Load Balancer ターゲットグループのヘルス設定を更新する
• Application Load Balancer ターゲットグループのヘルスチェック
• Application Load Balancer のターゲットグループ属性を編集する
• Application Load Balancer ターゲットグループにターゲットを登録する
• Lambda 関数を Application Load Balancer のターゲットとして使用する
• Application Load Balancer ターゲットグループのタグ
• Application Load Balancer ターゲットグループを削除する

ルーティング設定

デフォルトでは、ロードバランサーはターゲットグループの作成時に指定したプロトコルとポート番号を使用して、リクエストをターゲットにルーティングします。または、ターゲットグループへの登録時にターゲットへのトラフィックのルーティングに使用されるポートを上書きすることもできます。

ターゲットグループでは、次のプロトコルとポートがサポートされています。

• プロトコル: HTTP、 HTTPS

• ポート: 1 ～ 65535

ターゲットグループがHTTPSプロトコルで設定されているか、HTTPSヘルスチェックを使用している場合、HTTPSリスナーが TLS 1.3 セキュリティポリシーを使用している場合、ELBSecurityPolicy-TLS13-1-0-2021-06セキュリティポリシーがターゲット接続に使用されます。それ以外の場合は、ELBSecurityPolicy-2016-08セキュリティポリシーが使用されます。ロードバランサーは、ターゲットにインストールした証明書を使用して、ターゲットとTLSの接続を確立します。ロードバランサーはこれらの証明書を検証しません。したがって、自己署名証明書または期限切れの証明書を使用できます。ロードバランサーとそのターゲットは仮想プライベートクラウド (VPC) にあるため、ロードバランサーとターゲット間のトラフィックはパケットレベルで認証されるため、ターゲットの証明書が有効でなくても man-in-the-middle 攻撃やなりすましのリスクはありません。から出るトラフィック AWS にはこれらの同じ保護はありません。トラフィックをさらに保護するには、追加の手順が必要になる場合があります。

[Target type (ターゲットタイプ)]

ターゲットグループを作成するときは、そのターゲットの種類を指定します。それにより、このターゲットグループ内でターゲットを登録するときに指定するターゲットの種類が決定されます。ターゲットグループを作成した後で、ターゲットの種類を変更することはできません。

可能なターゲットの種類は次のとおりです。

instance

インスタンス ID で指定されたターゲット。

ip

ターゲットは IP アドレスです。

lambda

ターゲットは Lambda 関数です。

ターゲットタイプが の場合ip、次のいずれかのCIDRブロックから IP アドレスを指定できます。

• ターゲットグループの VPC のサブネット

• 10.0.0.0/8 (RFC1918）

• 100.64.0.0/10 (RFC 6598）

• 172.16.0.0/12 (RFC 1918)

• 192.168.0.0/16 (RFC 1918)

重要

パブリックにルーティング可能な IP アドレスは指定できません。

サポートされているすべてのCIDRブロックにより、次のターゲットをターゲットグループに登録できます。

• ロードバランサー VPC (同じリージョンまたは異なるリージョン) にVPCピアリング接続されている 内のインスタンス。

• AWS IP アドレスとポート (データベースなど) でアドレス指定できる リソース。

• AWS Direct Connect または Site-to-Site VPN接続 AWS を介して にリンクされたオンプレミスリソース。

注記

Local Zone 内にデプロイされた Application Load Balancer の場合、トラフィックを受信するには ip ターゲットが同じ Local Zone 内にある必要があります。

詳細については、AWS 「ローカルゾーンとは」を参照してください。

インスタンス ID を使用してターゲットを指定すると、トラフィックはインスタンスのプライマリネットワークインターフェイスで指定されたプライマリプライベート IP アドレスを使用して、インスタンスにルーティングされます。IP アドレスを使用してターゲットを指定する場合は、1 つまたは複数のネットワークインターフェイスからのプライベート IP アドレスを使用して、トラフィックをインスタンスにルーティングできます。これにより、インスタンスの複数のアプリケーションが同じポートを使用できるようになります。各ネットワークインターフェイスは独自のセキュリティグループを持つことができます。

ターゲットグループのターゲットの種類が lambda である場合、1 つの Lambda 関数を登録できます。ロードバランサーが Lambda 関数のリクエストを受け取ると、Lambda 関数を呼び出します。詳細については、「Lambda 関数を Application Load Balancer のターゲットとして使用する」を参照してください。

Amazon Elastic Container Service (Amazon ECS) を Application Load Balancer のターゲットとして設定できます。詳細については、「 用 Amazon Elastic Container Service ユーザーガイド」のApplication Load Balancer の作成」を参照してください。 AWS Fargate

IP アドレスタイプ

新しいターゲットグループを作成するときは、ターゲットグループの IP アドレスタイプを選択できます。これは、ターゲットとの通信、およびそれらのヘルスステータスのチェックに使用される IP バージョンを制御します。

Application Load Balancer は、 IPv4と の両方のIPv6ターゲットグループをサポートします。デフォルトの選択は IPv4 です。

考慮事項

• ターゲットグループ内のすべての IP アドレスは、同じ IP アドレスタイプである必要があります。例えば、ターゲットをIPv4ターゲットIPv6グループに登録することはできません。

• IPv6 ターゲットグループはロードdualstackバランサーでのみ使用できます。

• IPv6 ターゲットグループは、IP およびインスタンスタイプのターゲットをサポートします。

プロトコルバージョン

デフォルトでは、Application Load Balancer は HTTP/1.1 を使用してターゲットにリクエストを送信します。プロトコルバージョンを使用して、HTTP/2 または g を使用してターゲットにリクエストを送信できますRPC。

次の表は、リクエストプロトコルとターゲットグループのプロトコルバージョンの組み合わせの結果をまとめたものです。

リクエストプロトコル	プロトコルバージョン	結果
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	ターゲットが g をサポートしている場合の成功RPC
HTTP/1.1	GRPC	エラー
HTTP/2	GRPC	POST リクエストの場合の成功
GRPC	GRPC	成功

G RPCプロトコルバージョンの考慮事項

• サポートされているリスナープロトコルは のみですHTTPS。

• リスナールールでサポートされるアクションタイプは、forward のみです 。

• サポートされているターゲットタイプは、instance と ip のみです。

• ロードバランサーは gRPC リクエストを解析し、パッケージ、サービス、メソッドに基づいて gRPC 呼び出しを適切なターゲットグループにルーティングします。

• ロードバランサーは、単項ストリーミング、クライアントサイドストリーミング、サーバーサイドストリーミング、および双方向ストリーミングをサポートします。

• カスタムヘルスチェックメソッドには、/package.service/method という形式で指定する必要があります。

• ターゲットからの正常なレスポンスを確認するときに使用する gRPC ステータスコードを指定する必要があります。

• Lambda 関数をターゲットとして使用することはできません。

HTTP/2 プロトコルバージョンの考慮事項

• サポートされているリスナープロトコルは のみですHTTPS。

• リスナールールでサポートされるアクションタイプは、forward のみです 。

• サポートされているターゲットタイプは、instance と ip のみです。

• ロードバランサーは、クライアントからのストリーミングをサポートします。ロードバランサーは、ターゲットへのストリーミングをサポートしていません。

登録済みターゲット

ロードバランサーは、クライアントにとって単一の通信先として機能し、正常な登録済みターゲットに受信トラフィックを分散します。各ターゲットは、1 つ以上のターゲットグループに登録できます。

アプリケーションの需要が高まった場合、需要に対処するため、1 つまたは複数のターゲット グループに追加のターゲットを登録できます。ロードバランサーは、登録プロセスが完了し、設定されたしきい値に関係なく、ターゲットが最初の最初のヘルスチェックに合格するとすぐに、新しく登録されたターゲットへのトラフィックのルーティングを開始します。

アプリケーションの需要が低下した場合や、ターゲットを保守する必要がある場合、ターゲットグループからターゲットを登録解除することができます。ターゲットを登録解除するとターゲットグループから削除されますが、ターゲットにそれ以外の影響は及びません。登録解除するとすぐに、ロードバランサーはターゲットへのリクエストのルーティングを停止します。ターゲットは、未処理のリクエストが完了するまで draining 状態になります。リクエストの受信を再開する準備ができると、ターゲットをターゲットグループに再度登録することができます。

インスタンス ID でターゲットを登録する場合は、Auto Scaling グループでロードバランサーを使用できます。Auto Scaling グループにターゲットグループをアタッチすると、ターゲットの起動時に Auto Scaling によりターゲットグループにターゲットが登録されます。詳細については、「Amazon Auto Scaling ユーザーガイド」の「Auto Scaling グループにロードバランサーをアタッチする」を参照してください。 EC2 Auto Scaling

制限

• 別の Application Load Balancer の IP アドレスを同じ に登録することはできませんVPC。他の Application Load Balancer がロードバランサー にVPCピアリング接続されている にある場合はVPC、その IP アドレスを登録できます。

• ロードバランサー VPC (同じリージョンまたは異なるリージョン) にピアリング接続されている にある場合、インスタンス ID VPC でインスタンスを登録することはできません。このようなインスタンスは IP アドレスで登録できます。

ターゲットグループの属性

ターゲットグループの種類が 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 から最大ターゲット数までの整数です。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 です。詳細については、「複数値ヘッダー」を参照してください。

ルーティングアルゴリズム

ルーティングアルゴリズムは、リクエストを受信するターゲットを決定するときにロードバランサーが使用する方法です。ラウンドロビンルーティングアルゴリズムは、ターゲットグループレベルでリクエストをルーティングするためにデフォルトで使用されます。最小未処理のリクエストと加重ランダムルーティングアルゴリズムも、アプリケーションのニーズに基づいて利用できます。ターゲットグループには、一度に 1 つのアクティブなルーティングアルゴリズムしか使用できませんが、必要に応じてルーティングアルゴリズムを更新できます。

スティッキーセッションを有効にすると、選択したルーティングアルゴリズムが最初のターゲット選択に使用されます。同じクライアントからの今後のリクエストは、選択したルーティングアルゴリズムをバイパスして、同じターゲットに転送されます。

ラウンドロビン

• ラウンドロビンルーティングアルゴリズムは、ターゲットグループ内の正常なターゲット間でリクエストを順番に均等にルーティングします。

• このアルゴリズムは、受信されるリクエストが複雑さが類似している場合、登録されたターゲットの処理能力が類似している場合、またはターゲット間でリクエストを均等に分散する必要がある場合によく使用されます。

最小の未処理のリクエスト

• 最小未処理のリクエストルーティングアルゴリズムは、進行中のリクエストの数が最も少ないターゲットにリクエストをルーティングします。

• このアルゴリズムは、受信されるリクエストの複雑さが異なり、登録されたターゲットの処理能力が変わる場合に一般的に使用されます。

• HTTP/2 をサポートするロードバランサーが HTTP/1.1 のみをサポートするターゲットを使用している場合、リクエストは複数の HTTP/1.1 リクエストに変換されます。この設定では、最小未処理のリクエストアルゴリズムは、各 HTTP/2 リクエストを複数のリクエストとして扱います。

• を使用する場合 WebSockets、ターゲットは最小未処理のリクエストアルゴリズムを使用して選択されます。選択すると、ロードバランサーはターゲットへの接続を作成し、この接続を介してすべてのメッセージを送信します。

• 最小未処理のリクエストルーティングアルゴリズムは、スロースタートモードでは使用できません。

重み付きランダム

• 加重ランダムルーティングアルゴリズムは、ターゲットグループ内の正常なターゲット間でリクエストをランダムな順序で均等にルーティングします。

• このアルゴリズムは、自動ターゲット重み (ATW) 異常緩和をサポートします。

• 加重ランダムルーティングアルゴリズムは、スロースタートモードでは使用できません。

ターゲットグループのルーティングアルゴリズムを変更する

ターゲットグループのルーティングアルゴリズムはいつでも変更できます。

新しいコンソールを使用してルーティングアルゴリズムを変更するには

1. で Amazon EC2コンソールを開きますhttps://console.aws.amazon.com/ec2/。

2. ナビゲーションペインの [ Load Balancing (ロードバランシング) ] で [ Target Groups (ターゲットグループ) ] を選択します。

3. ターゲットグループの名前を選択して、その詳細ページを開きます。

4. ターゲットグループの詳細ページの属性タブで、編集 を選択します。

5. 「ターゲットグループ属性の編集」ページの「トラフィック設定」セクションの「負荷分散アルゴリズム」で、「ラウンドロビン」、「最小未処理リクエスト」、または「重み付きランダム」を選択します。

6. [Save changes] (変更の保存) をクリックします。

を使用してルーティングアルゴリズムを変更するには AWS CLI

load_balancing.algorithm.type 属性で modify-target-group-attributes コマンドを使用します。

ターゲットグループの正常性

デフォルトでは、ターゲットグループが少なくとも 1 つの正常なターゲットを持っている限り、そのターゲットグループは正常であると見なされます。フリートが大きい場合、トラフィックを処理する正常なターゲットが 1 つだけでは十分ではありません。代わりに、正常でなければならないターゲットの最小数または割合、および正常なターゲットが指定されたしきい値を下回ったときにロードバランサーが実行するアクションを指定できます。これにより、可用性が向上します。

異常な状態アクション

以下のアクションに対して正常なしきい値を設定できます。

• DNS フェイルオーバー — ゾーン内の正常なターゲットがしきい値を下回ると、 でゾーンのロードバランサーノードの IP アドレスが異常としてマークされますDNS。したがって、クライアントがロードバランサーDNS名を解決すると、トラフィックは正常なゾーンにのみルーティングされます。

• ルーティングフェイルオーバー - ゾーン内の正常なターゲットがしきい値を下回ると、ロードバランサーは、異常なターゲットを含め、ロードバランサーノードで使用可能なすべてのターゲットにトラフィックを送信します。これにより、特にターゲットが一時的にヘルスチェックに合格しなかった場合に、クライアント接続が成功する可能性が高まり、正常なターゲットが過負荷になるリスクが軽減されます。

要件と考慮事項

• ターゲットが Lambda 関数であるターゲットグループでは、この機能は使用できません。Application Load Balancer が Network Load Balancer または Global Accelerator のターゲットである場合は、DNSフェイルオーバーのしきい値を設定しないでください。

• アクションに両方のタイプのしきい値 (数と割合) を指定すると、どちらかのしきい値に達したときにロードバランサーがアクションを実行します。

• 両方のアクションにしきい値を指定する場合、DNSフェイルオーバーのしきい値はルーティングフェイルオーバーのしきい値以上である必要があります。これにより、フェイルオーバーがルーティングDNSフェイルオーバーの または の前にフェイルオーバーが発生します。

• しきい値を割合として指定すると、ターゲットグループに登録されているターゲットの総数に基づいて、値が動的に計算されます。

• ターゲットの合計数は、クロスゾーンロードバランサーがオフになっているかオンになっているかによって決まります。クロスゾーンロードバランサーがオフの場合、各ノードは独自のゾーン内のターゲットにのみトラフィックを送信します。つまり、しきい値は有効になっている各ゾーンのターゲット数に個別に適用されます。クロスゾーン負荷分散がオンの場合、各ノードはすべての有効ゾーンのすべてのターゲットにトラフィックを送信します。つまり、指定されたしきい値はすべての有効ゾーンのターゲットの総数に適用されます。

• DNS フェイルオーバーでは、ロードバランサーのDNSホスト名から異常ゾーンの IP アドレスを削除します。ただし、DNSレコードの time-to-live （TTL) が期限切れになるまで (60 秒）、ローカルクライアントDNSキャッシュにこれらの IP アドレスが含まれる場合があります。

• DNS フェイルオーバーが発生すると、ロードバランサーに関連付けられているすべてのターゲットグループに影響します。特にクロスゾーンロードバランサーがオフになっている場合は、この追加のトラフィックを処理するのに十分な容量が残りのゾーンにあることを確認してください。

• DNS フェイルオーバーでは、すべてのロードバランサーゾーンが異常と見なされると、ロードバランサーは異常ゾーンを含むすべてのゾーンにトラフィックを送信します。

• ゾーンの正常性など、DNSフェイルオーバーにつながる可能性のある正常なターゲットが十分にあるかどうか以外の要因があります。

モニタリング

ターゲットグループのヘルスをモニタリングするには、CloudWatch 「ターゲットグループのヘルスのメトリクス」を参照してください。

例

次の例は、ターゲットグループのヘルス設定がどのように適用されるかを示しています。

シナリオ

• 2 つのアベイラビリティーゾーン A と B をサポートするロードバランサー

• 各アベイラビリティーゾーンには 10 の登録済みターゲットが含まれています

• ターゲットグループには、次のターゲットグループのヘルス設定があります。

  • DNS フェイルオーバー - 50%

  • ルーティングフェイルオーバー - 50%

• アベイラビリティーゾーン B で 6 つのターゲットが失敗

クロスゾーンロードバランサーがオフの場合

• 各アベイラビリティーゾーンのロードバランサーノードは、アベイラビリティーゾーンの 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 値で指定されたリソースの正常性を評価します。Application Load Balancer の場合、Route 53 は、ロードバランサーに関連付けられたターゲットグループのヘルスチェックを使用します。

• Application Load Balancer 内のすべてのターゲットグループが正常である場合、Route 53 はエイリアスレコードを正常としてマークします。ターゲットグループに少なくとも 1 つの正常なターゲットが含まれている場合、ターゲットグループのヘルスチェックは合格となります。その後、Route 53 は、ルーティングポリシーに従ってレコードを返します。フェイルオーバールーティングポリシーを使用すると、Route 53 はプライマリレコードを返します。

• Application Load Balancer 内のターゲットグループのいずれかが異常な場合、エイリアスレコードは Route 53 ヘルスチェックに失敗します (フェイルオープン)。ターゲットの正常性の評価を使用している場合は、フェイルオーバールーティングポリシーが失敗します。

• Application Load Balancer 内のすべてのターゲットグループが空である (ターゲットがない) 場合、Route 53 はレコードが異常であるとみなします (フェイルオープン)。ターゲットの正常性の評価を使用している場合は、フェイルオーバールーティングポリシーが失敗します。

詳細については、「Amazon Route 53 デベロッパーガイド」のDNS「フェイルオーバーの設定」を参照してください。