翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # Amazon Route 53 ヘルスチェックの作成 Amazon Route 53 ヘルスチェックでは、ウェブアプリケーション、ウェブサーバー、その他のリソースの正常性とパフォーマンスを監視します。作成した各ヘルスチェックは、次の方法のいずれかでモニタリングできます。 + ウェブサーバーなどの指定されたリソースのヘルスチェック + そのほかのヘルスチェックのステータス + Amazon CloudWatch アラームの状態 + さらに、Amazon Application Recovery Controller (ARC) を使用すると、DNS フェイルオーバーレコードを使用してルーティングコントロールのヘルスチェックをセットアップして、アプリケーションのトラフィックフェイルオーバーを管理できます。詳細については、「[Amazon Application Recovery Controller (ARC) デベロッパーガイド](https://docs.aws.amazon.com/r53recovery/latest/dg/what-is-route-53-recovery.html)」を参照してください。 ヘルスチェックの種類に関する概要については、「[Amazon Route 53 ヘルスチェックの種類 ヘルスチェックの種類](health-checks-types.md)」を参照してください。ヘルスチェックの作成の詳細については、「[ヘルスチェックの作成と更新](health-checks-creating.md)」を参照してください。 ヘルスチェックの作成後、ヘルスチェックのステータスを確認する、ステータスが変更したときに通知を受け取る、そして DNS フェイルオーバーを設定できます。 **ヘルスチェックのステータスと通知を表示する** ヘルスチェックの現在と最近のステータスをRoute 53 コンソールで表示できます。また、 AWS SDKs、、または Route 53 API のいずれかを使用して AWS Command Line Interface AWS Tools for Windows PowerShell、プログラムでヘルスチェックを使用することもできます。 ヘルスチェックのステータスが変更されたときに通知を受け取るには、各ヘルスチェックに Amazon CloudWatch アラームを設定できます。 ヘルスチェックのステータス表示と通知の受信の詳細については、「[ヘルスチェックのステータス監視と通知の受信](health-checks-monitor-view-status.md)」を参照してください。 **DNS フェイルオーバーの設定** 同じ機能を実行する複数のリソースがある場合、DNS フェイルオーバーを設定して Route 53 がトラフィックを異常なリソースから正常なリソースへとルーティングできます。例えば、2 つのウェブサーバーがあり、そのうち 1 つのウェブサーバーが異常になった場合、Route 53 はもう 1 つのウェブサーバーにトラフィックをルーティングできます。詳細については、「[DNS フェイルオーバーの設定](dns-failover-configuring.md)」を参照してください。 **Topics** + [Amazon Route 53 ヘルスチェックの種類](health-checks-types.md) + [Amazon Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md) + [ヘルスチェックの作成、更新、削除](health-checks-creating-deleting.md) + [DNS フェイルオーバーの設定](dns-failover-configuring.md) + [ヘルスチェックの名前付けとタグ付け](health-checks-tagging.md) + [Amazon Route 53 API バージョン 2012-12-12 未満でのヘルスチェックの使用](dns-failover-using-old-apis.md) # Amazon Route 53 ヘルスチェックの種類 種類の Amazon Route 53 ヘルスチェックを作成できます。 **エンドポイントをモニタリングするヘルスチェック** IP アドレスあるいはドメイン名で特定するエンドポイントをモニタリングするヘルスチェックを設定できます。指定された一定の間隔で、Route 53 は、自動リクエストをインターネット経由でアプリケーションやサーバーなどのリソースに送信して、そのリソースが到達可能、使用可能、機能中であることを確認します。オプションで、ユーザーが行ったものと同様のリクエスト (特定の URL へのウェブページのリクエストなど) を行うように、ヘルスチェックを設定できます。 **他のヘルスチェック (算出したヘルスチェック) を監視するヘルスチェック** 他のヘルスチェックの正常または異常の判断を、Route 53 が行うべきかどうかをモニタリングする、ヘルスチェックを作成できます。この方法が便利な状況のひとつが、複数のウェブサーバーなどの同じ機能を実行する複数のリソースがあるときに、最低限のリソースが正常であるかどうかに重点を置く場合です。ヘルスチェックの通知設定をせずに、各リソースにヘルスチェックを作成できます。続いて、そのほかのヘルスチェックのステータスをモニタリングするヘルスチェックを作成し、利用できるウェブリソース数が指定するしきい値を下回る場合に通知を行うように設定できます。 **CloudWatch アラームをモニタリングするヘルスチェック** Amazon DynamoDB データベースへのスロットル読み込みイベント数や正常に機能していると推測される Elastic Load Balancing ホストの数などの CloudWatch メトリクスのステータスをモニタリングする CloudWatch アラームを作成できます。アラームを作成したら、そのアラームをモニタリングする CloudWatch と同じデータストリームをモニタリングするヘルスチェックを作成できます。 耐障害性と可用性を向上させるため、Route 53 は CloudWatch アラーム が `ALARM` 状態になるまで待ちません。ヘルスチェックのステータスの正常から異常への変更は、CloudWatch アラームのデータストリームと基準に基づいて発生します。 Route 53 は、以下の機能で CloudWatch アラームをサポートしています。 + 標準解像度メトリクス。高解像度のメトリクスはサポートされていません。詳細については、*Amazon CloudWatch ユーザーガイド*の「[高解像度メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html#high-resolution-metrics)」を参照してください。 + 統計: 平均値、最小値、最大値、合計値、およびサンプル数。拡張統計はサポートされていません。 + Route 53 では、「N 個中 M 個」のアラームはサポートされていません。詳細については、*Amazon CloudWatch ユーザーガイド*の「[アラームの評価](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarm-evaluation)」を参照してください。 + ヘルスチェックは、ヘルスチェックと同じ AWS アカウントに存在する CloudWatch アラームのみをモニタリングできます。 + Route 53 は、[Metric Math](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) を使用して複数の CloudWatch メトリクスをクエリするアラームをサポートしていません。 **Amazon Application Recovery Controller (ARC) ルーティングコントローラー** ARC のヘルスチェックは、ルーティングコントロールに関連付けられ、オンまたはオフの単純切り替えになっています。フェールオーバー DNS レコードでルーティングコントロールのヘルスチェックをそれぞれ設定します。その後、ARC でルーティングコントロールを更新してトラフィックを再ルーティングし、アベイラビリティーゾーンや AWSリージョンをまたいでアプリケーションにフェイルオーバーできます。詳細については、ARC デベロッパーガイドの「[ARC でのルーティングコントロール](https://docs.aws.amazon.com/r53recovery/latest/dg/routing-control.html)」を参照してください。 # Amazon Route 53 でヘルスチェックの正常性を判断する方法 ヘルスチェックが正常かどうかを判断するために Amazon Route 53 が使用する方法は、ヘルスチェックのタイプによって異なります。 ## Route 53 がエンドポイントをモニタリングするヘルスチェックのステータスを決定する方法 Route 53 は、世界各地にヘルスチェッカーを持っています。エンドポイントをモニタリングするヘルスチェックを作成すると、ヘルスチェッカーは、エンドポイントが正常であるかどうかを判断するためにユーザーが指定するエンドポイントにリクエストの送信を開始します Route 53 で使用するロケーションを選択することや、チェックの間隔 (10 秒ごとまたは 30 秒ごと) を指定することができます。異なるデータセンターの Route 53 ヘルスチェッカーは互いに調整しないため、選択した間隔に関係なく、1 秒あたり複数のリクエストを受け取った後、数秒間はヘルスチェックを受け取らないということが生じる場合があります。 各ヘルスチェッカーは、次の 2 つの値に基づいてエンドポイントの正常性を評価します。 + 応答時間。さまざまな理由から、ヘルスチェックリクエストに対するリソースの応答が遅くなったり、応答に失敗したりすることがあります。例えば、リソースがメンテナンスのためにシャットダウンしている、分散サービス妨害 (DDoS) 攻撃にあっている、ネットワークがダウンしている、などの理由です。 + エンドポイントが、指定した連続する回数のヘルスチェックに応答するかどうか (失敗のしきい値) Route 53 はヘルスチェッカーからデータを集計し、エンドポイントが正常であるかどうかを判断します。 + 18% を超えるヘルスチェッカーがエンドポイントを正常であるとレポートした場合、Route 53 はそのエンドポイントを正常と見なします。 + 18% 以下のヘルスチェッカーがエンドポイントを正常であるとレポートした場合、Route 53 はそのエンドポイントを異常と見なします。 18% という値が選ばれたのは、複数のリージョンのヘルスチェッカーが確実にエンドポイントを正常であると見なすようにするためです。これにより、ネットワークの状態によって一部のヘルスチェックの場所からエンドポイントが分離されたというだけで、エンドポイントを異常と見なすことを回避できます。この値は、将来のリリースで変更される可能性があります。 個々のヘルスチェッカーが、エンドポイントが正常であるかどうかを判断するために使用する応答時間は、ヘルスチェックのタイプによって異なります。 + **HTTP/HTTPS ヘルスチェック** – Route 53 が、エンドポイントとの TCP 接続を 4 秒以内に確立できることが必要です。加えて、接続後 2 秒以内に、HTTP ステータスコード 2xx または 3xx でエンドポイントが応答する必要があります。 **注記** HTTPS ヘルスチェックでは SSL/TLS 証明書が検証されないため、証明書が無効または期限切れの場合でもチェックが不合格になることはありません。 + **TCP ヘルスチェック**: Route 53 が、エンドポイントとの TCP 接続を 10 秒以内に確立できることが必要です。 + **HTTP/HTTPS ヘルスチェックと文字列一致**: HTTP/HTTPS ヘルスチェックと同様に、Route 53 はエンドポイントとの TCP 接続を 4 秒以内に確立し、そのエンドポイントは接続後 2 秒以内に 2xx または 3xx の HTTP ステータスコードで応答する必要があります。 Route 53 ヘルスチェッカーは、HTTP ステータスコードを受信後、続けて 2 秒以内にエンドポイントからレスポンス本文を受信する必要があります。Route 53 は、指定された文字列をレスポンス本文から検索します。その際、検索文字列全体が、レスポンス本文の最初の 5,120 バイト内に出現している必要があります。それ以外の場合、エンドポイントはヘルスチェックで不合格となります。Route 53 コンソールを使用している場合は、**文字列の検索** フィールドに文字列を指定します。Route 53 API を使用している場合は、ヘルスチェックの作成時に、`SearchString` 要素で文字列を指定します。 エンドポイントを監視するヘルスチェック (TCP ヘルスチェックを除く) で、エンドポイントからの応答にヘッダーが含まれている場合、ヘッダーは RFC7230、Hypertext Transfer Protocol (HTTP/1.1): メッセージ構文とルーティング、[セクション 3.2、「ヘッダーフィールド」](https://tools.ietf.org/html/rfc7230#section-3.2)で定義されている形式でなければなりません。 Route 53 は、実際のステータス (正常または非正常) を決定するための十分なデータを得るまでは、新しいヘルスチェックを正常と見なします。ヘルスチェックのステータスを反転するオプションを選択した場合、Route 53 は、十分なデータを得るまでは、新しいヘルスチェックを*非正常*と見なします。 ## Route 53 が他のヘルスチェックをモニタリングするヘルスチェックのステータスを決定する方法 ヘルスチェックは、他のヘルスチェックのステータスをモニタリングできます。このタイプのヘルスチェックは、*算出したヘルスチェック*として知られています。監視を行うヘルスチェックが*親ヘルスチェック*で、監視されるヘルスチェックが*子ヘルスチェック*です。1 つの親ヘルスチェックは、最大 255 の子ヘルスチェックの状態を監視できます。以下に、監視活動の仕組みを示します。 + Route 53 は、正常であると考えられる子のヘルスチェックの数を合計します。 + Route 53 はその後、正常と見なされる親のヘルスチェックのステータスについて正常でなければならない子ヘルスチェック数と、その数を比較します。 詳細については、「[ヘルスチェックを作成または更新するときに指定する値](health-checks-creating-values.md)」の [他のヘルスチェック (算出したヘルスチェック) の監視](health-checks-creating-values.md#health-checks-creating-values-calculated) を参照してください。 Route 53 は、実際のステータス (正常または非正常) を決定するための十分なデータを得るまでは、新しいヘルスチェックを正常と見なします。ヘルスチェックのステータスを反転するオプションを選択した場合、Route 53 は、十分なデータを得るまでは、新しいヘルスチェックを*非正常*と見なします。 ## Route 53 が CloudWatch アラームをモニタリングするヘルスチェックのステータスを決定する方法 CloudWatch アラームに基づくヘルスチェックを作成した場合、Route 53 は該当するアラームの状態ではなくそのアラームのデータストリームをモニタリングします。データストリームがアラームの状態を [**OK**] と示している場合、ヘルスチェックは正常と見なされます。データストリームが状態を [**アラーム**] と示している場合、ヘルスチェックは異常と見なされます。アラームの状態を判断するための十分な情報がデータストリームから提供されない場合、ヘルスチェックのステータスは [**ヘルスチェックステータス**] の設定 (正常、異常、または最後の既知の状態) によって決まります (Route 53 API では、この設定は `InsufficientDataHealthStatus` です)。 Route 53 では、クロスアカウント CloudWatch アラームをサポートしていません。 **注記** Route 53 のヘルスチェックでは、CloudWatch アラームの状態ではなく CloudWatch のデータストリームがモニタリングされるため、 CloudWatch の [SetAlarmState](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_SetAlarmState.html) API オペレーションを使用してヘルスチェックのステータスを強制的に変更することはできません。 Route 53 は、実際のステータス (正常または非正常) を決定するための十分なデータを得るまでは、新しいヘルスチェックを正常と見なします。ヘルスチェックのステータスを反転するオプションを選択した場合、Route 53 は、十分なデータを得るまでは、新しいヘルスチェックを*非正常*と見なします。 # ヘルスチェックの作成、更新、削除 **重要** これらの手順に進む前に、レコードに関連付けられているヘルスチェックを更新または削除する場合は、「[DNS フェイルオーバーが設定されている場合のヘルスチェックの更新または削除](health-checks-updating-deleting-tasks.md)」のタスクを確認してください。 このセクションでは、Route 53 ヘルスチェックの管理に関連する以下のトピックについて説明します。 1. **ヘルスチェックの作成と更新:** + Route 53 コンソールを使用してヘルスチェックを作成および更新する方法について説明します。 + エンドポイントモニタリング、プロトコル、IP アドレス、ドメイン名、高度な設定オプションなど、ヘルスチェックを作成または更新するときに指定する必要がある値を理解します。 1. **ヘルスチェックの作成時に表示される値:** + 完全な URL や IP アドレス、ポートなど、ヘルスチェックを作成するときに Route 53 コンソールが入力内容に基づいて表示する値を確認します。 1. **CloudWatch アラーム変更のヘルスチェックの更新:** + 関連する CloudWatch アラームの設定を変更するときにヘルスチェックを更新する方法について説明します。 1. **ヘルスチェックの削除:** + Route 53 コンソールを使用してヘルスチェックを削除する手順に従います。 1. **DNS フェイルオーバーが設定されている場合のヘルスチェックの更新または削除:** + DNS レコードに関連付けられたヘルスチェックを更新または削除するときに実行する推奨タスクについて説明します。このタスクを実行することにより、適切なルーティングとフェイルオーバーの設定が保証されます。 1. **ルーターとファイアウォールのルールの設定:** + Route 53 ヘルスチェッカーからのインバウンドトラフィックを許可し、ヘルスチェックが成功するようにルーターとファイアウォールのルールを設定する方法を理解します。 このセクションの情報にしたがって、Route 53 ヘルスチェックの作成、更新、削除を効果的に行い、設定を管理して、DNS フェイルオーバーおよびルーティングポリシーとの適切な統合を確認することができます。 **Topics** + [ヘルスチェックの作成と更新](health-checks-creating.md) + [ヘルスチェックを作成または更新するときに指定する値](health-checks-creating-values.md) + [ヘルスチェックを作成すると Amazon Route 53 が表示する値](health-checks-creating-values-displayed.md) + [CloudWatch アラーム設定を変更する場合のヘルスチェックの更新 (CloudWatch アラームのみをモニタリングするヘルスチェック)](health-checks-updating-cloudwatch-alarm-settings.md) + [ヘルスチェックの無効化または有効化](health-checks-disable.md) + [ヘルスチェックの反転](health-checks-invert.md) + [ヘルスチェックの削除](health-checks-deleting.md) + [DNS フェイルオーバーが設定されている場合のヘルスチェックの更新または削除](health-checks-updating-deleting-tasks.md) + [Amazon Route 53 のヘルスチェックができるようにルーターとファイアウォールのルールを設定する](dns-failover-router-firewall-rules.md) # ヘルスチェックの作成と更新 以下の手順では、Route 53 コンソールを使用してヘルスチェックを作成したり更新したりする方法について説明します。 **注記** Route 53 のヘルスチェックコンソールを更新中です。旧コンソールは移行期間中も引き続きご使用いただけます。 お使いのコンソールのタブを選択します。 + [新しいコンソール](#health-checks-creating-new) + [旧コンソール](#health-checks-creating-old) ------ #### [ New console ] **ヘルスチェックを作成または更新するには** 1. 既にレコードに関連付けられているヘルスチェックを更新する場合は、「[DNS フェイルオーバーが設定されている場合のヘルスチェックの更新または削除](health-checks-updating-deleting-tasks.md)」で推奨されているタスクを実行します。 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで [**Health Checks (ヘルスチェック)**] を選択します。 1. 既存のヘルスチェックを更新する場合は、ヘルスチェックのリンクされた ID を選択してから、**[編集]** を選択します。 ヘルスチェックを作成する場合は、**[ヘルスチェックを作成]** を選択します。 1. 適切な値を入力します。一部の値はヘルスチェックの作成後に変更できないのでご注意ください。詳細については、[ヘルスチェックを作成または更新するときに指定する値](health-checks-creating-values.md)を参照してください。 1. [**ヘルスチェックの作成**] を選択します。 **注記** Route 53 は、実際のステータス (正常または非正常) を決定するための十分なデータを得るまでは、新しいヘルスチェックを正常と見なします。 1. 1 つまたは複数の Route 53 レコードにヘルスチェックを関連付けます。レコードの作成と更新については、「[レコードを使用する](rrsets-working-with.md)」を参照してください。 ------ #### [ Old console ] **ヘルスチェックを作成または更新するには** 1. 既にレコードに関連付けられているヘルスチェックを更新する場合は、「[DNS フェイルオーバーが設定されている場合のヘルスチェックの更新または削除](health-checks-updating-deleting-tasks.md)」で推奨されているタスクを実行します。 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで [**ヘルスチェック**] を選択します。 1. 既存のヘルスチェックを更新する場合は、目的のヘルスチェックを選択してから、[**Edit Health Check**] を選択します。 ヘルスチェックを作成する場合は、[**Create Health Check**] を選択します。各設定の詳細については、ラベルの上にマウスポインタを移動してツールヒントを表示してください。 1. 適切な値を入力します。一部の値はヘルスチェックの作成後に変更できないのでご注意ください。詳細については、[ヘルスチェックを作成または更新するときに指定する値](health-checks-creating-values.md)を参照してください。 1. **ヘルスチェックの作成** を選択します。 **注記** Route 53 は、実際のステータス (正常または非正常) を決定するための十分なデータを得るまでは、新しいヘルスチェックを正常と見なします。ヘルスチェックのステータスを反転するオプションを選択した場合、Route 53 は、十分なデータを得るまでは、新しいヘルスチェックを*非正常*と見なします。 1. 1 つまたは複数の Route 53 レコードにヘルスチェックを関連付けます。レコードの作成と更新については、「[レコードを使用する](rrsets-working-with.md)」を参照してください。 ------ # ヘルスチェックを作成または更新するときに指定する値 ヘルスチェックを作成または更新する際は、該当する値を指定します。一部の値はヘルスチェックの作成後に変更できないのでご注意ください。 **Topics** + [エンドポイントの監視](#health-checks-creating-values-endpoint) + [他のヘルスチェック (算出したヘルスチェック) の監視](#health-checks-creating-values-calculated) + [CloudWatch アラームのモニタリング](#health-checks-creating-values-cloudwatch) + [高度な設定 (「エンドポイントを監視」する場合のみ)](#health-checks-creating-values-advanced) + [ヘルスチェックが失敗した場合の通知を取得する](#health-checks-creating-values-alarm) **名前** オプション（ただし推奨）: ヘルスチェックに割り当てる名前。[**名前**] に値が指定された場合、Route 53 は、ヘルスチェックにタグを追加し、そのタグのキーに **Name** という値を割り当てたうえで、指定された値をタグの値に割り当てます。Route 53 コンソールに表示されるヘルスチェックのリストには、[**名前**] タグの値が表示されるため、個々のヘルスチェックが識別しやすくなります。 タグ付けとヘルスチェックの詳細については、「[ヘルスチェックの名前付けとタグ付け](health-checks-tagging.md)」を参照してください。 **モニタリングの対象** このヘルスチェックで、エンドポイントを監視するか、または他のヘルスチェックのステータスを監視するか。 + **エンドポイント**: Route 53 は指定したエンドポイントの状態を監視します。ドメイン名または IP アドレスとポートを指定して、エンドポイントを指定できます。 **注記** AWS エンドポイント以外の を指定すると、追加料金が適用されます。 AWS エンドポイントの定義などの詳細については、[Route 53 料金表](https://aws.amazon.com/route53/pricing/)の「ヘルスチェック」を参照してください。 + **他のヘルスチェック (計算されたヘルスチェック) のステータス**: Route 53 は、指定した他のヘルスチェックの状態に基づいてこの状態チェックが正常であるかどうかを決定します。このヘルスチェックが正常であると判断されるために必要なヘルスチェック数も指定します。 + **CloudWatch アラームのデータストリームの状態** - Route 53 は、CloudWatch アラームのデータストリームをモニタリングして、このヘルスチェックが正常かどうかを判断します。 ## エンドポイントの監視 **注記** Route 53 のヘルスチェックコンソールを更新中です。旧コンソールは移行期間中も引き続きご使用いただけます。 お使いのコンソールのタブを選択します。 + [新しいコンソール](#health-checks-creating-values-endpoint-new) + [旧コンソール](#health-checks-creating-values-endpoint-old) ------ #### [ New console ] このヘルスチェックでエンドポイントを監視する場合、以下の値を指定します。 + エンドポイントの指定 + IP アドレス + ドメイン名 **エンドポイントの指定** IP アドレスまたはドメイン名を使用してエンドポイントを指定するかどうか。 ヘルスチェックの作成後は、[**Specify endpoint by**] の値を変更できません。 **IP アドレス ([IP アドレスでエンドポイントを指定する] を選択した場合のみ)** ドロップダウンでプロトコルを選択して、テキストボックスに IP アドレス、ポート、パスを入力します。 + プロトコルは次のいずれかになります。 **HTTP**: Route 53 は TCP 接続を確立しようとします。成功した場合、 Route 53 は HTTP リクエストを送信し、2xx または 3xx の HTTP ステータスコードを待機します。 + **HTTPS**: Route 53 は TCP 接続を確立しようとします。成功した場合、Route 53 は HTTPS リクエストを送信し、2xx または 3xx の HTTP ステータスコードを待機します。 **重要** **[HTTPS]** を選択する場合は、エンドポイントが TLS v1.0、v1.1、または v1.2 をサポートする必要があります。 **プロトコル**の値に** HTTPS **を選択すると、追加料金が適用されます。詳細については、「[Route 53 料金表](https://aws.amazon.com/route53/pricing/)」を参照してください。 + **TCP**: Route 53 は TCP 接続を確立しようとします。 詳細については、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。 ヘルスチェックの作成後は、[**Protocol**] の値を変更できません。 **[IP アドレス]** では、**[IP アドレスでエンドポイントを指定する]** を選択した場合、Route 53 でヘルスチェックを実行するエンドポイントの IPv4 または IPv6 アドレスを入力できます。 エンドポイントの IP アドレスの範囲がローカル、プライベート、ルーティング範囲外、マルチキャストのいずれかに該当する場合、Route 53 は、エンドポイントの正常性をチェックできません。ヘルスチェックを作成できない IP アドレスの詳細については、以下のドキュメントを参照してください。 + [RFC 5735, Special Use IPv4 Addresses](http://tools.ietf.org/html/rfc5735) (RFC 5735、特殊用途のIPv4アドレス) + [RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space](http://tools.ietf.org/html/rfc6598) (RFC 6598、IANA-共有アドレス空間用に予約されたIPv4プレフィックス)。 + [RFC 5156, Special-Use IPv6 Addresses](https://tools.ietf.org/html/rfc5156) (RFC 5156、特殊用途のIPv6アドレス) エンドポイントが Amazon EC2 インスタンスである場合は、Elastic IP アドレス を作成して EC2 インスタンスに関連付け、Elastic IP アドレスを指定するようお勧めします。これによってインスタンスの IP アドレスが固定されます。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Elastic IP アドレス (EIP)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)」を参照してください。 Amazon EC2 インスタンスを削除する場合、EIP に関連付けられているヘルスチェックも削除してください。詳細については、「[Amazon Route 53 ヘルスチェックのベストプラクティス](best-practices-healthchecks.md)」を参照してください。 AWS エンドポイント以外の を指定すると、追加料金が適用されます。 AWS エンドポイントの定義などの詳細については、[Route 53 料金表](https://aws.amazon.com/route53/pricing/)の「ヘルスチェック」を参照してください。 **[ポート]** では、Route 53 でヘルスチェックを実行するエンドポイントにポートを入力します。 **[パス (HTTP および HTTPS プロトコルの場合のみ)]** では、ヘルスチェックの実行時に Route 53 がリクエストするパスを入力します。エンドポイントが正常であるときに、2xx または 3xx の HTTP ステータスコードが返されるパスを指定してください (ファイル /docs/route53-health-check.html など)。クエリ文字列パラメータを含めることもできます (例: /welcome.html?language=jp&login=y)。先頭がスラッシュ文字 (/) でない場合、Route 53 はスラッシュ文字を自動的に追加します。 **ドメイン名 (すべてのプロコルで、[エンドポイントをドメイン名で指定する] を選択した場合のみ)** [**エンドポイントをドメイン名で指定する**] を選択した場合の、Route 53 でヘルスチェックを実行するエンドポイントのドメイン名 (example.com) またはサブドメイン名 (backend.example.com)。 エンドポイントをドメイン名で指定するように選択した場合、Route 53 は [**ドメイン名**] に指定したドメイン名を解決するための DNS クエリを、[**リクエスト間隔**] に指定した間隔で送信します。DNS が返す IP アドレスを使用して、Route 53 はエンドポイントの正常性を確認します。 ドメイン名で エンドポイントを指定した場合、Route 53 は、IPv4 のみを使用して、ヘルスチェックをエンドポイントに送信します。[**Domain name**] に指定した名前のタイプ A のレコードがない場合、ヘルスチェックは「DNS 解決策失敗」エラーで失敗します。 フェイルオーバー、位置情報、地理的近接性、レイテンシー、複数値、または加重のいずれかのレコードについて正常性をチェックする場合で、かつエンドポイントをドメイン名で指定した場合は、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**Domain name**] の値には、レコードの名前 (www.example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。 この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。 さらに、[**Protocol**] の値が [**HTTP**] または [**HTTPS**] である場合、前述の [**Host name**] (ホスト名) で説明したように、`Host` ヘッダーの [**Domain name**] (ドメイン名) の値が Route 53 から渡されます。[**Protocol**] の値が [**TCP**] である場合、Route 53 は `Host` ヘッダーを渡しません。 AWS エンドポイント以外の を指定すると、追加料金が適用されます。 AWS エンドポイントの定義などの詳細については、[Route 53 料金表](https://aws.amazon.com/route53/pricing/)の「ヘルスチェック」を参照してください。 ------ #### [ Old console ] このヘルスチェックでエンドポイントを監視する場合、以下の値を指定します。 + エンドポイントの指定 + プロトコル + IP アドレス + ホスト名 + ポート + ドメイン名 + パス **エンドポイントの指定** IP アドレスまたはドメイン名を使用してエンドポイントを指定するかどうか。 ヘルスチェックの作成後は、[**Specify endpoint by**] の値を変更できません。 **プロトコル** エンドポイントの正常性をチェックする際に Route 53 が使用する方法。 + **HTTP**: Route 53 は TCP 接続を確立しようとします。成功した場合、 Route 53 は HTTP リクエストを送信し、2xx または 3xx の HTTP ステータスコードを待機します。 + **HTTPS**: Route 53 は TCP 接続を確立しようとします。成功した場合、Route 53 は HTTPS リクエストを送信し、2xx または 3xx の HTTP ステータスコードを待機します。 **重要** **[HTTPS]** を選択する場合は、エンドポイントが TLS v1.0、v1.1、または v1.2 をサポートする必要があります。 **プロトコル**の値に** HTTPS **を選択すると、追加料金が適用されます。詳細については、「[Route 53 料金表](https://aws.amazon.com/route53/pricing/)」を参照してください。 + **TCP**: Route 53 は TCP 接続を確立しようとします。 詳細については、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。 ヘルスチェックの作成後は、[**Protocol**] の値を変更できません。 **IP アドレス ([IP アドレスでエンドポイントを指定する] を選択した場合のみ)** Route 53 でヘルスチェックを実行するエンドポイントの IPv4 または IPv6 アドレス ([**IP アドレスでエンドポイントを指定する**] を選択した場合のみ)。 エンドポイントの IP アドレスの範囲がローカル、プライベート、ルーティング範囲外、マルチキャストのいずれかに該当する場合、Route 53 は、エンドポイントの正常性をチェックできません。ヘルスチェックを作成できない IP アドレスの詳細については、以下のドキュメントを参照してください。 + [RFC 5735, Special Use IPv4 Addresses](http://tools.ietf.org/html/rfc5735) (RFC 5735、特殊用途のIPv4アドレス) + [RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space](http://tools.ietf.org/html/rfc6598) (RFC 6598、IANA-共有アドレス空間用に予約されたIPv4プレフィックス)。 + [RFC 5156, Special-Use IPv6 Addresses](https://tools.ietf.org/html/rfc5156) (RFC 5156、特殊用途のIPv6アドレス) エンドポイントが Amazon EC2 インスタンスである場合は、Elastic IP アドレス を作成して EC2 インスタンスに関連付け、Elastic IP アドレスを指定するようお勧めします。これによってインスタンスの IP アドレスが固定されます。詳細については、「*Amazon EC2 ユーザーガイド*」の「[Elastic IP アドレス (EIP)](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/elastic-ip-addresses-eip.html)」を参照してください。 Amazon EC2 インスタンスを削除する場合、EIP に関連付けられているヘルスチェックも削除してください。詳細については、「[Amazon Route 53 ヘルスチェックのベストプラクティス](best-practices-healthchecks.md)」を参照してください。 AWS エンドポイント以外の を指定すると、追加料金が適用されます。 AWS エンドポイントの定義などの詳細については、[Route 53 料金表](https://aws.amazon.com/route53/pricing/)の「ヘルスチェック」を参照してください。 **ホスト名 ([IP アドレスでエンドポイントを指定する] を選択した場合で、HTTP および HTTPSの場合のみ)** HTTP/HTTPS ヘルスチェックで Route 53 から `Host` ヘッダーに渡す値。通常は、Route 53 でヘルスチェックを実行するウェブサイトの完全修飾 DNS 名を指定します。Route 53 がエンドポイントの正常性をチェックするときに、`Host` ヘッダーがどのように構築されるかを以下に示します。 + [**Protocol**] の [**Port**] と [**HTTP**] に **80** の値を指定すると、Route 53 は **ホスト名**の値を含んだ `Host` ヘッダーをエンドポイントに渡します。 + [**Protocol**] の [**Port**] と [**HTTP**] に **443** の値を指定すると、Route 53 は **ホスト名**の値を含んだ `Host` ヘッダーをエンドポイントに渡します。 + [**Protocol**] の [**Port**] と [**HTTP**] または [**HTTPS**] に 別の値を指定すると、Route 53 は *ホスト名***:***Port*の値を含んだ `Host` ヘッダーをエンドポイントに渡します。 エンドポイントを IP アドレスで指定することを選択し、**ホスト名**に値を指定しない場合、Route 53 は `Host` ヘッダーの **IP アドレス**の値を、以前の値に置き換えます。 **ポート** Route 53 でヘルスチェックを実行するエンドポイント上のポート。 **ドメイン名 (すべてのプロコルで、[エンドポイントをドメイン名で指定する] を選択した場合のみ)** [**エンドポイントをドメイン名で指定する**] を選択した場合の、Route 53 でヘルスチェックを実行するエンドポイントのドメイン名 (example.com) またはサブドメイン名 (backend.example.com)。 エンドポイントをドメイン名で指定するように選択した場合、Route 53 は [**ドメイン名**] に指定したドメイン名を解決するための DNS クエリを、[**リクエスト間隔**] に指定した間隔で送信します。DNS が返す IP アドレスを使用して、Route 53 はエンドポイントの正常性を確認します。 ドメイン名で エンドポイントを指定した場合、Route 53 は、IPv4 のみを使用して、ヘルスチェックをエンドポイントに送信します。[**Domain name**] に指定した名前のタイプ A のレコードがない場合、ヘルスチェックは「DNS 解決策失敗」エラーで失敗します。 フェイルオーバー、位置情報、地理的近接性、レイテンシー、複数値、または加重のいずれかのレコードについて正常性をチェックする場合で、かつエンドポイントをドメイン名で指定した場合は、エンドポイントごとにヘルスチェックを作成することをお勧めします。例えば、www.example.com のコンテンツを配信する各 HTTP サーバーについて、ヘルスチェックを作成します。[**Domain name**] の値には、レコードの名前 (www.example.com) ではなく、サーバーのドメイン名 (us-east-2-www.example.com など) を指定します。 この構成で、[**ドメイン名**] の値がレコードの名前と一致するヘルスチェックを作成し、それらのレコードにヘルスチェックを関連付けた場合、ヘルスチェックで予想できない結果が生じます。 さらに、[**Protocol**] の値が [**HTTP**] または [**HTTPS**] である場合、前述の [**Host name**] (ホスト名) で説明したように、`Host` ヘッダーの [**Domain name**] (ドメイン名) の値が Route 53 から渡されます。[**Protocol**] の値が [**TCP**] である場合、Route 53 は `Host` ヘッダーを渡しません。 AWS エンドポイント以外の を指定すると、追加料金が適用されます。 AWS エンドポイントの定義などの詳細については、[Route 53 料金表](https://aws.amazon.com/route53/pricing/)の「ヘルスチェック」を参照してください。 **パス (HTTP および HTTPS プロトコルの場合のみ)** ヘルスチェックの実行時に Route 53 でリクエストするパス。エンドポイントが正常であるときに、`2xx` または `3xx` の HTTP ステータスコードが返されるパスを指定してください (ファイル `/docs/route53-health-check.html` など)。クエリ文字列パラメータ (`/welcome.html?language=jp&login=y` など) を含めることもできます。先頭がスラッシュ文字 (`/`) でない場合、Route 53 はスラッシュ文字を自動的に追加します。 ------ ## 他のヘルスチェック (算出したヘルスチェック) の監視 **注記** Route 53 のヘルスチェックコンソールを更新中です。旧コンソールは移行期間中も引き続きご使用いただけます。 お使いのコンソールのタブを選択します。 + [新しいコンソール](#health-checks-creating-values-calculated-new) + [旧コンソール](#health-checks-creating-values-calculated-old) ------ #### [ New console ] このヘルスチェックで他のヘルスチェックのステータスを監視する場合、以下の値を指定します。 + 監視対象のヘルスチェック + 次の場合に正常であると報告します。 **監視対象のヘルスチェック ** Route 53 で監視するヘルスチェック。監視によりヘルスチェックの状態を判断します。 [**Health checks to monitor**] に最大 256 個のヘルスチェックを追加できます。リストからヘルスチェックを削除するには、対象のヘルスチェックの強調表示部分の右にある [**x**] を選択します。 算出したヘルスチェックを、算出したその他のヘルスチェックの状態を監視するように設定することはできません。 算出したヘルスチェックの監視対象であるヘルスチェックを無効にすると、Route 53 は無効にしたヘルスチェックを正常であるとみなした上で、算出したヘルスチェックが正常かどうかを計算します。無効にしたヘルスチェックが異常とみなされるようにするには、[**Invert health check status (ヘルスチェックのステータスの反転)**] チェックボックスをオンにします。 ** 次の場合に正常であると報告します。** このヘルスチェックが正常かどうかを判断するために、Route 53 で実行する計算 + [**選択したヘルスチェック y 個のうち少なくとも x 個が正常な場合に正常と報告する**]: Route 53 は、[**モニターするヘルスチェック**] に追加したヘルスチェックのうち指定数のヘルスチェックが正常である場合に、そのヘルスチェックが正常であると見なします。次の点に注意してください。 + [**モニターするヘルスチェック**] に指定したヘルスチェックの数より大きい数値を指定した場合、Route 53 は必ずこのヘルスチェックに不具合があると見なします。 + **0** を指定した場合、Route 53 は常にこのヘルスチェックが正常であると見なします。 + [**すべてのヘルスチェックが正常である場合に正常であると報告する (AND)**]: Route 53 は、[**モニターするヘルスチェック**] に追加したヘルスチェックがすべて正常である場合にのみ、このヘルスチェックを正常であると見なします。 + [**1 つ以上のヘルスチェックが正常な場合に正常と報告する (OR)**]: Route 53 は、[**モニターするヘルスチェック**] に追加したヘルスチェックのうち少なくとも 1 つが正常である場合に、このヘルスチェックが正常であると見なします。 ------ #### [ Old console ] このヘルスチェックで他のヘルスチェックのステータスを監視する場合、以下の値を指定します。 + 監視対象のヘルスチェック + 次の場合に正常であると報告します。 + ヘルスチェックのステータスを反転させる + Disabled ** 監視対象のヘルスチェック ** Route 53 で監視するヘルスチェック。監視によりヘルスチェックの状態を判断します。 [**Health checks to monitor**] に最大 256 個のヘルスチェックを追加できます。リストからヘルスチェックを削除するには、対象のヘルスチェックの強調表示部分の右にある [**x**] を選択します。 算出したヘルスチェックを、算出したその他のヘルスチェックの状態を監視するように設定することはできません。 算出したヘルスチェックの監視対象であるヘルスチェックを無効にすると、Route 53 は無効にしたヘルスチェックを正常であるとみなした上で、算出したヘルスチェックが正常かどうかを計算します。無効にしたヘルスチェックが異常とみなされるようにするには、[**Invert health check status (ヘルスチェックのステータスの反転)**] チェックボックスをオンにします。 ** 次の場合に正常であると報告します。** このヘルスチェックが正常かどうかを判断するために、Route 53 で実行する計算 + [**選択したヘルスチェック y 個のうち少なくとも x 個が正常な場合に正常と報告する**]: Route 53 は、[**モニターするヘルスチェック**] に追加したヘルスチェックのうち指定数のヘルスチェックが正常である場合に、そのヘルスチェックが正常であると見なします。次の点に注意してください。 + [**モニターするヘルスチェック**] に指定したヘルスチェックの数より大きい数値を指定した場合、Route 53 は必ずこのヘルスチェックに不具合があると見なします。 + **0** を指定した場合、Route 53 は常にこのヘルスチェックが正常であると見なします。 + [**すべてのヘルスチェックが正常である場合に正常であると報告する (AND)**]: Route 53 は、[**モニターするヘルスチェック**] に追加したヘルスチェックがすべて正常である場合にのみ、このヘルスチェックを正常であると見なします。 + [**1 つ以上のヘルスチェックが正常な場合に正常と報告する (OR)**]: Route 53 は、[**モニターするヘルスチェック**] に追加したヘルスチェックのうち少なくとも 1 つが正常である場合に、このヘルスチェックが正常であると見なします。 ** ヘルスチェックステータスを反転させる (古いコンソールのみ)** 新しいコンソールでヘルスチェックを反転させるには、「[ヘルスチェックの反転](health-checks-invert.md)」を参照してください。 Route 53 でヘルスチェックのステータスを反転させるかどうかを選択します。このオプションを選択した場合、Route 53 はステータスが正常であればヘルスチェックに不具合があると見なします。逆も同様です。 ** 無効 (古いコンソールのみ)** 新しいコンソールでヘルスチェックを無効にするには、「[ヘルスチェックの無効化または有効化](health-checks-disable.md)」を参照してください。 Route 53 によるヘルスチェックの実行を停止させます。ヘルスチェックを無効にすると、Route 53 は、参照するヘルスチェックのステータスの集計を停止します。 ヘルスチェックを無効にすると、Route 53 は、そのヘルスチェックのステータスを常に正常とみなすようになります。DNS フェイルオーバーを設定した場合、Route 53 はトラフィックを引き続き該当するリソースにルーティングします。リソースへのトラックのルーティングを停止させるには、ヘルスチェックを反転させます。 ヘルスチェックを無効にしても、ヘルスチェックの料金は適用されます。 ------ ## CloudWatch アラームのモニタリング **注記** Route 53 のヘルスチェックコンソールを更新中です。旧コンソールは移行期間中も引き続きご使用いただけます。 お使いのコンソールのタブを選択します。 + [新しいコンソール](#health-checks-creating-values-cloudwatch-new) + [旧コンソール](#health-checks-creating-values-cloudwatch-old) ------ #### [ New console ] このヘルスチェックで CloudWatch アラームのアラーム状態を監視する場合は、以下の値を指定します。 + CloudWatch アラーム + ヘルスチェックステータス **CloudWatch アラーム** このヘルスチェックが正常かどうかを判断するために Route 53 が使用する CloudWatch アラームを選択します。CloudWatch アラームは、ヘルスチェック AWS アカウント と同じ にある必要があります。 Route 53 は、以下の機能で CloudWatch アラームをサポートしています。 + 標準解像度メトリクス。高解像度のメトリクスはサポートされていません。詳細については、*Amazon CloudWatch ユーザーガイド *の「[高解像度メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html#high-resolution-metrics)」を参照してください。 + 統計: `Average`、`Minimum`、`Maximum`、`Sum`、および `SampleCount`。拡張統計はサポートされていません。 + Route 53 では、「N 個中 M 個」のアラームはサポートされていません。詳細については、*Amazon CloudWatch ユーザーガイド* の「[アラームの評価](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarm-evaluation)」を参照してください。 Route 53 は、[Metric Math](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) を使用して複数の CloudWatch メトリクスをクエリするアラームをサポートしていません。 アラームを作成する場合は、次の手順を実行します。 1. [**作成**] を選択します。ブラウザの新しいタブに CloudWatch コンソールが表示されます。 1. 適切な値を入力します。詳細については、*Amazon CloudWatch ユーザーガイド *の「[CloudWatch アラームの作成または編集](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ConsoleAlarms.html)」を参照してください。 1. Route 53 コンソールが表示されているブラウザタブに戻ります。 1. [**CloudWatch alarm**] の横にある更新ボタンを選択します。 1. リストから新しいアラームを選択します。 ヘルスチェックを作成したあとで CloudWatch アラームの設定を変更する場合、ヘルスチェックを更新する必要があります。詳細については、「[CloudWatch アラーム設定を変更する場合のヘルスチェックの更新 (CloudWatch アラームのみをモニタリングするヘルスチェック)CloudWatch アラーム設定を変更する場合のヘルスチェックの更新](health-checks-updating-cloudwatch-alarm-settings.md)」を参照してください。 **ヘルスチェックステータス** **CloudWatch アラーム**で選択したアラーム状態を判断するための、十分なデータが CloudWatch にない場合に、ヘルスチェックのステータス (正常、異常、または最後の既知の状態) を選択します。既知の最新ステータスを使用することを選択した場合、Route 53 は、アラームの状態を判断するための十分なデータが CloudWatch にあった最新のヘルスチェックのステータスを使用します。既知の最新ステータスがない新しいヘルスチェックの場合、ヘルスチェックのデフォルトステータスは "正常" になります。 **ヘルスチェックステータス**の値は、一時的に CloudWatch メトリクスのデータストリームを用できなかった場合の、一時的なステータスを提供します。(Route 53 は、対応するアラームの状態ではなく、CloudWatch メトリックスのデータストリームを監視します。) メトリクスが頻繁に、または長時間 (数時間以上) 使用できなくなる場合は、既知の最新ステータスを使用しないことをお勧めします。 ------ #### [ Old console ] このヘルスチェックで CloudWatch アラームのアラーム状態を監視する場合は、以下の値を指定します。 + CloudWatch アラーム + ヘルスチェックステータス + ヘルスチェックのステータスを反転させる + Disabled **CloudWatch アラーム** このヘルスチェックが正常かどうかを判断するために Route 53 が使用する CloudWatch アラームを選択します。CloudWatch アラームは、ヘルスチェック AWS アカウント と同じ にある必要があります。 Route 53 は、以下の機能で CloudWatch アラームをサポートしています。 + 標準解像度メトリクス。高解像度のメトリクスはサポートされていません。詳細については、*Amazon CloudWatch ユーザーガイド *の「[高解像度メトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/publishingMetrics.html#high-resolution-metrics)」を参照してください。 + 統計: `Average`、`Minimum`、`Maximum`、`Sum`、および `SampleCount`。拡張統計はサポートされていません。 + Route 53 では、「N 個中 M 個」のアラームはサポートされていません。詳細については、*Amazon CloudWatch ユーザーガイド* の「[アラームの評価](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html#alarm-evaluation)」を参照してください。 Route 53 は、[Metric Math](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/using-metric-math.html) を使用して複数の CloudWatch メトリクスをクエリするアラームをサポートしていません。 アラームを作成する場合は、次の手順を実行します。 1. [**作成**] を選択します。ブラウザの新しいタブに CloudWatch コンソールが表示されます。 1. 適切な値を入力します。詳細については、*Amazon CloudWatch ユーザーガイド *の「[CloudWatch アラームの作成または編集](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/ConsoleAlarms.html)」を参照してください。 1. Route 53 コンソールが表示されているブラウザタブに戻ります。 1. [**CloudWatch alarm**] の横にある更新ボタンを選択します。 1. リストから新しいアラームを選択します。 ヘルスチェックを作成したあとで CloudWatch アラームの設定を変更する場合、ヘルスチェックを更新する必要があります。詳細については、「[CloudWatch アラーム設定を変更する場合のヘルスチェックの更新 (CloudWatch アラームのみをモニタリングするヘルスチェック)CloudWatch アラーム設定を変更する場合のヘルスチェックの更新](health-checks-updating-cloudwatch-alarm-settings.md)」を参照してください。 **ヘルスチェックステータス** **CloudWatch アラーム**で選択したアラーム状態を判断するための、十分なデータが CloudWatch にない場合に、ヘルスチェックのステータス (正常、異常、または最後の既知の状態) を選択します。既知の最新ステータスを使用することを選択した場合、Route 53 は、アラームの状態を判断するための十分なデータが CloudWatch にあった最新のヘルスチェックのステータスを使用します。既知の最新ステータスがない新しいヘルスチェックの場合、ヘルスチェックのデフォルトステータスは "正常" になります。 **ヘルスチェックステータス**の値は、一時的に CloudWatch メトリクスのデータストリームを用できなかった場合の、一時的なステータスを提供します。(Route 53 は、対応するアラームの状態ではなく、CloudWatch メトリックスのデータストリームを監視します。) メトリクスが頻繁に、または長時間 (数時間以上) 使用できなくなる場合は、既知の最新ステータスを使用しないことをお勧めします。 **ヘルスチェックステータスを反転させる (古いコンソールのみ)** 新しいコンソールでヘルスチェックを反転させるには、「[ヘルスチェックの反転](health-checks-invert.md)」を参照してください。 Route 53 でヘルスチェックのステータスを反転させるかどうかを選択します。このオプションを選択した場合、Route 53 はステータスが正常であればヘルスチェックに不具合があると見なします。逆も同様です。 ** 無効 (古いコンソールのみ)** 新しいコンソールでヘルスチェックを無効にするには、「[ヘルスチェックの無効化または有効化](health-checks-disable.md)」を参照してください。 Route 53 によるヘルスチェックの実行を停止させます。ヘルスチェックを無効にすると、Route 53 は該当する CloudWatch メトリクスのモニタリングを停止します。 ヘルスチェックを無効にすると、Route 53 は、そのヘルスチェックのステータスを常に正常とみなすようになります。DNS フェイルオーバーを設定した場合、Route 53 はトラフィックを引き続き該当するリソースにルーティングします。リソースへのトラックのルーティングを停止させるには、ヘルスチェックを反転させます。 ヘルスチェックを無効にしても、ヘルスチェックの料金は適用されます。 ------ ## 高度な設定 (「エンドポイントを監視」する場合のみ) **注記** Route 53 のヘルスチェックコンソールを更新中です。旧コンソールは移行期間中も引き続きご使用いただけます。 + [新しいコンソール](#health-checks-creating-values-advanced-new) + [旧コンソール](#health-checks-creating-values-advanced-old) ------ #### [ New console ] + リクエストの間隔 + 失敗しきい値 + 文字列の一致 + 検索文字列 + レイテンシーグラフ + SNI の有効化 + ホスト名 **リクエストの間隔** 各 Route 53 ヘルスチェッカーがエンドポイントから応答を受け取ってから、次のヘルスチェックリクエストを送信するまでの秒数。30 秒の間隔を選択した場合、世界各地のデータセンターにあるそれぞれの Route 53 ヘルスチェッカーは、30 秒あたりに 1 つのヘルスチェックリクエストをエンドポイントに送信します。平均して、エンドポイントは約 2 秒ごとにヘルスチェックリクエストを受け取ることになります。10 秒の間隔を選択した場合、エンドポイントは 1 秒にあたりに複数のヘルスチェックリクエストを受け取ることになります。 異なるデータセンターの Route 53 ヘルスチェッカーは互いに調整しないため、選択した間隔に関係なく、1 秒あたり複数のリクエストを受け取った後、数秒間はヘルスチェックを受け取らないということが生じる場合があります。 ヘルスチェックの作成後は、[**リクエストの間隔**] の値を変更できません。 **リクエストの間隔**の値で **[高速 (10 秒)]** を選択すると、追加料金が適用されます。詳細については、「[Route 53 料金表](https://aws.amazon.com/route53/pricing/)」を参照してください。 **失敗しきい値** Route 53 がエンドポイントの最新ステータスを異常から正常または正常から異常に変更するまでに必要な、エンドポイントが連続してヘルスチェックに合格または不合格になる回数。詳細については、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。 **文字列マッチング (HTTP または HTTPS の場合のみ)** Route 53 で、HTTP または HTTPS リクエストをエンドポイントに送信、または指定文字列でレスポンス本文を検索することにより、エンドポイントの状態を判断するかどうか。[**文字列の検索**] で指定した値がレスポンス本文に含まれる場合、Route 53 は、そのエンドポイントが正常であると見なします。レスポンス本文に含まれない場合、またはエンドポイントが応答しない場合、Route 53 は、そのエンドポイントを異常と見なします。検索文字列全体が、レスポンス本文の最初の 5,120 バイト内に出現している必要があります。 ヘルスチェックの作成後は、[**String Matching**] の値を変更できません。 [**文字列マッチング**] の値で [**はい**] を選択すると、追加料金が適用されます。詳細については、「[Route 53 料金表](https://aws.amazon.com/route53/pricing/)」を参照してください。 **ヘルスチェッカーが圧縮されたレスポンスを処理する方法** エンドポイントが圧縮されたレスポンスを返す Web サーバーである場合、Route 53 ヘルスチェッカーは、ヘルスチェッカーがサポートする圧縮アルゴリズムを使用して Web サーバーがレスポンスを圧縮した場合にのみ、指定された検索文字列をチェックする前に、レスポンスを解凍します。Health チェッカーは、次の圧縮アルゴリズムをサポートしています。 + Gzip + Deflate 別のアルゴリズムを使用してレスポンスが圧縮されている場合、ヘルスチェッカーは文字列を検索する前にレスポンスを解凍できません。この場合、検索はたいていいつも失敗し、Route 53 はエンドポイントを異常と見なします。 **文字列の検索 ([文字列マッチング] が有効の場合のみ)** エンドポイントからのレスポンス本文内で Route 53 が検索する文字列 。最大長は 255 文字です。 Route 53 は、[**文字列の検索**] でレスポンス本文内を検索する場合、大文字小文字を識別します。 **レイテンシーグラフ** Route 53 で複数の AWS リージョンのヘルスチェッカーとエンドポイント間のレイテンシーを測定するかどうかを選択します。このオプションを選択した場合、CloudWatch のレイテンシーのグラフは、Route 53 コンソールの [**ヘルスチェック**] ページの [**レイテンシー**] タブに表示されます。Route 53 ヘルスチェッカーがエンドポイントに接続できない場合、Route 53 はそのエンドポイントのレイテンシーグラフを表示できません。 ヘルスチェックの作成後は、[**Latency Measurements**] の値を変更できません。 ヘルスチェッカーとエンドポイント間のレイテンシーを計測するように Route 53 を設定する場合、追加料金が適用されます。詳細については、「[Route 53 料金表](https://aws.amazon.com/route53/pricing/)」を参照してください。 **SNI の有効化 (HTTPS のみ)** TLS ネゴシエーション中に、Route 53 が `client_hello` メッセージでエンドポイントにホスト名を送信するかどうかを指定します。これにより、エンドポイントは該当する SSL/TLS 証明書で HTTPS リクエストに応答することができます。 一部のエンドポイントでは、HTTPS リクエストで client\$1hello メッセージにホスト名を含める必要があります。SNI を有効にしない場合、ヘルスチェックのステータスに失敗が表示される場合があります。エラーメッセージは、SNI 情報を含まないリクエストに応答するようにサーバーがどう設定されているかによって異なります。ヘルスチェックは、他の理由でも失敗のステータスになる場合があります。SNI が有効であるのにこのエラーが表示される場合は、エンドポイントの SSL/TLS 設定を調べて証明書が有効であることを確認します。 次の要件に注意してください。 + エンドポイントは SNI をサポートする必要があります。 + エンドポイントの SSL/TLS 証明書には、`Common Name` フィールドにドメイン名が 1 つ含まれており、`Subject Alternative Names` フィールドにいくつか含まれている場合もあります。証明書内のドメイン名のいずれかが **[ホスト名]** で指定している値と一致する必要があります。 **ヘルスチェックリージョン** Route 53 でエンドポイントの正常性をチェックする場合には、推奨リージョンでヘルスチェッカーを使用するか、お客様が指定したリージョンでヘルスチェッカーを使用するかを指定してください。 ヘルスチェックを更新して、ヘルスチェックを実行してきたリージョンを削除する場合、Route 53 は最長 1 時間そのリージョンからのチェックを実行します。こうすることで、エンドポイント (例えば、3 つのリージョンを 4 つの異なるリージョンに置き換える場合) において何らかのヘルスチェッカーが常にチェックを実行するようにできます [**Customize**] を選択した場合は、削除するリージョンの [**x**] を選択します。リージョンをリストに戻すには、リスト末尾のスペースをクリックします。3 つ以上のリージョンを指定する必要があります。 **ホスト名 ([IP アドレスでエンドポイントを指定する] を選択した場合で、HTTP および HTTPS の場合のみ)** HTTP/HTTPS ヘルスチェックで Route 53 から `Host` ヘッダーに渡す値。通常は、Route 53 でヘルスチェックを実行するウェブサイトの完全修飾 DNS 名を指定します。Route 53 がエンドポイントの正常性をチェックするときに、`Host` ヘッダーがどのように構築されるかを以下に示します。 + [**Protocol**] の [**Port**] と [**HTTP**] に **80** の値を指定すると、Route 53 は **ホスト名**の値を含んだ `Host` ヘッダーをエンドポイントに渡します。 + **[プロトコル]** の **[ポート]** と **[HTTPS]** に **443** の値を指定すると、Route 53 は **[ホスト名]** の値を含んだ `Host` ヘッダーをエンドポイントに渡します。 + [**Protocol**] の [**Port**] と [**HTTP**] または [**HTTPS**] に別の値を指定すると、Route 53 は *ホスト名***:***Port* の値を含んだ `Host` ヘッダーをエンドポイントに渡します。 エンドポイントを IP アドレスで指定することを選択し、**ホスト名**に値を指定しない場合、Route 53 は `Host` ヘッダーの **IP アドレス**の値を、以前の値に置き換えます。 ------ #### [ Old console ] エンドポイントを監視するオプションを選択した場合、以下の設定も指定できます。 + リクエストの間隔 + 失敗しきい値 + 文字列の一致 + 検索文字列 + レイテンシーグラフ + SNI の有効化 + ヘルスチェックリージョン + ヘルスチェックのステータスを反転させる + Disabled **リクエストの間隔** 各 Route 53 ヘルスチェッカーがエンドポイントから応答を受け取ってから、次のヘルスチェックリクエストを送信するまでの秒数。30 秒の間隔を選択した場合、世界各地のデータセンターにあるそれぞれの Route 53 ヘルスチェッカーは、30 秒あたりに 1 つのヘルスチェックリクエストをエンドポイントに送信します。平均して、エンドポイントは約 2 秒ごとにヘルスチェックリクエストを受け取ることになります。10 秒の間隔を選択した場合、エンドポイントは 1 秒にあたりに複数のヘルスチェックリクエストを受け取ることになります。 異なるデータセンターの Route 53 ヘルスチェッカーは互いに調整しないため、選択した間隔に関係なく、1 秒あたり複数のリクエストを受け取った後、数秒間はヘルスチェックを受け取らないということが生じる場合があります。 ヘルスチェックの作成後は、[**リクエストの間隔**] の値を変更できません。 **リクエストの間隔**の値で **[高速 (10 秒)]** を選択すると、追加料金が適用されます。詳細については、「[Route 53 料金表](https://aws.amazon.com/route53/pricing/)」を参照してください。 **失敗しきい値** Route 53 がエンドポイントの最新ステータスを異常から正常または正常から異常に変更するまでに必要な、エンドポイントが連続してヘルスチェックに合格または不合格になる回数。詳細については、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。 **文字列マッチング (HTTP または HTTPS の場合のみ)** Route 53 で、HTTP または HTTPS リクエストをエンドポイントに送信、または指定文字列でレスポンス本文を検索することにより、エンドポイントの状態を判断するかどうか。[**文字列の検索**] で指定した値がレスポンス本文に含まれる場合、Route 53 は、そのエンドポイントが正常であると見なします。レスポンス本文に含まれない場合、またはエンドポイントが応答しない場合、Route 53 は、そのエンドポイントを異常と見なします。検索文字列全体が、レスポンス本文の最初の 5,120 バイト内に出現している必要があります。 ヘルスチェックの作成後は、[**String Matching**] の値を変更できません。 [**文字列マッチング**] の値で [**はい**] を選択すると、追加料金が適用されます。詳細については、「[Route 53 料金表](https://aws.amazon.com/route53/pricing/)」を参照してください。 **ヘルスチェッカーが圧縮されたレスポンスを処理する方法** エンドポイントが圧縮されたレスポンスを返す Web サーバーである場合、Route 53 ヘルスチェッカーは、ヘルスチェッカーがサポートする圧縮アルゴリズムを使用して Web サーバーがレスポンスを圧縮した場合にのみ、指定された検索文字列をチェックする前に、レスポンスを解凍します。Health チェッカーは、次の圧縮アルゴリズムをサポートしています。 + Gzip + Deflate 別のアルゴリズムを使用してレスポンスが圧縮されている場合、ヘルスチェッカーは文字列を検索する前にレスポンスを解凍できません。この場合、検索はたいていいつも失敗し、Route 53 はエンドポイントを異常と見なします。 **文字列の検索 ([文字列マッチング] が有効の場合のみ)** エンドポイントからのレスポンス本文内で Route 53 が検索する文字列 。最大長は 255 文字です。 Route 53 は、[**文字列の検索**] でレスポンス本文内を検索する場合、大文字小文字を識別します。 **レイテンシーグラフ** Route 53 で複数の AWS リージョンのヘルスチェッカーとエンドポイント間のレイテンシーを測定するかどうかを選択します。このオプションを選択した場合、CloudWatch のレイテンシーのグラフは、Route 53 コンソールの [**ヘルスチェック**] ページの [**レイテンシー**] タブに表示されます。Route 53 ヘルスチェッカーがエンドポイントに接続できない場合、Route 53 はそのエンドポイントのレイテンシーグラフを表示できません。 ヘルスチェックの作成後は、[**Latency Measurements**] の値を変更できません。 ヘルスチェッカーとエンドポイント間のレイテンシーを計測するように Route 53 を設定する場合、追加料金が適用されます。詳細については、「[Route 53 料金表](https://aws.amazon.com/route53/pricing/)」を参照してください。 **SNI の有効化 (HTTPS のみ)** TLS ネゴシエーション中に、Route 53 が `client_hello` メッセージでエンドポイントにホスト名を送信するかどうかを指定します。これにより、エンドポイントは該当する SSL/TLS 証明書で HTTPS リクエストに応答することができます。 一部のエンドポイントでは、HTTPS リクエストで `client_hello` メッセージにホスト名を含める必要があります。SNI を有効にしない場合、ヘルスチェックのステータスに失敗が表示される場合があります。エラーメッセージは、SNI 情報を含まないリクエストに応答するようにサーバーがどう設定されているかによって異なります。ヘルスチェックは、他の理由でも失敗のステータスになる場合があります。SNI が有効であるのにこのエラーが表示される場合は、エンドポイントの SSL/TLS 設定を調べて証明書が有効であることを確認します。 次の要件に注意してください。 + エンドポイントは SNI をサポートする必要があります。 + エンドポイントの SSL/TLS 証明書には、`Common Name` フィールドにドメイン名が 1 つ含まれており、`Subject Alternative Names` フィールドにいくつか含まれている場合もあります。証明書内のドメイン名のいずれかが **[ホスト名]** で指定している値と一致する必要があります。 **ヘルスチェックリージョン** Route 53 でエンドポイントの正常性をチェックする場合には、推奨リージョンでヘルスチェッカーを使用するか、お客様が指定したリージョンでヘルスチェッカーを使用するかを指定してください。 ヘルスチェックを更新して、ヘルスチェックを実行してきたリージョンを削除する場合、Route 53 は最長 1 時間そのリージョンからのチェックを実行します。こうすることで、エンドポイント (例えば、3 つのリージョンを 4 つの異なるリージョンに置き換える場合) において何らかのヘルスチェッカーが常にチェックを実行するようにできます [**Customize**] を選択した場合は、削除するリージョンの [**x**] を選択します。リージョンをリストに戻すには、リスト末尾のスペースをクリックします。3 つ以上のリージョンを指定する必要があります。 **ヘルスチェックステータスを反転させる (古いコンソールのみ)** 新しいコンソールでヘルスチェックを反転させるには、「[ヘルスチェックの反転](health-checks-invert.md)」を参照してください。 Route 53 でヘルスチェックのステータスを反転させるかどうかを選択します。このオプションを選択した場合、Route 53 はステータスが正常であればヘルスチェックに不具合があると見なします。逆も同様です。例えば、文字列マッチングを設定していて、指定した値をエンドポイントが返した場合に、Route 53 がヘルスチェックを [*異常*] と見なすようにできます。 ** 無効 (古いコンソールのみ)** 新しいコンソールでヘルスチェックを無効にするには、「[ヘルスチェックの無効化または有効化](health-checks-disable.md)」を参照してください。 Route 53 によるヘルスチェックの実行を停止させます。ヘルスチェックを無効にすると、Route 53 は、エンドポイントとの TCP 接続確立を中断しようとします。 ヘルスチェックを無効にすると、Route 53 は、そのヘルスチェックのステータスを常に正常とみなすようになります。DNS フェイルオーバーを設定した場合、Route 53 はトラフィックを引き続き該当するリソースにルーティングします。リソースへのトラックのルーティングを停止させるには、ヘルスチェックを反転させます。 ヘルスチェックを無効にしても、ヘルスチェックの料金は適用されます。 ------ ## ヘルスチェックが失敗した場合の通知を取得する ヘルスチェックが不合格の場合、次のオプションを使用してメールでの通知を設定します。 + [Create alarm](#health-checks-creating-values-create-alarm) + [Send notification to](#health-checks-creating-values-send-notification-to) + [Topic name](#health-checks-creating-values-topic-name) + [Recipient email addresses](#health-checks-creating-values-recipient-email-addresses) **アラームの作成 (ヘルスチェックの作成時のみ)** デフォルトの CloudWatch アラームを作成するかどうかを指定します。[**はい**] を選択すると、このエンドポイントのステータスが異常に変わって、そのエンドポイントの異常状態が 1 分間続いていると Route 53 が判断した場合に、CloudWatch が Amazon SNS 通知を送信します。 ステータスが正常に戻ったときに CloudWatch が別の Amazon SNS 通知を送信するようにするには、ヘルスチェックの作成後にアラームをもう 1 つ作成します。詳細については、*Amazon CloudWatch ユーザーガイド*の「[Amazon CloudWatch アラームの作成](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AlarmThatSendsEmail.html)］を参照してください。 既存のヘルスチェックにアラームを作成する場合、または、エンドポイントが 1 分 (デフォルト値) とは異なる時間、Route 53 に異常な状態とみなされると通知を受け取る場合は、[**いいえ**] を選択し、ヘルスチェックの作成後にアラームを追加します。詳細については、「[CloudWatch を使用したヘルスチェックのモニタリング](monitoring-health-checks.md)」を参照してください。 **通知の送信先 (アラームの作成時のみ)** CloudWatch が既存または新規の Amazon SNS トピックに通知を送信するかどうかを指定します。 + [**既存の SNS トピック**]- リストからトピック名を選択します。トピックは、米国東部 (バージニア北部) リージョンにある必要があります。 + **新規 SNS トピック** - [**Topic Name (トピック名)**] にトピック名を入力し、[**受信者**］に通知を送信したい［E メールアドレス] を入力します。複数のアドレスがある場合は、カンマ (,)、セミコロン (;)、または空白で区切ります。 Route 53 は、米国東部 (バージニア北部) リージョンにトピックを作成します。 **Topic Name (新しい SNS トピックの作成時のみ) ** [** New SNS Topic**] を指定した場合、新しいトピック名を入力します。 **Recipient email addresses (新しい SNS トピックを作成する場合のみ) ** [**New SNS Topic**] を指定した場合、通知の送信先となるメールアドレスを入力します。複数ある場合は、カンマ (,)、セミコロン (;)、または空白で区切ります。 # ヘルスチェックを作成すると Amazon Route 53 が表示する値 [**Create Health Check** (ヘルスチェックの作成)] ページには、入力した値に応じて以下の値が表示されます。 **URL** ヘルスチェックを実行する際に Route 53 がリクエストを送信する完全な URL (HTTP/HTTPS ヘルスチェックの場合) または IP アドレスとポート (TCP ヘルスチェックの場合)。 **ヘルスチェックタイプ** [**Basic**] または [**Basic \$1 additional options**] (このヘルスチェックに対して指定した設定による)。追加オプションの料金については、「[Route 53 料金表](https://aws.amazon.com/route53/pricing/)」を参照してください。 # CloudWatch アラーム設定を変更する場合のヘルスチェックの更新 (CloudWatch アラームのみをモニタリングするヘルスチェック) CloudWatch アラームへのデータストリームをモニタリングする Route 53 ヘルスチェックを作成した後に CloudWatch アラームの設定を更新すると、Route 53 ではヘルスチェックのアラーム設定は自動的に更新されません。新しいアラーム設定を使用してヘルスチェックを開始するためには、ヘルスチェックを更新する必要があります。 **注記** ヘルスチェックの更新をプログラムするには、`UpdateHealthCheck` API を使用できます。`AlarmIdentifier` と `Region` の現在の値を指定するだけで、Route 53 が CloudWatch から最新の設定を取得します。詳細については、*Amazon Route 53 API リファレンス*の「[UpdateHealthCheck](https://docs.aws.amazon.com/Route53/latest/APIReference/API_UpdateHealthCheck.html)」を参照してください。 **注記** Route 53 のヘルスチェックコンソールを更新中です。旧コンソールは移行期間中も引き続きご使用いただけます。 お使いのコンソールのタブを選択します。 + [新しいコンソール](#health-checks-updating-cloudwatch-alarm-settings-new) + [旧コンソール](#health-checks-updating-cloudwatch-alarm-settings-old) ------ #### [ New console ] **新しい CloudWatch アラーム設定があるヘルスチェックを更新するには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで **[ヘルスチェック]** を選択します。 1. 更新するヘルスチェックのリンクされた ID を選択します。 1. **[編集]** を選択します。 ヘルスチェックの CloudWatch アラームが変更されたことのお知らせが表示されます。[**Details**] フィールドには、新しいアラーム設定が表示されます。 1. **[保存]** を選択します。 ------ #### [ Old console ] **新しい CloudWatch アラーム設定があるヘルスチェックを更新するには (コンソール)** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで [**Health Checks (ヘルスチェック)**] を選択します。 1. 更新するヘルスチェックのチェックボックスを選択します。 1. [**Edit health check**] を選択します。 ヘルスチェックの CloudWatch アラームが変更されたことのお知らせが表示されます。[**Details**] フィールドには、新しいアラーム設定が表示されます。 1. **[保存]** を選択します。 ------ # ヘルスチェックの無効化または有効化 ヘルスチェックを無効にすると、Route 53 がヘルスチェックを実行できなくなります。ヘルスチェックを無効にすると、Route 53 は、参照するヘルスチェックのステータスの集計を停止します。ヘルスチェックを無効にすると、Route 53 は、そのヘルスチェックのステータスを常に正常とみなすようになります。DNS フェイルオーバーを設定した場合、Route 53 はトラフィックを引き続き該当するリソースにルーティングします。リソースへのトラックのルーティングを停止させるには、**[Inverted]** (転置) の値を変更します。 **注記** Route 53 のヘルスチェックコンソールを更新中です。旧コンソールは移行期間中も引き続きご使用いただけます。 ヘルスチェックを作成または編集するときに、古いコンソールでヘルスチェックを無効または有効にすることができます。詳細については、「[ヘルスチェックを作成または更新するときに指定する値](health-checks-creating-values.md)」を参照してください。 新しいコンソールでヘルスチェックを無効にするには、次の手順を実行します。 **ヘルスチェックを無効または有効にするには (新しいコンソールのみ)** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで **[ヘルスチェック]** を選択します。 1. **[アクション]** 列で 3 つのドットを選択し、**[無効化]** または **[有効化]** を選択します。 または、有効化または無効化するヘルスチェックのリンクされた ID を選択します。 1. **[設定]** テーブルの **[ステータス]** フィールドでは、ヘルスチェックが有効か無効かを指定します。 1. ヘルスチェックを有効または無効にするには、**[無効化]** または **[有効化]** を選択します。 # ヘルスチェックの反転 ヘルスチェックを反転させた場合、Route 53 はステータスが正常であればヘルスチェックに不具合があると見なします。逆も同様です。 **注記** Route 53 のヘルスチェックコンソールを更新中です。旧コンソールは移行期間中も引き続きご使用いただけます。 ヘルスチェックを作成または編集するときに、古いコンソールでヘルスチェックを反転させることができます。詳細については、「[ヘルスチェックを作成または更新するときに指定する値](health-checks-creating-values.md)」を参照してください。 新しいコンソールでヘルスチェックを反転させるには、次の手順を実行します。 **ヘルスチェックを反転させるには (新しいコンソールのみ)** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで **[ヘルスチェック]** を選択します。 1. **[アクション]** 列で 3 つのドットを選択し、**[反転]** を選択します。 または、反転させるヘルスチェックのリンクされた ID を選択します。 1. **[設定]** テーブルの **[反転]** フィールドは、ヘルスチェックが反転されている (**[はい**]) または反転されていない (**[いいえ]**) かどうかを指定します。 1. ヘルスチェックを反転させるには **[反転]** を選択します。 反転ステータスを元に戻す場合、**[反転]** フィールドが **[はい]** の場合は、もう一度 **[反転]** を選択します。 # ヘルスチェックの削除 ヘルスチェックを無効にするには、次の手順を実行します。 **注記** を使用して AWS Cloud Map いて、インスタンスの登録時に Route 53 ヘルスチェックを作成する AWS Cloud Map ように を設定している場合、Route 53 コンソールを使用してヘルスチェックを削除することはできません。インスタンスの登録を解除すると、ヘルスチェックが自動的に削除されます。ヘルスチェックが Route 53 コンソールに表示されなくなるまでに数時間かかる場合があります。 **注記** Route 53 のヘルスチェックコンソールを更新中です。旧コンソールは移行期間中も引き続きご使用いただけます。 お使いのコンソールのタブを選択します。 + [新しいコンソール](#health-checks-deleting-new) + [旧コンソール](#health-checks-deleting-old) ------ #### [ New console ] **ヘルスチェックを削除するには** 1. レコードに関連付けられているヘルスチェックを削除する場合は、「[DNS フェイルオーバーが設定されている場合のヘルスチェックの更新または削除](health-checks-updating-deleting-tasks.md)」で推奨されているタスクを実行します。 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで **[ヘルスチェック]** を選択します。 1. 削除するヘルスチェックのリンクされた ID を選択します。 1. **[削除]** を選択します。 1. テキストボックスに **confirm** を入力し、**[削除]** を選択します。 ------ #### [ Old console ] **ヘルスチェックを削除するには (コンソール)** 1. レコードに関連付けられているヘルスチェックを削除する場合は、「[DNS フェイルオーバーが設定されている場合のヘルスチェックの更新または削除](health-checks-updating-deleting-tasks.md)」で推奨されているタスクを実行します。 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで [**Health Checks (ヘルスチェック)**] を選択します。 1. 右側のペインで、削除するヘルスチェックを選択します。 1. [**Delete Health Check**] を選択します。 1. [**Yes, Delete**] を選択して確定します。 ------ # DNS フェイルオーバーが設定されている場合のヘルスチェックの更新または削除 レコードに関連付けられているヘルスチェックを更新または削除するとき、あるいは、ヘルスチェックが関連付けられているレコードに変更を加えるときは、そうした変更が DNS クエリのルーティングや DNS フェイルオーバーの構成に及ぼす影響を考慮する必要があります。 **重要** Route 53 に、ヘルスチェックの削除を防止する機構はありません。ヘルスチェックがレコードに関連付けられていたとしても同様です。ヘルスチェックを削除したにもかかわらず、そこに関連付けられていたレコードを更新しなかった場合、以後そのヘルスチェックのステータスが予測不能となり、ステータスが変化する可能性もあります。この場合、DNS フェイルオーバー設定の DNS クエリのルーティングが影響を受けます。 既にレコードに関連付けられているヘルスチェックを更新または削除するには、次のタスクを実行するようお勧めします。 1. ヘルスチェックに関連付けられているレコードを特定します。ヘルスチェックに関連付けられているレコードを特定するには、次のいずれかを実行する必要があります。 + Route 53 コンソールを使用して各ホストゾーンのレコードを確認します。詳細については、「[レコードの一覧表示](resource-record-sets-listing.md)」を参照してください。 + 各ホストゾーンで `ListResourceRecordSets` API アクションを実行し、そのレスポンスを確認します。詳細については、*Amazon Route 53 API リファレンス*の「[ListResourceRecordSets](https://docs.aws.amazon.com/Route53/latest/APIReference/API_ListResourceRecordSets.html)」を参照してください。 1. ヘルスチェックの更新や削除、レコードの更新によって生じる動作の変化を推定します。この評価に基づいて、実際に行う変更を決めます。 詳細については、「[ヘルスチェックを省略するとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-omitting)」を参照してください。 1. ヘルスチェックおよびレコードに適宜変更を加えます。詳細については、以下のトピックを参照してください。 + [ヘルスチェックの作成と更新](health-checks-creating.md) + [レコードの編集](resource-record-sets-editing.md) 1. 今後使用しないヘルスチェックがあれば削除します。詳細については、「[ヘルスチェックの削除](health-checks-deleting.md)」を参照してください。 # Amazon Route 53 のヘルスチェックができるようにルーターとファイアウォールのルールを設定する Route 53 は、エンドポイントの正常性をチェックする際、ヘルスチェックの作成時に指定された IP アドレスおよびポートに対し、HTTP、HTTPS、TCP のいずれかのリクエストを送信します。ヘルスチェックが成功するためには、Route 53 ヘルスチェッカーが使用する IP アドレスからのインバウンドトラフィックを、ルーターとファイアウォールのルールで許可する必要があります。 Route 53 ヘルスチェッカー、Route 53 ネームサーバー、およびその他の AWS サービスの IP アドレスの現在のリストについては、「」を参照してください[Amazon Route 53 サーバーの IP アドレス範囲](route-53-ip-addresses.md)。 Amazon EC2 では、セキュリティグループがファイアウォールとして機能します。詳細については、[Amazon EC2 ユーザーガイド」の「Amazon EC2 セキュリティグループ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-network-security.html)」を参照してください。Route 53 ヘルスチェックを許可するようにセキュリティグループを設定するには、各 IP アドレス範囲からのインバウンドトラフィックを許可するか、 AWSマネージドプレフィックスリストを使用できます。 *Amazon EC2 * AWSマネージドプレフィックスリストを使用するには、セキュリティグループを変更して からのインバウンドトラフィックを許可します。ここで`com.amazonaws..route53-healthchecks`、 ` `は Amazon EC2 インスタンスまたはリソース AWS リージョン の です。Route 53 ヘルスチェックを使用して IPv6 エンドポイントをチェックしている場合は、`com.amazonaws..ipv6.route53-healthchecks` からのインバウンドトラフィックも許可する必要があります。 AWSマネージドプレフィックスリストの詳細については、*「Amazon VPC* [ユーザーガイド AWS」の「マネージドプレフィックスリストの使用](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html)」を参照してください。 **重要** 許可された IP アドレスのリストに IP アドレスを追加するときは、ヘルスチェックの作成時に指定した各 AWS リージョンの CIDR 範囲内のすべての IP アドレスとグローバル CIDR 範囲を追加します。リージョン内の 1 つの IP アドレスから送信されたヘルスチェックリクエストが表示される場合があります。ただし、この IP アドレスを、そのリージョンの別の IP アドレスにいつでも変更することができます。 現在のヘルスチェッカー IP アドレスと、古いヘルスチェッカー IP アドレスの両方が含まれていることを確認する場合は、/26 および /18 の IP アドレス範囲を、すべて許可リストに追加します。完全なリストについては、「*AWS 全般のリファレンス*」の「[AWS IP アドレス範囲](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html)」を参照してください。 AWSマネージドプレフィックスリストをインバウンドセキュリティグループに追加すると、必要な範囲がすべて自動的に追加されます。 # DNS フェイルオーバーの設定 複数の HTTP サーバー、あるいは複数のメールサーバーなど、同じ機能を実行するリソースが重複して存在する場合、それらのリソースの正常性をチェックし正常なリソースのみを使用して DNS クエリに応答するように、Amazon Route 53 を設定することができます。例えば、ウェブサイト (example.com) が、世界各地の 3 拠点のデータセンターにそれぞれ 2 台ずつ、合計 6 台のサーバーでホストされているとします。それらのサーバーの正常性をチェックし、その時点で正常なサーバーのみを使用して example.com の DNS クエリに応答するように Route 53 を設定することができます。 Route 53 では、構成が単純な場合と複雑な場合の両方で、リソースの正常性をチェックすることができます。 + シンプルな構成では、example.com のタイプ A の加重レコードのグループなど、すべてが同じ名前とタイプのレコードグループを作成します。その上で、対応するリソースの正常性をチェックするように Route 53 を設定します。Route 53 は、リソースの正常性に基づいて DNS クエリへの応答を実行します。詳細については、「[Amazon Route 53 のシンプルな構成でのヘルスチェックの動作 の単純構成におけるヘルスチェックの動作](dns-failover-simple-configs.md)」を参照してください + より複雑な構成では、複数の基準に基づいてトラフィックをルーティングするレコードのツリーを作成します。例えば、ユーザーの待ち時間が最も重要な基準である場合、レイテンシーエイリアスレコードを使用して、ベストのレイテンシーを提供するリージョンにトラフィックをルーティングすることができます。レイテンシーエイリアスレコードは、エイリアスターゲットとして各リージョンのレコードに加重されている場合があります。加重レコードは、インスタンスタイプに基づいてトラフィックを EC2 インスタンスにルーティングします。シンプルな構成の場合と同様に、Route 53 は、リソースの正常性に基づいてトラフィックをルーティングするように設定することができます。詳細については、「[Amazon Route 53 の複雑な構成でのヘルスチェックの動作複雑な構成におけるヘルスチェックの動作](dns-failover-complex-configs.md)」を参照してください **Topics** + [DNS フェイルオーバーを設定するためのタスクリスト](dns-failover-how-to.md) + [Amazon Route 53 のシンプルな構成でのヘルスチェックの動作](dns-failover-simple-configs.md) + [Amazon Route 53 の複雑な構成でのヘルスチェックの動作](dns-failover-complex-configs.md) + [ヘルスチェックが設定されている場合に Amazon Route 53 がレコードを選択する方法](health-checks-how-route-53-chooses-records.md) + [フェイルオーバー (アクティブ/アクティブとアクティブ/パッシブ) の設定](dns-failover-types.md) + [プライベートホストゾーンのフェイルオーバーの設定](dns-failover-private-hosted-zones.md) + [Amazon Route 53 でフェイルオーバーの問題を回避する方法](dns-failover-problems.md) # DNS フェイルオーバーを設定するためのタスクリスト Route 53 を使用して DNS のフェイルオーバーを設定するには、以下のタスクを実行します。 1. 全体的な設定の概略図を作成し、作成するレコードのタイプ (加重エイリアス、フェイルオーバー、レイテンシーなど) をノードごとに指定します。ツリーの上部には、ユーザーがウェブサイトやウェブアプリケーションにアクセスするために使用する example.com などのドメイン名のレコードを入れます。 概略図に表示されるレコードの種類は、設定の複雑さによって異なります。 + シンプルな構成では、概略図にエイリアスレコードは含まれません。エイリアスレコードは、別の Route 53 レコードではなく、ELB ロードバランサーなどのリソースにトラフィックを直接ルーティングします。詳細については、「[Amazon Route 53 のシンプルな構成でのヘルスチェックの動作 の単純構成におけるヘルスチェックの動作](dns-failover-simple-configs.md)」を参照してください + 複雑な構成の場合は、エイリアスレコード (加重エイリアスやフェイルオーバーエイリアスなど) と非エイリアスレコードを複数レベルのツリーで組み合わせます (「[Amazon Route 53 の複雑な構成でのヘルスチェックの動作複雑な構成におけるヘルスチェックの動作](dns-failover-complex-configs.md)」トピックの例を参照)。 **注記** 複雑なルーティング設定のレコードをすばやく簡単に作成して、レコードをヘルスチェックに関連付けるには、トラフィックフロービジュアルエディターを使用して、設定をトラフィックポリシーとして保存することができます。その後、トラフィックポリシーを、同じホストゾーンまたは複数のホストゾーンで 1 つ以上のドメイン名 (example.com など) またはサブドメイン名 (www.example.com など) に関連付けることができます。さらに、新しい設定が期待どおりに機能していない場合は、更新を元に戻すことができます。詳細については、「[DNS トラフィックのルーティングにトラフィックフローを使用する](traffic-flow.md)」を参照してください 詳細については、次のドキュメントを参照してください。 + [ルーティングポリシーの選択](routing-policy.md) + [エイリアスレコードと非エイリアスレコードの選択](resource-record-sets-choosing-alias-non-alias.md) 1. データセンターで実行されている Amazon EC2 サーバーや E メールサーバーなど、エイリアスレコードを作成できないリソースのヘルスチェックを作成します。これらのヘルスチェックは、非エイリアスレコードに関連付けます。 詳細については、「[ヘルスチェックの作成、更新、削除](health-checks-creating-deleting.md)」を参照してください 1. 必要に応じて、ヘルスチェックで指定したエンドポイントに対し、 Route 53 が定期的なリクエストを送信できるように、ルーターとファイアウォールのルールを設定します。詳細については、「[Amazon Route 53 のヘルスチェックができるようにルーターとファイアウォールのルールを設定する のヘルスチェックができるようにルーターとファイアウォールのルールを設定する](dns-failover-router-firewall-rules.md)」を参照してください 1. 概略図の中の非エイリアスレコードをすべて作成し、ステップ 2 で作成したヘルスチェックを該当するレコードに関連付けます。 エイリアスレコードを含まない設定で DNS フェイルオーバーを設定する場合、以降の作業は不要です。 1. ELB ロードバランサーや CloudFront ディストリビューションなどの AWS リソースにトラフィックをルーティングするエイリアスレコードを作成します。リソースが異常な場合に、Route 53 がツリーの別のブランチを試すようにするには、各エイリアスレコードの [**ターゲットの正常性の評価**] の値を [**Yes (あり)**] に設定してください。(**ターゲットヘルスの評価**は一部の AWS リソースではサポートされていません）。 1. ステップ 1 で作成した概略図の一番下から、ステップ 4 と 5 で作成したレコードにトラフィックをルーティングするエイリアスレコードを作成します。ツリーの 1 つのブランチの中で、非エイリアスレコードがすべて異常なときに別のブランチを試すように Route 53 を設定する場合は、各エイリアスレコードの [**ターゲットの正常性の評価**] の値を [**Yes (あり)**] に設定します。 別のレコードを作成するまで、トラフィックを別のレコードにルーティングするエイリアスレコードを作成することはできません。 # Amazon Route 53 のシンプルな構成でのヘルスチェックの動作 example.com を対象とした 2 つ以上のウェブサーバーなど、同じ機能を実行する 2 つ以上のリソースがある場合、次のヘルスチェック機能を使用して、正常なリソースにのみトラフィックをルーティングできます。 **EC2 インスタンスおよびその他のリソース (非エイリアスレコード) の正常性をチェックする** エイリアスレコードを作成できないリソース (EC2 インスタンスなど) にトラフィックをルーティングする場合は、各リソースのレコードとヘルスチェックを作成します。次に、各ヘルスチェックを該当するレコードに関連付けます。ヘルスチェックは、対応するリソースの正常性を定期的にチェックし、Route 53 は、ヘルスチェックが正常とレポートするリソースにのみトラフィックをルーティングします。 ** AWS リソース (エイリアスレコード) の正常性を評価する** [エイリアスレコード](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)を使用して ELB ロードバランサーなどの選択した AWS リソースにトラフィックをルーティングする場合は、リソースの正常性を評価し、正常なリソースにのみトラフィックをルーティングするように Route 53 を設定できます。エイリアスレコードを設定してリソースの正常性を評価する場合、リソースのヘルスチェックを作成する必要はありません。 シンプルな構成でリソースの正常性をチェックするように、Route 53 を設定する方法の概要を以下に示します。 1. どのリソースの正常性を Route 53 で監視するかを明確にします。例えば、example.com のリクエストに応答するすべての HTTP サーバーを監視対象にするとします。 1. データセンターで実行されている EC2 インスタンスやサーバーなど、エイリアスレコードを作成できないリソースのヘルスチェックを作成します。リソースにヘルスチェックリクエストを送信する方法を指定します。具体的には、使用するプロトコル (HTTP、HTTPS、TCP)、使用する IP アドレスとポート、さらに、HTTP/HTTPS ヘルスチェックの場合はドメインの名前とパスが伝えられます。 **注記** ELB ロードバランサーなどのエイリアスレコードを作成できるリソースを使用している場合は、それらのリソースのヘルスチェックを作成しないでください。 リソースごとにヘルスチェックを 1 つ作成し、ヘルスチェックのエンドポイントには、リソースと同じ IP アドレスを使用するのが一般的な構成です。ヘルスチェックは、指定された IP アドレスに要求を送信します。 **注記** Route 53 では、リソースの IP アドレスがローカル、プライベート、ルーティング範囲外、またはマルチキャストのいずれかに該当する場合、正常性をチェックすることはできません。ヘルスチェックを作成できない IP アドレスの詳細については、「[RFC 5735, Special Use IPv4 Addresses](https://datatracker.ietf.org/doc/html/rfc5735)」と「[RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space](https://datatracker.ietf.org/doc/html/rfc6598)」を参照してください。 ヘルスチェック作成の詳細については、「[ヘルスチェックの作成、更新、削除](health-checks-creating-deleting.md)」を参照してください。 1. ヘルスチェックで指定したエンドポイントに対し、Route 53 が定期的なリクエストを送信できるように、ルーターとファイアウォールのルールを設定する必要があります。詳細については、「[Amazon Route 53 のヘルスチェックができるようにルーターとファイアウォールのルールを設定する のヘルスチェックができるようにルーターとファイアウォールのルールを設定する](dns-failover-router-firewall-rules.md)」を参照してください。 1. 例えば、加重レコードのグループなど、リソースのレコードのグループを作成します。エイリアスと非エイリアスレコードを混在させることができますが、[**名前**]、[**タイプ**]、および [**ルーティングポリシー**] のすべての値が同じである必要があります。 リソースの正常性をチェックするために Route 53 を設定する方法は、エイリアスレコードを作成するか非エイリアスレコードを作成するかによって異なります。 + **エイリアスレコード** – ［**Evaluate Target Health (ターゲットの正常性の評価)**] で [**Yes (あり**)] を指定します。 + **非エイリアスレコード**– ステップ 2 で作成したヘルスチェックを、対応するレコードと関連付けます。 設定が完了したら、次の図のような設定になります。この図には、非エイリアスレコードのみが含まれています。 ![\[3 つの加重レコードおよび対応するヘルスチェック。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-weighted.png) Route 53 コンソールを使用したレコード作成の詳細については、「[Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)」を参照してください。 1. ヘルスチェックを作成した場合、Route 53 はヘルスチェックごとに定期的にエンドポイントにリクエストを送信します。つまり、DNS クエリを受信したときにヘルスチェックが実行されるわけではありません。Route 53 は、その応答に応じてエンドポイントが正常であるかどうかを判断し、その情報をもとにクエリへの応答方法を決定します。詳細については、「[Amazon Route 53 でヘルスチェックの正常性を判断する方法Route 53 でヘルスチェックの正常性を判断する方法](dns-failover-determining-health-of-endpoints.md)」を参照してください。 Route 53 によって正常性がチェックされるのは、レコードで指定されたリソース (example.com の A レコードで指定された IP アドレスなど) ではありません。レコードにヘルスチェックが関連付けられた場合、Route 53 では、ヘルスチェックで指定されたエンドポイントの正常性のチェックを開始します。また、他のヘルスチェックの正常性をモニタリングしたり、CloudWatch アラームのデータストリームをモニタリングしたりするように Route 53 を設定することもできます。詳細については、「[Amazon Route 53 ヘルスチェックの種類 ヘルスチェックの種類](health-checks-types.md)」を参照してください。 Route 53 が example.com のクエリを受信した場合の動作を以下に示します。 1. Route 53 が、ルーティングポリシーに基づいてレコードを選択します。このケースでは、重みに基づいてレコードが選択されます。 1. そのレコードのヘルスチェックのステータスをチェックして、選択されたレコードの現在の正常性を調べます。 1. 選択したレコードに異常がある場合、Route 53 は別のレコードを選択します。このとき、異常のあるレコードは候補から外されます。 詳細については、「[ヘルスチェックが設定されている場合に Amazon Route 53 がレコードを選択する方法ヘルスチェックが設定されている場合に Route 53 がレコードを選択する方法](health-checks-how-route-53-chooses-records.md)」を参照してください。 1. 正常なレコードを検出した Route 53 は、A レコードの IP アドレスなどの適切な値でクエリに応答します。 次の例は、加重レコードのグループを示しています。3 つ目のレコードに異常がみられます。まず、Route 53 は、3 つすべてのレコードの重みに基づいてレコードを選択します。最初に選択したレコードに異常が見つかると、Route 53 は別のレコードを選択します。このとき、3 つ目のレコードの重みは計算から除外されます。 + 初めに Route 53 が 3 つすべてのレコードからの選択を行った際に、1 つ目のレコードがリクエストへの応答に使用される時間は全体の 20% (= 10/(10 \$1 20 \$1 20)) となります。 + Route 53 により、3 つ目のレコードに異常が発見された場合、1 つ目のレコードがリクエストへの応答に使用される時間は、全体の 33% (=10/(10 \$1 20)) となります。 ![\[3 つの加重レコードおよび対応するヘルスチェック。3 番目のヘルスチェックが異常であるため、Route 53 は関連するレコードが異常であると見なします。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-weighted-failed-hc.png) レコードグループ内の 1 つ以上のレコードからヘルスチェックを省略すると、Route 53 には対応するリソースの正常性を判断する方法がなくなります。Route 53 は、それらのレコードを正常と見なします。 ![\[3 つの加重レコード (ヘルスチェックが関連付けられているのは 2 つだけ) Route 53 は、常に 3 番目のレコードが正常であると見なします。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-weighted-missing-health-check.png) # Amazon Route 53 の複雑な構成でのヘルスチェックの動作 複雑な構成であっても、リソースの正常性をチェックする方法は同じです。ただし、複雑な構成では、エイリアスレコード (加重エイリアスやフェイルオーバーエイリアスなど) と非エイリアスレコードを組み合わせてデシジョンツリーを構築し、リクエストに対する Route 53 の応答を柔軟に制御することができます。 例えば、レイテンシーエイリアスレコードを使用して、ユーザーに近いリージョンを選択することが考えられます。また、各リージョン内の複数のリソースに加重レコードを使用して、単一エンドポイントやアベイラビリティーゾーンの障害への対策を講じることも可能です。この設定は以下の図のようになります。 ![\[レイテンシーエイリアスレコードおよび加重エイリアスレコードを含む DNS 設定。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted.png) Amazon EC2 と Route 53 の設定方法は次のとおりです。ツリーの一番下から始めましょう。これはレコードを作成する順序です。 + us-east-1 と ap-southeast-2 という 2 つのリージョンのそれぞれに、2 つの EC2; インスタンスが存在します。EC2 インスタンスが正常であるかどうかを判断して、Route 53 がトラフィックをルーティングするように、各インスタンスのヘルスチェックを作成します。各ヘルスチェックを設定して、インスタンスの Elastic IP アドレスで対応するインスタンスにヘルスチェックリクエストを送信します。 Route 53 はグローバルサービスであるため、ヘルスチェックを作成するリージョンは指定しないでください。 + インスタンスタイプに基づいて各リージョンの 2 つのインスタンスにトラフィックをルーティングするため、各インスタンスに加重レコードを作成し、各レコードに重みを付与します。(後で加重を変更して、より多くのトラフィックを、またはより少ないトラフィックをインスタンスにルーティングできます。) また、該当するヘルスチェックを各インスタンスに関連付けます。 レコードを作成するとき、us-east-1-www.example.com. や ap-southeast-2-www.example.com. などの名前を使用します。ツリーの一番上に到達するまで待って、ユーザーがウェブサイトやウェブアプリケーションにアクセスするために使用する名前 (example.com など) をレコードに渡します。 + ユーザーのレイテンシーが最も短いリージョンにトラフィックをルーティングする場合は、ツリー上部のレコードのレイテンシーの[ルーティングポリシー](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html)を選択します。 トラフィックを各リージョンの*リソース*に直接ルーティングするのではなく、各リージョンの*レコード*にルーティンしたいとします（加重レコードはすでにしています）。その結果、レイテンシーの[エイリアスレコード](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)を作成することになります。 エイリアスレコードを作成するときに、ユーザーがウェブサイトやウェブアプリケーションにアクセスするために使用する名前 (example.com など) を指定します。エイリアスレコードは、example.com のトラフィックを us-east-1-www.example.com と ap-southeast-2-www.example.com のレコードにルーティングします。 レイテンシーエイリアスレコードの [**Evaluate Target Health**] の値は、どちらも [**Yes**] に設定します。これにより Route 53 は、リージョンにトラフィックをルーティングしようとする前に、そこに正常なリソースがあるかどうかを判断します。正常なリソースがない場合、Route 53 は、他のリージョンから正常なリソースを選択します。 ![\[レイテンシーエイリアスレコードおよび加重エイリアスレコードを含む DNS 設定。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-both-failed.png) 前の図は、以下の一連のイベントを示したものです。 1. Route 53 が example.com のクエリを受信します。要求元のユーザーに対するレイテンシーに基づいて、Route 53 は us-east-1 リージョンのレイテンシーエイリアスレコードを選択します。 1. Route 53 は、重みに基づいて加重レコードを選択します。レイテンシーエイリアスレコードの [**Evaluate Target Health (ターゲットの正常性の評価)**] が [**Yes (あり)**] であるため、Route 53 は、選択された加重レコードの正常性をチェックします。 1. ヘルスチェックで不合格と判明した場合、Route 53 は、別の加重レコードを重みに基づいて選択し、その正常性をチェックします。そのレコードも異常であると判明します。 1. Route 53 は、ブランチの出発点に戻り、次善のレイテンシーを持つレイテンシーエイリアスレコードを検索して、ap-southeast-2 のレコードを選択します。 1. Route 53 は再度、重みに基づいてリソースを選択し、その正常性をチェックします。リソースは正常なので、Route 53 はクエリに対応した適切な値を返します。 **Topics** + [エイリアスレコードにヘルスチェックを関連付けるとどうなるか](#dns-failover-complex-configs-hc-alias) + [ヘルスチェックを省略するとどうなるか](#dns-failover-complex-configs-hc-omitting) + [[Evaluate Target Health] を [No] に設定するとどうなるか](#dns-failover-complex-configs-eth-no) ## エイリアスレコードにヘルスチェックを関連付けるとどうなるか [**Evaluate Target Health**] の値を [**Yes**] に設定する代わりに (または設定したうえで)、エイリアスレコードにヘルスチェックを関連付けることができます。ただし、実用性の面からいうと、基盤になるリソース (HTTP サーバー、データベースサーバーなど、エイリアスレコードの参照先となるリソース) の正常性に基づいて Route 53 がクエリに応答する、という構成の方が一般的です。例えば、次の構成を考えてみます。 + 一連の加重レコードをエイリアスターゲットとするレイテンシーエイリアスレコードにヘルスチェックを割り当てます。 + レイテンシーエイリアスレコードの [**Evaluate Target Health**] の値は、[**Yes**] に設定します。 この設定で、加重レコードに応じた値を Route 53 が返すためには、次の 2 点が満たされなければなりません。 + レイテンシーエイリアスレコードに関連付けられているヘルスチェックが合格すること。 + 少なくとも 1 つの加重レコードが、合格したヘルスチェックに関連付けられているか、またはヘルスチェックそのものに関連付けられていないことから、正常と見なされること。後者のケースでは、Route 53 は常に加重レコードを正常と見なします。 次の図では、左上のレイテンシーエイリアスレコードのヘルスチェックに失敗しています。結果として、Route 53 は、加重レコードのすべてが正常であっても、レイテンシーエイリアスレコードが参照する加重レコードのいずれかを使用したクエリの応答を停止します。Route 53 は、レイテンシーエイリアスレコードのヘルスチェックが再び正常となった場合にのみ、これらの加重レコードの再チェックを開始します。(例外については、「[ヘルスチェックが設定されている場合に Amazon Route 53 がレコードを選択する方法ヘルスチェックが設定されている場合に Route 53 がレコードを選択する方法](health-checks-how-route-53-chooses-records.md)」を参照してください。) ![\[ターゲットの正常性の評価が Yes で、エイリアスレコードのヘルスチェックに設定してあるエイリアスレコードを含む DNS 設定。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-alias-hc-failed.png) ## ヘルスチェックを省略するとどうなるか 複雑な構成では、エイリアス以外のすべてのレコードにヘルスチェックを関連付けることが大切です。次の例では、us-east-1 リージョンのいずれかの加重レコードでヘルスチェックが欠落しています。 ![\[ヘルスチェックが一度失敗し、ヘルスチェックのないレコードが 1 つある DNS 設定。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-missing-health-check.png) 以下に、この構成の非エイリアスレコードでヘルスチェックを省略した場合の動作を説明します。 1. Route 53 が example.com のクエリを受信します。要求元のユーザーに対するレイテンシーに基づいて、Route 53 は us-east-1 リージョンのレイテンシーエイリアスレコードを選択します。 1. Route 53 は、レイテンシーエイリアスレコードのエイリアスターゲットを探し、対応するヘルスチェックのステータスをチェックします。一方の加重レコードのヘルスチェックが不合格となり、そのレコードは考慮の対象から除外されます。 1. us-east-1 リージョンのエイリアスターゲット内のもう一方の加重レコードにはヘルスチェックが関連付けられていません。ヘルスチェックを行わない限り、対応するリソースが正常であるかどうかを Route 53 が認識する方法はありません。リソースは正常なので、Route 53 はクエリに応じて適切な値を返します。 ## [Evaluate Target Health] を [No] に設定するとどうなるか 一般に、ツリー内のすべてのエイリアスレコードについて、[**ターゲットの正常性の評価**] を [**Yes** (あり)] に設定する必要があります。[**Evaluate Target Health (ターゲットの正常性の評価)**] を [**No (なし)**] に設定した場合、Route 53 は、レコードのヘルスチェックが失敗した場合でも、エイリアスレコードが参照するレコードにトラフィックをルーティングし続けます。 次の例では、すべての加重レコードに関連付けられたヘルスチェックがありますが、us-east-1 リージョンのレイテンシーエイリアスレコードの [**ターゲットの正常性の評価**] は [**No** (なし)] に設定されています。 ![\[ターゲットの正常性の評価が No に設定されているエイリアスレコードを含む DNS 設定。\]](http://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-eth-is-no.png) この構成でエイリアスレコードの [**Evaluate Target Health**] を [**No**] に設定した場合の動作を以下に説明します。 1. Route 53 が example.com のクエリを受信します。要求元のユーザーに対するレイテンシーに基づいて、Route 53 は us-east-1 リージョンのレイテンシーエイリアスレコードを選択します。 1. Route 53 は、レイテンシーエイリアスレコードのエイリアスターゲットを特定し、対応するヘルスチェックを調べます。どちらも不合格です。 1. us-east-1 リージョンでは、レイテンシーエイリアスレコードの [**Evaluate Target Health**] の値が [**No**] であるため、Route 53 は、このブランチの中からいずれかのレコードを選ぶ必要があります。ブランチの出発点に戻って ap-southeast-2 リージョンから正常なレコードを探すことはありません。 # ヘルスチェックが設定されている場合に Amazon Route 53 がレコードを選択する方法 同じ名前、同じタイプ (A または AAAA など)、および同じルーティングポリシー (加重またはフェイルオーバーなど) を持つレコードグループ内のすべてのレコードのヘルスチェックを設定すると、Route 53 は正常なレコードを選択し、そのレコードから該当する値を返すことによって、DNS クエリに応答します。 例えば、3 つの加重された A レコードを作成し、そのすべてにヘルスチェックを割り当てたとします。1 つのレコードでヘルスチェックが正常でない場合、Route 53 は他の 2 つのレコードのいずれかの IP アドレスで DNS クエリに応答します。 正常なレコードを Route 53 が選択する際の動作を以下に示します。 1. 最初に Route 53 は、ルーティングポリシーと各レコードに指定した値に基づいてレコードを選択します。例えば、加重レコードの場合、Route 53 は各レコードに指定した重みに基づいてレコードを選択します。 1. Route 53 は、レコードが正常であるかどうかを判断します。 + **関連付けられたヘルスチェックを持つ非エイリアスレコード** – ヘルスチェックを非エイリアスレコードに関連付けた場合、Route 53 はヘルスチェックの現在のステータスをチェックします。 Route 53 は、ヘルスチェックで指定されたエンドポイントの正常性を定期的にチェックします。DNS クエリが到着した時点でヘルスチェックを実行するわけではありません。 ヘルスチェックはエイリアスレコードに関連付けることができますが、ヘルスチェックはエイリアス以外のレコードにのみ関連付けることをお勧めします。詳細については、「[エイリアスレコードにヘルスチェックを関連付けるとどうなるか](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias)」を参照してください。 + **[Evaluate Target Health (ターゲットの正常性の評価)] が [Yes (あり)] に設定されたエイリアスレコード** – Route 53 は、エイリアスレコードが参照するリソース (例えば、ELB ロードバランサーまたは同じホストゾーン内の別のレコード) のヘルスステータスをチェックします。 1. レコードが正常であれば、Route 53 は、適切な値 (IP アドレスなど) でクエリに応答します。 レコードが異常である場合、Route 53 は同じ基準で別のレコードを選択し、正常なレコードが見つかるまでそのプロセスを繰り返します。 レコードを選択する際、Route 53 は以下の基準を使用します。 **ヘルスチェックのないレコードは常に正常** 同じ名前とタイプを持つレコードのグループ内で、レコードに関連付けられているヘルスチェックがない場合、Route 53 はそのレコードを常に正常と見なします。クエリへの応答の候補には、そのレコードが常に含まれます。 **レコードが正常でない場合は、すべてのレコードが正常** レコードのグループ内に正常なレコードが 1 つも存在しなかった場合でも、Route 53 は DNS クエリへの応答として何かを返す必要がありますが、レコードの優劣を選択するための判断材料がありません。この状況では、グループに含まれるすべてのレコードが正常と見なされ、Route 53 はルーティングポリシーと各レコードに指定した値に基づいて 1 つを選択します。 **重みが 0 である加重レコード** 加重レコードのグループ内のすべてのレコードにヘルスチェックを追加する一方で、一部のレコードにゼロ以外の重みを付け、他のレコードの重みをゼロにした場合、ヘルスチェックは、次の例外を除いて、すべてのレコードの重みがゼロ以外の場合と同様に動作します。 + 最初に Route 53 は、ゼロ以外の加重レコード (存在する場合) のみを対象とします。 + 重みが 0 より大きいレコードがいずれも異常であった場合、Route 53 は、重みがゼロである加重レコードを対象にします。 一部の状況では Route 53 は重みがゼロである加重レコードを考慮するので、重みがゼロのターゲットにも DNS クエリに対する実行可能な回答があるようにすることが重要です。 加重レコードの詳細については、「[ヘルスチェックと加重ルーティング](routing-policy-weighted.md#routing-policy-weighted-healthchecks)」を参照してください。 **エイリアスレコード** 各エイリアスレコードに対して [**ターゲットの正常性の評価**] を [**Yes** (あり)] に設定することで、エイリアスレコードのヘルスチェックを設定することもできます。これにより Route 53 は、レコードがトラフィックをルーティングする先のリソース (例えば、ELB ロードバランサーまたは同じホストされたゾーン内の別のレコード) で、その正常性を評価します。 例えば、エイリアスレコードのエイリアスターゲットが、一連の加重レコードから成るグループであり、そのグループの加重レコードの重みがいずれもゼロ以外であるとします。 + 正常な加重レコードが 1 つでもあれば、Route 53 は、そのエイリアスレコードを正常と見なします。 + 正常な加重レコードが存在しない場合、Route 53 は、そのエイリアスレコードを異常と見なします。 + 少なくとも 1 つの加重レコードが正常に戻るまで、Route 53 は、そのツリーのブランチのレコードを候補から除外します。 詳細については、「[Amazon Route 53 の複雑な構成でのヘルスチェックの動作複雑な構成におけるヘルスチェックの動作](dns-failover-complex-configs.md)」を参照してください。 **フェイルオーバーレコード** フェイルオーバーレコードは、通常、他のルーティングタイプと同じように動作します。ヘルスチェックを作成し、それらを非エイリアスレコードに関連付けて、エイリアスレコードの [**ターゲットの正常性の評価**] を [**Yes** (あり)] に設定します。次の点に注意してください。 + プライマリレコードとセカンダリレコードは、どちらも非エイリアスレコードまたはエイリアスレコードです。 + プライマリフェイルオーバーレコードとセカンダリフェイルオーバーレコードの両方にヘルスチェックが関連付けられている場合、Route 53 は、リクエストに対して次のように応答します。 + プライマリレコードが正常 (ヘルスチェックのエンドポイントが正常) であると判断した Route 53 は、 DNS クエリへの応答としてプライマリレコードのみを返します。 + プライマリレコードが異常でありセカンダリレコードが正常であると Route 53 が判断した場合は、セカンダリレコードが返されます。 + プライマリレコードとセカンダリレコードの両方が異常であると Route 53 が判断した場合は、プライマリレコードが返されます。 + セカンダリレコードを設定する際、ヘルスチェックを追加するかどうかは任意です。セカンダリのヘルスチェックが省略されていて、プライマリレコードのヘルスチェックエンドポイントが異常だった場合、Route 53 は常にセカンダリレコードで DNS クエリに応答します。セカンダリレコードが異常であったとしても同様です。 詳細については、以下のトピックを参照してください。 + [1 つのプライマリリソースおよび 1 つのセカンダリリソースを使用したフェイルオーバー (アクティブ/パッシブ) の設定](dns-failover-types.md#dns-failover-types-active-passive-one-resource) + [複数のプライマリリソースおよびセカンダリリソースを使用したフェイルオーバー (アクティブ/パッシブ) の設定](dns-failover-types.md#dns-failover-types-active-passive-multiple-resources) # フェイルオーバー (アクティブ/アクティブとアクティブ/パッシブ) の設定 Route 53 のヘルスチェックを使用して、フェイルオーバー (アクティブ/アクティブとアクティブ/パッシブ) を設定できます。フェイルオーバー以外のいずれかの[ルーティングポリシー](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) (またはルーティングポリシーの組み合わせ) を使用して、フェイルオーバー (アクティブ/アクティブ) を設定し、フェイルオーバールーティングポリシーを使用してフェイルオーバー (アクティブ/パッシブ) を設定します。 **Topics** + [フェイルオーバー (アクティブ/アクティブ)](#dns-failover-types-active-active) + [アクティブ/パッシブ (フェイルオーバー)。](#dns-failover-types-active-passive) ## フェイルオーバー (アクティブ/アクティブ) すべてのリソースをほとんどの時間で利用できるようにするには、このフェイルオーバー設定を使用します。利用不可能になったリソースについては、Route 53 は異常として検出できるので、以後、クエリへの応答に使用しなくなります。 アクティブ/アクティブのフェイルオーバーでは、Route 53 がそれらを異常と見なさない限り、同じ名前、同じタイプ (A または AAAAなど)、および同じルーティングポリシー (加重またはレイテンシーなど) を持つすべてのレコードがアクティブとなります。Route 53 は、正常な任意のレコードを使用して DNS クエリに応答できます。 ## アクティブ/パッシブ (フェイルオーバー)。 プライマリリソースまたはリソースグループをほとんどの時間で利用可能にして、すべてのプライマリリソースが使用できなくなった場合に備えて、セカンダリリソースまたはリソースグループをスタンバイ状態にする場合は、フェイルオーバー (アクティブ/パッシブ) 設定を使用します。クエリへの応答で Route 53 が返すのは、正常なプライマリリソースのみです。すべてのプライマリリソースで異常が発生した場合、Route 53 は、DNS クエリへの応答として正常なセカンダリリソースのみを返します。 **Topics** + [1 つのプライマリリソースおよび 1 つのセカンダリリソースを使用したフェイルオーバー (アクティブ/パッシブ) の設定](#dns-failover-types-active-passive-one-resource) + [複数のプライマリリソースおよびセカンダリリソースを使用したフェイルオーバー (アクティブ/パッシブ) の設定](#dns-failover-types-active-passive-multiple-resources) + [加重レコードを使用してフェイルオーバー (アクティブ/パッシブ) を構成する](#dns-failover-types-active-passive-weighted) ### 1 つのプライマリリソースおよび 1 つのセカンダリリソースを使用したフェイルオーバー (アクティブ/パッシブ) の設定 1 つのプライマリレコードと 1 つのセカンダリレコードでフェイルオーバー (アクティブ/パッシブ) 設定を作成するには、レコードを作成し、ルーティングポリシーとして [**フェイルオーバー**] を指定します。プライマリリソースが正常な場合、Route 53 はプライマリレコードを使用して DNS クエリに応答します。プライマリリソースが異常な場合、Route 53 はセカンダリレコードを使用して DNS クエリに応答します。 ### 複数のプライマリリソースおよびセカンダリリソースを使用したフェイルオーバー (アクティブ/パッシブ) の設定 プライマリレコード、セカンダリレコード、またはその両方に複数のリソースを関連付けることもできます。この構成では、 関連付けられたリソースの少なくとも 1 つが正常である限り、Route 53 はプライマリフェイルオーバーレコードが正常であると見なします。詳細については、「[ヘルスチェックが設定されている場合に Amazon Route 53 がレコードを選択する方法ヘルスチェックが設定されている場合に Route 53 がレコードを選択する方法](health-checks-how-route-53-chooses-records.md)」を参照してください。 プライマリまたはセカンダリレコードの複数のリソースでフェイルオーバー (アクティブ/パッシブ) を設定するには、次のタスクを実行します。 1. トラフィックをルーティングするリソース (EC2 インスタンスやデータセンター内のウェブサーバーなど) ごとに、ヘルスチェックを作成します。 **注記** [エイリアスレコード](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html)を作成できる AWS リソースにトラフィックをルーティングする場合は、それらのリソースのヘルスチェックを作成しないでください。エイリアスレコードを作成する場合は、[**ターゲットの正常性の評価**] を [**Yes** (あり)] に設定します。 詳細については、「[ヘルスチェックの作成と更新](health-checks-creating.md)」を参照してください。 1. プライマリリソースのレコードを作成し、次の値を指定します。 + 各レコードに同じ名前、タイプ、ルーティングポリシーを割り当てます。例えば、すべてが failover-primary.example.com という名前の 3 つの加重 A レコードを作成することができます。 + エイリアスレコードを作成できる AWS リソースを使用している場合は、ターゲットの状態の評価に**「はい**」と指定します。 **** エイリアスレコードを作成できないリソースを使用している場合は、ステップ 1 の該当するヘルスチェックを各レコードに関連付けます。 詳細については、「[Amazon Route 53 コンソールを使用したレコードの作成](resource-record-sets-creating.md)」を参照してください。 1. 該当する場合、セカンダリリソースのレコードを作成し、次の値を指定します。 + 各レコードに同じ名前、タイプ、ルーティングポリシーを割り当てます。例えば、すべてが failover-secondary.example.com という名前の 3 つの加重 A レコードを作成することができます。 + エイリアスレコードを作成できる AWS リソースを使用している場合は、ターゲットの状態の評価に**「はい**」と指定します。 **** エイリアスレコードを作成できないリソースを使用している場合は、ステップ 1 の該当するヘルスチェックを各レコードに関連付けます。 **注記** 一部のお客様は、プライマリリソースとしてウェブサーバーを使用し、ウェブサイトエンドポイントとして構成された Amazon S3 バケットをセカンダリリソースとして使用されています。S3 バケットには、「一時的に使用できません」という簡単なメッセージが含まれています。その構成を使用している場合は、この手順をスキップして、ステップ 4 でセカンダリリソースのフェイルオーバーエイリアスレコードを作成します。 1. プライマリとセカンダリの 2 つのフェイルオーバーエイリアスレコードを作成し、次の値を指定します。 **プライマリレコード** + **Name (名前)** – Route 53 でトラフィックをルーティングさせるドメイン名 (example.com)、またはサブドメイン名 (www.example.com) を指定します。 + **エイリアス **– **あり** を指定します。 + **エイリアス先 **‐ ステップ 2 で作成したレコードの名前を指定します。 + **ルーティングポリシー **– **フェイルオーバーを指定します。** + **フェイルオーバーレコードのタイプ **– **プライマリ**を指定します。 + **ターゲットの正常性の評価** – **あり** を指定します。 + **ヘルスチェックとの関連付け** – **なし **を指定します。 **セカンダリレコード** + **名前**－プライマリレコードに指定したものと同じ名前を指定します。 + **エイリアス** – **ありを指定します**。 + **エイリアス先 **– ステップ 3 でセカンダリリソースのレコードを作成している場合は、レコードの名前を指定します。セカンダリリソースに Amazon S3 バケットを使用している場合は、ウェブサイトエンドポイントの DNS 名を指定します。 + **ルーティングポリシー**－ **フェイルオーバーを指定します**。 + **フェイルオーバーレコードのタイプ **–** セカンダリ を指定します**。 + **ターゲットの正常性の評価 ** －**あり を指定します**。 + **ヘルスチェックとの関連付け** －**なしを指定します**。 ### 加重レコードを使用してフェイルオーバー (アクティブ/パッシブ) を構成する また、警告付きのフェイルオーバー (アクティブ/パッシブ) のために加重されたレコードを使用することもできます。一部のレコードに対してゼロ以外の重みを指定し、他のレコードに対してゼロの重みを指定した場合、Route 53 は重みがゼロ以外の健全なレコードのみを使用して DNS クエリに応答します。重みがゼロより大きいレコードがいずれも異常であった場合、Route 53 は重みがゼロであるレコードを使用してクエリに応答します。 **注記** Route 53 がゼロの重みを持つレコードを使用して DNS クエリに応答するためには、ゼロ以外の重みを持つすべてのレコードが異常とみなされる必要があります。これにより、ウェブサーバーなどの最後の正常なリソースが、他のリソースが利用できないときにすべてのトラフィックを処理できない場合、ウェブアプリケーションまたはウェブサイトが信頼できなくなる可能性があります。 # プライベートホストゾーンのフェイルオーバーの設定 プライベートホストゾーンにフェイルオーバーレコードを作成する方法は、次の点に注意してください。 + Route 53 ヘルスチェッカーは VPC の外にあります。IP アドレスを使用して VPC 内のエンドポイントの正常性をチェックするには、VPC 内のインスタンスにパブリック IP アドレスを割り当てる必要があります。 + また、CloudWatch メトリクスを作成し、アラームをメトリクスに関連付けて、アラームのデータストリームに基づくヘルスチェックを作成することもできます。例えば、EC2 の `StatusCheckFailed` メトリクスのステータスをチェックする CloudWatch メトリクスを作成、このメトリクスにアラームを追加、さらにアラームのデータストリームに基づいたヘルスチェックを作成することが可能であり、バーチャルプライベートクラウド (VPC) 内にプライベート IP アドレスのみがあるインスタンスをチェックします。CloudWatch コンソールを使用して CloudWatch メトリクスおよびアラームを作成する方法について詳細は、[Amazon CloudWatch ユーザーガイド](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/)を参照してください。 詳細については、「[プライベートホストゾーンの使用](hosted-zones-private.md)」および「[CloudWatch を使用したヘルスチェックのモニタリング](monitoring-health-checks.md)」を参照してください。 # Amazon Route 53 でフェイルオーバーの問題を回避する方法 Route 53 に実装されたフェイルオーバーアルゴリズムは、正常なエンドポイントにトラフィックをルーティングするだけでなく、ヘルスチェックやアプリケーションの設定ミス、エンドポイントの過負荷、パーティションの障害などに起因する最悪のシナリオを回避するように設計されています。 **Topics** + [Amazon Route 53 でカスケードの失敗を回避する方法](#dns-failover-cascading-failures) + [Amazon Route 53 でのインターネットの分断への対処方法](#dns-failover-internet-partitions) ## Amazon Route 53 でカスケードの失敗を回避する方法 カスケードの失敗に対する第一の備えとして、すべてのリクエストルーティングアルゴリズム (加重やフェイルオーバーなど) には、最後の手段となるモードが用意されています。この特殊なモードでは、レコードがすべて異常と判断された場合に、Route 53 アルゴリズムは、再びすべてのレコードを正常と見なすようになります。 例えば、いくつかのホスト上で、アプリケーションの全インスタンスがヘルスチェックリクエストを拒否している場合、Route 53 の DNS サーバーは、DNS 応答を拒否したり NXDOMAIN (存在しないドメイン) 応答を返したりするのではなく、何等かの応答を返します。アプリケーションがユーザーに応答しても、ヘルスチェックには不合格になることがあるため、設定ミスから生じる問題をある程度防ぐことができます。 同様に、アプリケーションに過剰な負荷がかかっていて、3 つのエンドポイントのうち 1 つがヘルスチェックで不合格と判断され、Route 53 の DNS 応答から除外された場合、Route 53 は残りの 2 つのエンドポイントを使って応答を返します。残りのエンドポイントがそれ以上の負荷に耐えきれず障害が発生した場合、Route 53 は再度、3 つすべてのエンドポイントにリクエストを分配するようになります。 ## Amazon Route 53 でのインターネットの分断への対処方法 一般的ではありませんが、インターネットに重大な分断が生じる場合があります。つまり、大規模な地理的リージョン間でインターネット経由の相互通信ができなくなることがあります。インターネットに分断が生じている間、エンドポイントの正常性ステータスに関して導き出される結論が Route 53 の拠点によって違ったり、CloudWatch に報告されるステータスと異なることがあります。各 AWS リージョンの Route 53 ヘルスチェッカーは、すべての Route 53 ロケーションにヘルスチェックステータスを常に送信しています。インターネットの分断が生じている間は、Route 53 の各拠点は、そうしたステータスの一部 (通常は最も近いリージョンのステータス) にしかアクセスできなくなります。 例えば、インターネットの分断で南米との接続に影響が生じているとします。その間、 南米 (サンパウロ) にある Route 53 DNS サーバーは、 AWS リージョンの南米 (サンパウロ) にあるヘルスチェックエンドポイントには問題なくアクセスできますが、その他のエンドポイントには正常にアクセスできない可能性があります。同時に、米国東部 (オハイオ) の Route 53 は、南米 (サンパウロ) リージョンのヘルスチェックエンドポイントへのアクセスに支障があるとして、対応するレコードを異常と判断することが考えられます。 こうした分断によって、Route 53 の各拠点が、それぞれ域内のエンドポイントの可視性によってエンドポイントの正常性ステータスを判断するようになり、最終的に拠点ごとにその結論が異なる、という状況に発展する可能性があります。そのため、Route 53 の各拠点は、到達可能なごく一部のヘルスチェッカーがエンドポイントを正常と判断していれば、そのエンドポイントを正常と見なします。 # ヘルスチェックの名前付けとタグ付け Amazon Route 53 ヘルスチェックにはタグを追加することができます。タグを追加することによって、ヘルスチェック ID よりもわかりやすい名前を個々のヘルスチェックに付けることができます。これらは、 が AWS 請求書を整理するために AWS Billing and Cost Management 提供するのと同じタグです。コスト配分でタグがどのように使用されているかについては、*AWS Billing ユーザーガイド*の [コスト配分タグを使用したカスタム請求レポート](https://docs.aws.amazon.com/awsaccountbilling/latest/aboutv2/allocation.html)を参照してください。 それぞれのタグは、キー（タグの名前）と値で構成されます。キーと値は、どちらもお客様が定義します。ヘルスチェックにタグを追加するときは、キーと値に次の値を持つタグを 1 つ追加することをお勧めします。 + **キー** - **名前** + **値**: ヘルスチェックに割り当てる名前。 Route 53 コンソールのヘルスチェックのリストには、[**名前**] タグの値が表示されるため、個々のヘルスチェックが識別しやすくなります。ヘルスチェックのタグを表示するには、ヘルスチェックを選択し、[**タグ**] タブをクリックします。 タグの詳細については、次のトピックを参照してください。 + Route 53 コンソールでヘルスチェックを追加または編集するときに、**名前**タグを追加、編集、または削除する場合は、[ヘルスチェックの作成と更新](health-checks-creating.md) をご覧ください。 + Route 53 リソースにタグを付ける方法の概要については、「[Amazon Route 53 リソースのタグ付け](tagging-resources.md)」を参照してください。 ## タグの制限 タグには以下のベーシックな制限があります。 + リソースあたりのタグの最大数 – 新しいコンソールは 50、古いコンソールは 10。 + **キー**の最大長 - 128 文字 (Unicode) + **値**の最大長 - 256 文字 (Unicode) + **キー**と**値**に使用できる文字: アルファベットの大文字と小文字 (UTF-8 文字セット)、数字、スペース、および以下の記号文字 (\$1 . : / = \$1 - @) です。 + タグのキーと値は大文字と小文字が区別されます。 + キーまたは値に`aws:`プレフィックスを使用しないでください。 AWS 用に予約されています。 ## ヘルスチェックに対するタグの追加、編集、削除 次の手順は、ヘルスチェックのタグを Route 53 コンソールで使用する方法を示しています。 **注記** Route 53 のヘルスチェックコンソールを更新中です。旧コンソールは移行期間中も引き続きご使用いただけます。 お使いのコンソールのタブを選択します。 + [新しいコンソール](#health-checks-tagging-new) + [旧コンソール](#health-checks-tagging-old) ------ #### [ New console ] **ヘルスチェックにタグを追加するには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで **[ヘルスチェック]** を選択します。 1. タグを追加するヘルスチェックのリンクされた ID を選択します。 1. 下部ページで、**[タグ]** タブ、**[管理]**、**[新しいタグを追加]** の順に選択します。 1. **[キー]** フィールドにタグの名前を入力し、**[値]** フィールドに値を入力します。 1. **[保存]** を選択します。 **ヘルスチェックのタグを編集するには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで **[ヘルスチェック]** を選択します。 1. ヘルスチェックのリンクされた ID を選択します。 1. 下部のペインで **[タグ]** タブ、**[管理]** の順に選択します。 1. タグを編集および追加することができるようになりました。 1. **[保存]** を選択します。 **ヘルスチェックのタグを削除するには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで **[ヘルスチェック]** を選択します。 1. ヘルスチェックのリンクされた ID を選択します。 1. 下部のペインで **[タグ]** タブ、**[管理]** の順に選択します。 1. 削除するタグの横にある **[削除]** を選択します。 1. **[保存]** を選択します。 ------ #### [ Old console ] **ヘルスチェックにタグを追加するには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで [**Health Checks (ヘルスチェック)**] を選択します。 1. ヘルスチェックを選択します。同じタグを複数のヘルスチェックに追加する場合は、複数のヘルスチェックを選択してください。 1. 下部のペインで [**Tags**] タブ、[**Add/Edit Tags**] の順に選択します。 1. [**Add/Edit Tags**] ダイアログボックスの [**Key**] フィールドにタグの名前を入力し、[**Value**] フィールドに値を入力します。 1. [**Apply changes (変更の適用)**] を選択します。 **ヘルスチェックのタグを編集するには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで [**Health Checks (ヘルスチェック)**] を選択します。 1. ヘルスチェックを選択します。 同じタグを共有する複数のヘルスチェックを選択した場合に、すべてのタグの値を一度に編集することはできません。ただし、指定したタグを含むヘルスチェックと共に含まないヘルスチェックを 1 つ以上選択した場合、複数のヘルスチェックに表示されるタグの値を編集できます。 たとえば、**Cost Center** タグが含まれている複数のヘルスチェックと、含まれていない 1 つのヘルスチェックを選択したとします。このとき、タグを追加するオプションを選択して、キーに「**Cost Center**」、値に「**777**」を指定します。選択されたヘルスチェックのうち、既に **Cost Center** タグが設定されているヘルスチェックに対して、Route 53 はその値を **777** に変更します。**Cost Center** タグを持たないヘルスチェックに対しては、 Route 53 がそのタグを追加し、値を **777** に設定します。 1. 下部のペインで [**Tags**] タブ、[**Add/Edit Tags**] の順に選択します。 1. [**Add/Edit Tags**] ダイアログボックスで値を編集します。 1. **[保存]** を選択します。 **ヘルスチェックのタグを削除するには** 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/route53/](https://console.aws.amazon.com/route53/) で Route 53 コンソールを開きます。 1. ナビゲーションペインで [**Health Checks (ヘルスチェック)**] を選択します。 1. ヘルスチェックを選択します。同じタグを複数のヘルスチェックから削除する場合は、複数のヘルスチェックを選択してください。 1. 下部のペインで [**Tags**] タブ、[**Add/Edit Tags**] の順に選択します。 1. [**Add/Edit Tags**] ダイアログボックスで、削除するタグの横にある赤色の *X* を選択します。 1. [**Save**] を選択します。 ------ # Amazon Route 53 API バージョン 2012-12-12 未満でのヘルスチェックの使用 ヘルスチェックは、Amazon Route 53 API 2012-12-12 以降のバージョンでサポートされます。ヘルスチェックが設定されているレコードがホストゾーンに存在する場合は、2012-12-12 API 以降のみを使用するようお勧めします。それより前の API バージョンでのヘルスチェックの使用には、次の制限があります。 + `EvaluateTargetHealth`、`Failover`、`HealthCheckId` のいずれかの要素を含んだレコードを `ChangeResourceRecordSets` アクションで作成したり削除したりすることができません。 + それらの要素を含んだレコードを `ListResourceRecordSets` アクションでリストすることはできますが、出力結果にはそれらの要素が含まれません。サポート外の属性がレコードに含まれていることを示すメッセージが、レスポンスの `Value` 要素に格納されます。