Route53ヘルスチェックとフェイルオーバー設計 — 自動DNS切り替え

Route53ヘルスチェックの種類

Route53は3種類のヘルスチェックを提供する。

1. エンドポイントヘルスチェック:
   → HTTP/HTTPS/TCPでエンドポイントを直接監視
   → 世界中のRoute53ヘルスチェッカーから監視

2. 計算ヘルスチェック（Calculated）:
   → 複数のヘルスチェックを論理演算（AND/OR）で組み合わせ
   → 子ヘルスチェックのX/Y以上が正常なら正常とみなす

3. CloudWatchアラームに基づくヘルスチェック:
   → CloudWatchアラームの状態を参照
   → VPC内のプライベートリソースのヘルスチェックに利用

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

# HTTPヘルスチェックの作成
aws route53 create-health-check \
  --caller-reference "my-health-check-001" \
  --health-check-config '{
    "Type": "HTTP",
    "IPAddress": "203.0.113.10",
    "Port": 80,
    "ResourcePath": "/health",
    "FullyQualifiedDomainName": "api.example.com",
    "RequestInterval": 30,
    "FailureThreshold": 3,
    "MeasureLatency": true
  }'

設定パラメータ:
  RequestInterval: 30秒（標準）または 10秒（高速、料金高）
  FailureThreshold: 連続失敗回数（1〜10、デフォルト3）
  ResourcePath: ヘルスチェック対象のパス（例: /health）
  
判定の仕組み:
  Route53は世界中の複数ロケーションからチェック
  → 18以上のロケーションが監視
  → 「健全」判定: 監視ロケーションの18%以上が成功と判定

フェイルオーバールーティング

プライマリが障害時にセカンダリに自動切り替えする。

# プライマリレコードの作成（フェイルオーバー: PRIMARY）
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "A",
        "SetIdentifier": "primary",
        "Failover": "PRIMARY",
        "TTL": 60,
        "ResourceRecords": [{"Value": "203.0.113.10"}],
        "HealthCheckId": "HEALTH_CHECK_ID"
      }
    }]
  }'

# セカンダリレコード（フェイルオーバー: SECONDARY）
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "CREATE",
      "ResourceRecordSet": {
        "Name": "api.example.com",
        "Type": "A",
        "SetIdentifier": "secondary",
        "Failover": "SECONDARY",
        "TTL": 60,
        "ResourceRecords": [{"Value": "203.0.113.20"}]
      }
    }]
  }'

フェイルオーバーの動作:
  正常時: PRIMARY レコードを返す
  障害時（ヘルスチェック失敗）: SECONDARY レコードを返す
  セカンダリにはヘルスチェック不要（SECONDARYはフォールバック先）
  
注意: TTLが60秒の場合、切り替えに最大60秒かかる
      高速なフェイルオーバーには低TTL（10〜30秒）を使う

プライベートリソースへのヘルスチェック

Route53のヘルスチェッカーはパブリックIPからアクセスするため、VPC内のプライベートリソースは直接監視できない。

解決策: CloudWatchアラームベースのヘルスチェック

プライベートEC2/RDS → CloudWatchメトリクス
   ↓ （アラーム）
CloudWatch Alarm → Route53ヘルスチェック（アラーム状態参照）
   ↓
Route53がDNSフェイルオーバー

設定手順:
1. EC2インスタンスにCloudWatch Agentを設定
2. 該当メトリクスにアラームを作成
3. Route53ヘルスチェックでアラームを参照
4. フェイルオーバーレコードにヘルスチェックを紐付け

# CloudWatchアラームに基づくヘルスチェックの作成
aws route53 create-health-check \
  --caller-reference "private-resource-check" \
  --health-check-config '{
    "Type": "CLOUDWATCH_METRIC",
    "CloudWatchAlarmConfiguration": {
      "EvaluationPeriods": 1,
      "Threshold": 1,
      "ComparisonOperator": "GreaterThanOrEqualToThreshold",
      "Period": 60,
      "MetricName": "UnhealthyHostCount",
      "Namespace": "AWS/ApplicationELB",
      "Statistic": "Average",
      "Dimensions": [{
        "Name": "TargetGroup",
        "Value": "targetgroup/my-tg/xxx"
      }],
      "Region": "ap-northeast-1"
    }
  }'

計算ヘルスチェック（Calculated Health Check）

複数チェックを組み合わせる複雑な正常性評価に使う。

ユースケース:
  アプリの全体的な健全性を複数チェックで評価
  
  例:
  - Web サーバーチェック（3台中2台以上が正常）
  - DBチェック（プライマリが正常）
  - キャッシュチェック（Redisが正常）
  → 上記3チェックがすべて正常な場合のみ「健全」

SNS通知との連携

ヘルスチェック失敗時にアラートを送信する。

# ヘルスチェック失敗時のSNS通知
aws cloudwatch put-metric-alarm \
  --alarm-name "Route53-HealthCheck-Failure" \
  --metric-name "HealthCheckStatus" \
  --namespace "AWS/Route53" \
  --statistic "Minimum" \
  --period 60 \
  --threshold 1 \
  --comparison-operator "LessThanThreshold" \
  --evaluation-periods 1 \
  --dimensions Name=HealthCheckId,Value=HEALTH_CHECK_ID \
  --alarm-actions arn:aws:sns:us-east-1:123456789012:alert-topic

注意: Route53ヘルスチェックのメトリクスは us-east-1 リージョンにのみ存在する。

試験頻出ポイント

シナリオ	回答
プライベートEC2のヘルスチェック	CloudWatchアラームベースのヘルスチェック
プライマリ障害時に自動でセカンダリへ	フェイルオーバールーティング
複数チェックを組み合わせた判定	計算ヘルスチェック（Calculated）
ヘルスチェックのメトリクスリージョン	常に us-east-1
セカンダリにヘルスチェックは必要か	不要（SECONDARYはフォールバック先）

まとめ

Route53ヘルスチェックはエンドポイント、計算、CloudWatchアラームの3種類があり、VPC内プライベートリソースにはCloudWatchアラームベースを使う。フェイルオーバールーティングと組み合わせることで自動DNS切り替えを実現できる。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感