AWS Solutions Architect · レッスン

ヘルスチェックと DNS フェイルオーバー

エンドポイント、計算済み、CloudWatch アラームのヘルスチェックを設定し、異常なエンドポイントから自動的にトラフィックを切り替えるよう Route 53 を構成します。

「ヘルスチェックと DNS フェイルオーバー」はCoddyKit上の無料AWS Solutions Architectレッスンです。これはレッスン4/4です。下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応のAIチューターでハンズオン演習できます。これはAWS Solutions Architect学習パスの一部であり、ウェブとCoddyKitアプリ全体で進捗が同期されます。 AWS Solutions Architectコースには全4レッスンが含まれています。

Route 53のヘルスチェックとは

Route 53のヘルスチェックは、Webサーバー、ロードバランサー、またはインターネットからアクセスできるHTTP／HTTPS／TCPエンドポイントなど、エンドポイントの状態を継続的に監視します。ヘルスチェックの結果に基づいて、Route 53はDNSルーティングを自動的に更新し、異常なリソースにトラフィックが送信されるのを防げます。

ヘルスチェックには、1件あたり月額料金がかかります。Route 53のグローバルヘルスチェッカー（複数のリージョンに配置）がエンドポイントを同時にプローブするため、ヘルスチェック自体にも冗長性があります。エンドポイントが異常とみなされるのは、一定数のチェッカーが失敗したと一致して判断した場合のみです。

エンドポイントヘルスチェック

エンドポイントヘルスチェックは、指定したプロトコル（HTTP、HTTPS、またはTCP）、ポート、オプションのパスを使用して、特定のIPアドレスまたはドメイン名を監視します。HTTP／HTTPSチェックでは、エンドポイントがタイムアウト時間内に2xxまたは3xxのHTTPステータスコードを返すことをRoute 53が確認します。HTTPSチェックでは、オプションでTLS証明書も検証できます。

主な設定項目は、リクエスト間隔（10秒または30秒。10秒にすると検出は速くなりますが、料金が高くなります）、失敗しきい値（異常と判定するまでの連続失敗回数。1～10回）、文字列照合（レスポンス本文に特定の文字列が含まれていることを任意で確認）です。

# Create an HTTP health check
aws route53 create-health-check \
  --caller-reference hc-2026-06-20 \
  --health-check-config '{
    "Type": "HTTP",
    "IPAddress": "54.100.1.1",
    "Port": 80,
    "ResourcePath": "/health",
    "FailureThreshold": 3,
    "RequestInterval": 30
  }'

計算済みヘルスチェック

計算済みヘルスチェックは、複数の子ヘルスチェックの結果をブール論理（AND、OR、NOT）で組み合わせます。複雑なルーティングチェーンを作成せずに、複数のシグナルに基づいてアプリケーションレベルのヘルスを定義できます。

例として、APIサーバーのチェックとデータベースのチェックの両方に合格した場合のみ、Webアプリケーションが正常であるとします。両方のエンドポイントチェックを参照する、タイプがANDの計算済みヘルスチェックを作成します。どちらか一方が失敗すると、計算済みヘルスチェックも失敗し、Route 53は関連付けられたDNSレコードをレスポンスから除外します。

# Create a calculated health check (AND of two child checks)
aws route53 create-health-check \
  --caller-reference hc-calc-2026 \
  --health-check-config '{
    "Type": "CALCULATED",
    "ChildHealthChecks": [
      "hc-api-id",
      "hc-db-id"
    ],
    "HealthThreshold": 2
  }'

CloudWatchアラームヘルスチェック

CloudWatchアラームヘルスチェックは、Route 53のヘルスチェックをCloudWatchアラームの状態に関連付けます。アラームがALARM状態の場合、ヘルスチェックは異常と判定されます。OKまたはINSUFFICIENT_DATAの場合は、正常と判定されます。

このパターンは、VPC内のエンドポイント（Route 53の外部ヘルスチェッカーから到達できないリソース）に特に有効です。プライベートエンドポイントを直接プローブする代わりに、そのエンドポイント用のCloudWatchメトリクスとアラームを作成し、アラームの状態に基づいてRoute 53のヘルスチェックを実行します。これにより、エラー率やキューの深さなど、ビジネスメトリクスに基づくヘルスチェックも可能になります。

# Create a health check based on a CloudWatch alarm
aws route53 create-health-check \
  --caller-reference hc-cw-2026 \
  --health-check-config '{
    "Type": "CLOUDWATCH_METRIC",
    "AlarmIdentifier": {
      "Region": "us-east-1",
      "Name": "HighErrorRate-Alarm"
    },
    "InsufficientDataHealthStatus": "Healthy"
  }'

プライベートエンドポイントのヘルスチェック

Route 53のヘルスチェッカーは、VPCの外部にあるAWS管理のサーバーで、パブリックインターネット経由でエンドポイントにアクセスします。プライベートサブネット内のリソースには、標準のエンドポイントヘルスチェックからアクセスできません。プライベートエンドポイントには、次のいずれかの方法を使用してください。

VPC内部からカスタムCloudWatchメトリクス（アプリケーションからの成功／失敗シグナルなど）を発行し、アラームを作成して、CloudWatchアラームヘルスチェックを使用する
VPC内部のELB、RDS、またはアプリケーションのメトリクスを集約するCloudWatchコンポジットアラームを使用する

このパターンは、プライベートサブネット内のデータベース、内部ロードバランサー、バックエンドサービスにとって重要です。

ヘルスチェックのステータスとモニタリング

Route 53コンソールのHealth Checksでヘルスチェックのステータスを確認できます。また、API経由で取得することもできます。Route 53は、AWS/Route53名前空間にヘルスチェックのメトリクスを発行します。これには、HealthCheckStatus（1 = 正常、0 = 異常）や、HealthCheckPercentageHealthy（エンドポイントが正常であると報告したRoute 53チェッカーの割合）が含まれます。

HealthCheckStatusに対してCloudWatchアラームを設定すると、エンドポイントが異常になったときにSNS通知を受け取れます。これにより、オンコールチームがDNSフェイルオーバーの発生に気付く前に状況を把握できます。

# Get health check status
aws route53 get-health-check-status \
  --health-check-id a1b2c3d4-e5f6-7890-abcd-ef1234567890 \
  --query 'CheckerIpRanges'

フェイルオーバールーティングによるDNSフェイルオーバー

Route 53がPrimaryレコードのヘルスチェック失敗を検出すると、PrimaryをDNSレスポンスから除外し、Secondaryのアドレスを返します。これをDNSフェイルオーバーと呼びます。切り替えは、評価期間（ヘルスチェッカーの失敗回数 × リクエスト間隔）にレコードのTTLを加えた時間内に発生します。

例として、リクエスト間隔が30秒、失敗しきい値が3、TTLが60秒の場合を考えます。最悪時のフェイルオーバー時間は、およそ3 × 30 + 60 = 150秒です。TTLを短く（例：10秒）し、ヘルスチェック間隔を短く（10秒）すると、3 × 10 + 10 = 40秒まで短縮できます。

加重レコードとレイテンシーレコードのヘルスチェック

ヘルスチェックは、フェイルオーバーレコードだけでなく、加重レコードやレイテンシーレコードにも関連付けられます。加重レコードのヘルスチェックが失敗すると、Route 53はそのレコードのトラフィックの重みを、正常な加重レコード間で比例配分します。レイテンシーレコードのヘルスチェックが失敗すると、Route 53は次にレイテンシーが低い正常なレコードへクエリをルーティングします。

これにより、明示的なフェイルオーバーレコードを必要とせずに、加重ルーティングとレイテンシールーティングの各ポリシーでエンドポイント障害に対応できます。これはSAA-C03でよく扱われるパターンです。ヘルスチェックを併用したリージョン間のレイテンシールーティングにより、パフォーマンスの最適化と自動ディザスタリカバリの両方を実現できます。

ヘルスチェックを使用したアクティブ／アクティブのマルチリージョン構成

Route 53を使用した、耐障害性の高いマルチリージョンのアクティブ／アクティブ構成は次のとおりです。

各リージョン（us-east-1、eu-west-1、ap-southeast-1）に、ヘルスチェック付きのレイテンシーレコードを作成します
すべてのリージョンが正常な場合、ユーザーはレイテンシーが最も低いリージョンへルーティングされます
いずれかのリージョンのヘルスチェックが失敗すると（アプリケーションの停止または応答なし）、Route 53はそのリージョンをDNSレスポンスから自動的に除外し、次に適した正常なリージョンへクエリをルーティングします
障害が発生したリージョンが復旧すると、ヘルスチェックに合格し、Route 53はそのリージョンをローテーションに再追加します

これにより、手動介入なしで、パフォーマンスを最適化した自動グローバルフェイルオーバーを実現できます。

Route 53ヘルスチェッカーのIP範囲

Route 53のヘルスチェッカーは、AWS IP範囲JSONファイルのROUTE53_HEALTHCHECKSセクションに公開されているIP範囲からアクセスします。エンドポイントが、インバウンドアクセスを制限するファイアウォールまたはセキュリティグループで保護されている場合、ヘルスチェックが成功するように、これらのIP範囲からのトラフィックを許可する必要があります。

別の方法として、プライベートバックエンド（ALBなど）へプロキシするパブリック向けエンドポイントをヘルスチェックに使用できます。ALBのセキュリティグループではRoute 53のIP範囲のみを許可し、バックエンドのセキュリティグループではALBのセキュリティグループのみを許可します。これにより、多層防御のアプローチを維持できます。

# Fetch Route 53 health checker IP ranges
curl -s https://ip-ranges.amazonaws.com/ip-ranges.json | \
  python3 -c "
import json,sys
data=json.load(sys.stdin)
ranges=[p['ip_prefix'] for p in data['prefixes'] if p['service']=='ROUTE53_HEALTHCHECKS']
print('\n'.join(ranges))
"

ヘルスチェックのベストプラクティス

Route 53ヘルスチェックのベストプラクティスは次のとおりです。

重要な依存関係（データベース接続やキャッシュへの到達性など）をすべて確認し、完全に稼働している場合のみ200を返す専用の/healthエンドポイントを作成する
重要な本番エンドポイントには10秒のリクエスト間隔を使用して、障害をより速く検出する
CloudWatchでHealthCheckPercentageHealthyを監視する。一部のRoute 53チェッカーだけが失敗する部分的な障害は、リージョンのネットワーク障害または断続的な問題を示している可能性があります
VPC内のプライベートリソースには、アプリケーションメトリクスに基づくCloudWatchアラームヘルスチェックを使用する
本番環境で依存する前に、非本番環境でフェイルオーバーをテストする

確認テスト

このレッスンで扱ったAWS Solutions Architect（SAA-C03）の概念について、理解度を確認しましょう。

レッスンのまとめ

このレッスンでは、次のことを学びました。エンドポイントヘルスチェックは、外部のRoute 53チェッカーからHTTP／HTTPS／TCPをプローブします。CloudWatchアラームヘルスチェックを使用すると、プライベートVPCリソースを監視できます。また、計算済みヘルスチェックは、ブール論理で複数のシグナルを組み合わせます。DNSフェイルオーバーの速度は、ヘルスチェック間隔、失敗しきい値、TTLによって決まります。次は、CloudFrontディストリビューションとオリジンについて学びます。

よくある質問

「ヘルスチェックと DNS フェイルオーバー」レッスンは無料ですか？

はい。「ヘルスチェックと DNS フェイルオーバー」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、AWS Solutions Architectコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 AWS Solutions Architectコースには全4レッスンが含まれています。

「ヘルスチェックと DNS フェイルオーバー」で何を学びますか？

エンドポイント、計算済み、CloudWatch アラームのヘルスチェックを設定し、異常なエンドポイントから自動的にトラフィックを切り替えるよう Route 53 を構成します。ブラウザで直接実行するハンズオンコードでAWS Solutions Architectを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。

AWS Solutions Architectを始めるのに経験は必要ですか？

事前経験は必要ありません。CoddyKitのAWS Solutions Architectは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。これはレッスン4/4です。

「ヘルスチェックと DNS フェイルオーバー」レッスンにはどのくらい時間がかかりますか？

ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。

このAWS Solutions Architectレッスンでコードを書いて実行できますか？

はい。すべてのAWS Solutions Architectレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。

このコースのすべてのレッスン

← AWS Solutions Architectに戻る