こしあん
2025-01-25

Route 53の多彩なルーティングとフェイルオーバー手法


66{icon} {views}


Amazon Route 53ではフェイルオーバーや複数回答、加重、レイテンシーなどのさまざまなルーティング機能を用いて高可用性を実現できます。NLBやGlobal Acceleratorとの組み合わせを含め、それぞれの特徴や実装方法を整理してみました。

Route 53のフェイルオーバーの整理

o1に以下のように聞いてみる

Route 53のフェイルオーバー時のルーティングを
・フェイルオーバールーティング
・複数回答ルーティング
・加重ルーティング
・レイテンシールーティング
で整理してください。 ただし、リソースはいずれの場合は複数のリージョンにまたがってデプロイされているものとします

ルーティング方式 主な特徴 フェイルオーバー時の動作 適用シナリオ
フェイルオーバールーティング ・プライマリとセカンダリを定義し、明示的に切り替え
・DR構成(Disaster Recovery)に向いている
・プライマリが不健康と判定されると
セカンダリへ切り替えて応答
・障害が復旧した場合はプライマリへ戻す
・明確なプライマリ/セカンダリ構成を取りたい場合
・災害復旧戦略を取りたい場合
複数回答ルーティング ・複数の正常なエンドポイントを同時にDNS応答
・クライアント側がどのエンドポイントを使うか選択する
・不健康なエンドポイントは応答リストから除外
・クライアントは応答された複数IPのうち
どれかへ接続(接続ロジックはクライアント依存)
・複数のリージョンをアクティブ-アクティブで利用したい場合
・クライアントが別のエンドポイントへフォールバックできる設計になっている場合
加重ルーティング ・エンドポイントごとに重みを設定し、割り当て比率でトラフィックを制御
・通常時の負荷分散やカナリアリリースに利用しやすい
・不健康なエンドポイントは自動的にDNS応答から除外
・残った健康なエンドポイントにトラフィックが集中
・障害復旧後は再び加重設定通りに割り振る
・複数のリージョンでトラフィックの割合を制御したい場合
・テストリリースや段階的な移行を行いたい場合
レイテンシールーティング ・クライアントと各リージョン間のレイテンシを考慮し
最も応答が早いリージョンを選択
・不健康なリージョンにはルーティングしない
・正常なリージョンのうち、レイテンシが最も低い場所へ誘導
・世界中のユーザに対して、地理的に最適な
リージョンへ振り分けたい場合
・ユーザ体験を向上するため、遅延を最小化したい場合

Route 53:フェイルオーバールーティング

プライマリの状態 接続元 プライマリ(ap-northeast-1) セカンダリ(us-east-1)
正常 日本
正常 アメリカ
異常 日本
異常 アメリカ
  • 表の見方:プライマリが日本の東京(ap-northeast-1)、セカンダリがアメリカのバージニア(us-east-1)にあるとする
  • プライマリもセカンダリも正常な場合=「プライマリの状態:正常」、プライマリのWebサーバーのEC2を落としてセカンダリだけ正常な場合=「プライマリの状態:異常」
  • 接続元:ap-northeast-1とus-east-1に閲覧用の別のEC2を立てて、curlでサイトを見てどちらにルーティングされるかのテスト
  • ◯がついたほうにルーティングされる
  • Route 53のフェイルオーバールーティングの場合は、接続元に関係なくプライマリ・セカンダリがはっきりしている

Route 53 : 複数回答ルーティング

  • 複数回答ルーティングは、最大8個のIPアドレスを紐づけ、正常な値のみ返すルーティング
  • 複数回答ルーティングはエイリアスレコードが使えなく、固定のIPアドレスのみ。動的なIPなALBでは意味のあるDNSレコードを作成できない。Elastic IPはALBに紐づけることができない
  • ALBをNetwork Load Balancerに置き換えればElastic IPを紐づけられる、ALBのままなら後述のGlobal Acceleratorを使う
  • NLB+Elastic IPでも動くが、ヘルスチェック周りが結構面倒くさいのでおすすめはしない

プライマリの状態 接続元 プライマリ(ap-northeast-1) セカンダリ(us-east-1)
正常 日本
正常 アメリカ
異常 日本
異常 アメリカ
  • NLB自体にACMは割当可能。ここはALBと同じ。ただ、NLBはサブネット単位にElastic IPを振るのでわかりづらい
  • 正常時の挙動は、ランダムにプライマリ・セカンダリに割り振られるというより、交互に割り振られる。連続してcurlを叩いてみると、日本側、アメリカ側の両方で接続しても、プライマリ→セカンダリ→プライマリ→セカンダリとなる(以下の図)。
  • フェイルオーバー時は、NLBとRoute 53でヘルスチェックを正しく設定していれば、セカンダリのほうだけにルーティングされる(ここが結構ハマる)。設定がうまくできないと「(52) Empty reply from server」とずっと表示されてフェイルオーバーできない。「半分の確率で接続失敗する」というのがおこる
  • Route 53のヘルスチェックはTCPリクエストをElastic IPに送るだけだと、EC2が落ちていてもヘルスチェックをすり抜けてしまう(サブネットに足ししてTCP 443が通るを判定しているだけなので)。HTTPSリクエストが通っているかどうかで送る。NLBがレイヤー4で動作するのに、ヘルスチェックはレイヤー7で判定しないといけないのがわかりづらい。

(番外)Global Accelerator

  • ALBのまま複数回答ルーティングっぽいことをやりたい場合の選択肢だが、実際の挙動は複数回答とは結構違う
  • フェイルオーバーはRoute 53でするのではなく、Global Acceleratorで行う。
  • ドメインの紐づけはGlobal Acceleratorとエイリアスレコードを張る。したがってRoute 53は固定のエイリアスに対して名前解決しているだけ

SSLの終端はALBのまま

SSLの終端はどうなるのかというと、ALBのまま。Global AcceleratorはTCP/UDP (レイヤ4)で動作する。

  Client (HTTPS)  
   └─> GA( TCP 443 リスナー, Anycast IP )  
         └─> ALB( HTTPS リスナー, 証明書あり )  
               └─> Backend EC2 など  

フェイルオーバー時の挙動

  • 複数回答ルーティングっぽいことといいつつ、実際はレイテンシールーティングのような挙動になる。これは、Global Acceleratorは最もレイテンシーの低いエッジロケーションにルーティングしているため。
  • 日本から接続したら、ランダムでアメリカ側に飛ばされるということは基本ない
  • フェイルオーバー時の切り替わりはめちゃくちゃ早い。一時的に502や503は出るが、本当に一瞬で切り替わり、Route 53より早い
プライマリの状態 接続元 プライマリ(ap-northeast-1) セカンダリ(us-east-1)
正常 日本
正常 アメリカ
異常 日本
異常 アメリカ

Route 53 : 加重ルーティング

  • 指定した比率でトラフィックを分散したいときに使える。エイリアスレコードが使えて、ALBでも可能
  • フェイルオーバーだけでなく、A/Bテストのユースケースがある。コストさえ見合えば割と使いやすそう
  • たまたまあたりを引いただけかもしれないが、プライマリを落としたときのフェイルオーバーは結構速い。アクティブ・アクティブ構成で、もともとルーティングが確立されているからかもしれない。

プライマリの状態 接続元 プライマリ(ap-northeast-1) セカンダリ(us-east-1)
正常 日本
正常 アメリカ
異常 日本
異常 アメリカ

正常時のトラフィックはどのようにルーティングされるのか

  • 内部の実装がどうなっているのかはよくわからないが、curlを叩いたときに、常にランダムにルーティングされるではないようだ。一定時間のまとまりで同一のリージョンにルーティングされ、少し待ってから連続してcurlを叩くと別なリージョンにルーティングされるようになった。
  • レイテンシーは特に気にしていなく、日本・アメリカの両方の接続元で同じような傾向になった

Route 53 : レイテンシールーティング

  • 最もレイテンシーの低いリージョンにルーティングするもの。アクティブ・アクティブではあるが、正常時にルーティングされるリージョンは確定的。
  • 異常時にフェイルオーバーするときは、もちろん正常なリージョンのみに飛ばすことが可能。
  • Global Acceleratorと似たようなことを、Route 53(DNSレベル)でやっている感じ。こっちのほうがわかりやすい

プライマリの状態 接続元 プライマリ(ap-northeast-1) セカンダリ(us-east-1)
正常 日本
正常 アメリカ
異常 日本
異常 アメリカ

参考:Global Acceleratorとレイテンシールーティングとの違い

ChatGPT(o1)に聞いた結果


AWS Global Accelerator と Amazon Route 53 のレイテンシーベースのルーティング(以下「Route 53 レイテンシールーティング」)は、いずれもエンドユーザーからのアクセスを最適なエンドポイントへ導くためのAWSサービスですが、役割や仕組みに大きな違いがあります。主な相違点は以下のとおりです。

────────────────────────────────────────
1. ルーティングの仕組み (DNSベースかネットワークベースか)
────────────────────────────────────────
■ Route 53 (レイテンシールーティング)
・DNSレベルでの制御
Route 53 は「DNSベース」でのルーティングです。ユーザーがドメイン名を引く際に、最もレイテンシーが低い(通信速度が速い)と思われるリージョンのエンドポイントを返します。
・DNSキャッシュの影響
DNS解決はユーザー端末やISPのDNSサーバーによりキャッシュされるため、短時間で接続先リージョンを切り替える必要があっても、TTL(有効期限)が切れるまで変更が反映されにくいという特徴があります。

■ AWS Global Accelerator
・グローバルなAWSネットワークへの乗り入れ
Global Accelerator は「ネットワークベース」での制御です。エンドユーザーは Global Accelerator が提供する“固定のグローバルIPアドレス”に接続し、その入口となるエッジロケーション(AWSエッジ)からAWSのグローバルバックボーンネットワークを経由して最適なリージョンのエンドポイントへトラフィックが転送されます。
・リアルタイムに近い経路最適化・自動フェイルオーバー
ネットワークレイヤーで経路を動的に最適化し、障害があれば別のリージョンへ素早く自動フェイルオーバーします。DNSキャッシュの影響を受けにくいため、レイテンシーの変動や障害に対して即座に対応しやすいというメリットがあります。

────────────────────────────────────────
2. 導入形態・エンドポイント設定の違い
────────────────────────────────────────
■ Route 53 (レイテンシールーティング)
・多様なルーティングポリシー
レイテンシーベース以外にも、地理的ルーティング(Geo Location)、加重(Weighted)やフェイルオーバーポリシーなど、多彩なDNSルーティングが可能です。
・設定は「ドメイン名」と「各リージョンのエンドポイント」を紐付ける形
例: example.com にアクセスしたとき、最も近いリージョンAのELBを返すか、リージョンBのELBを返すか、といった形でDNS応答を切り替えます。

■ AWS Global Accelerator
・固定IPアドレスが利用可能
Route 53 のようにエンドユーザーにホスト名を解決させるのではなく、“Global Accelerator専用の静的グローバルIP”を割り当て、そこに対してルーティングを行います。
・アプリケーションへの接続をAWSネットワークで高速化
ユーザーは常に同じIPアドレスにアクセスし、Global Accelerator がユーザーに最も近いエッジロケーションを自動的に選択してくれます。その後、AWSのバックボーン網を介してターゲットのリージョンへトラフィックを転送します。

────────────────────────────────────────
3. レイテンシー・可用性への影響
────────────────────────────────────────
■ Route 53 (レイテンシールーティング)
・DNS解決時のルーティングのみ
一度DNSで解決されたエンドポイントに接続が確立されると、ユーザーは基本的にそのエンドポイントを使い続けます。TTLが切れるまでは同じリージョンを利用し続けることが多いです。
・フェイルオーバーの速度はDNSのTTLに左右される
ローTTL(短めのTTL設定)を活用することである程度は早めに切り替えられますが、Global Acceleratorほどリアルタイムには切り替えられません。

■ AWS Global Accelerator
・ネットワーク経路の動的変更と高速フェイルオーバー
DNSに依存しないため、万一リージョンの障害やネットワーク状況が悪化していても、Global Accelerator 側で迅速に別の正常なエンドポイントへ振り替えます。
・AWSバックボーンの利用による低レイテンシー
インターネットのパブリック区間を最小化して、可能な限りAWSのバックボーンネットワークを利用することで、安定したレイテンシーとスループットが期待できます。

────────────────────────────────────────
4. 主なユースケース
────────────────────────────────────────
■ Route 53 (レイテンシールーティング)
・DNSレベルでのグローバルヘルスチェック・ルーティング分岐が必要なケース
・既存のDNSレコードを活用しながらリージョンごとに細かいポリシーを設定したいケース
・サービスの特性上、DNSを切り替えるだけでも十分な応答性能を得られる場合

■ AWS Global Accelerator
・リアルタイムの経路最適化および可能な限り低いレイテンシーを求めるケース
・一度割り当てた固定IPを変えずに、バックエンドを柔軟に切り替えたいケース
・AWSバックボーンを使った高速グローバル通信でサイトやアプリケーションの応答性能を向上させたいケース
・障害発生時のリージョン切り替えをより迅速に行いたいケース

────────────────────────────────────────
■ まとめ
────────────────────────────────────────
• Route 53 のレイテンシーベースルーティングは、DNS レベルでエンドユーザーに最適なリージョンのエンドポイントを返す仕組みです。DNSを使った様々なルーティングポリシーを利用できますが、DNSキャッシュの影響を受けるため、切り替えには多少の時間がかかります。
• AWS Global Accelerator は、グローバルなエッジネットワークとバックボーンを使ってネットワークレベルでユーザーを最適なエンドポイントへ導きます。DNSのTTLに依存せず、リアルタイムに近い形でレイテンシー向上やフェイルオーバーが可能です。

要件やアプリケーションの性質(リアルタイム性の重要度、大規模トラフィック、既存のDNS運用ルールなど)を踏まえて、Route 53 のレイテンシールーティングを使うか、AWS Global Acceleratorを使うか、あるいは併用するか検討するとよいでしょう。


実装

Route 53:フェイルオーバールーティング

Route 53を使ったマルチリージョンのフェイルオーバーを試すを参照

Route 53 : 複数回答ルーティング

Route 53を使ったマルチリージョンのフェイルオーバーを試すをから以下の変更を加える

ec2.tf。NLBはセキュリティグループを持てないので、全部のIPからの80を許可するように変更する。

resource "aws_security_group" "web_sg_primary" {
  name   = "web-sg-primary"
  vpc_id = module.vpc_primary.vpc_id

  # NLB からの 80 番受け取り
  ingress {
    description      = "Allow HTTP from NLB"
    from_port        = 80
    to_port          = 80
    protocol         = "tcp"
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }

  # Session Manager 用に通信を制限したい場合は SSM 関連エンドポイントの SG と紐付けるなど検討
  egress {
    from_port        = 0
    to_port          = 0
    protocol         = -1
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }
}

resource "aws_security_group" "web_sg_secondary" {
  provider = aws.secondary
  name     = "web-sg-secondary"
  vpc_id   = module.vpc_secondary.vpc_id

  ingress {
    description      = "Allow HTTP from NLB"
    from_port        = 80
    to_port          = 80
    protocol         = "tcp"
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }

  egress {
    from_port        = 0
    to_port          = 0
    protocol         = -1
    cidr_blocks      = ["0.0.0.0/0"]
    ipv6_cidr_blocks = ["::/0"]
  }
}

alb.tfを削除し、nlb.tfを以下のように定義する。サブネットマッピングがALBと異なる点。ターゲットグループにアタッチするのは同様にEC2。ここが初見だとわかりづらい。

# ────────────────────────────────────────────────────────
# 1) EIP (NLB 用) を作成
# ────────────────────────────────────────────────────────
# 1AZ 分のサブネットに対してEIP を発行。
resource "aws_eip" "nlb_eip_primary" {
  domain = "vpc"
}

resource "aws_eip" "nlb_eip_secondary" {
  provider = aws.secondary
  domain   = "vpc"
}

# ────────────────────────────────────────────────────────
# 2) NLB を作成して Elastic IP を紐づけ
# ────────────────────────────────────────────────────────
resource "aws_lb" "nlb_primary" {
  name               = "nlb-primary-sample"
  load_balancer_type = "network"

  # サブネットと紐づける際に EIP(Allocation ID)を割り当て
  subnet_mapping {
    subnet_id     = module.vpc_primary.public_subnet_ids[0]
    allocation_id = aws_eip.nlb_eip_primary.id
  }

  # NLB は Security Group を紐づけずに (VPC の Network ACL で制御)
  # cross_zone_load_balancing_enabled や他オプションは任意で追加
}

resource "aws_lb" "nlb_secondary" {
  provider           = aws.secondary
  name               = "nlb-secondary-sample"
  load_balancer_type = "network"

  subnet_mapping {
    subnet_id     = module.vpc_secondary.public_subnet_ids[0]
    allocation_id = aws_eip.nlb_eip_secondary.id
  }
}

# ────────────────────────────────────────────────────────
# 3) ターゲットグループ (バックエンドへの転送)
# ────────────────────────────────────────────────────────
resource "aws_lb_target_group" "nlb_primary_tg" {
  name        = "nlb-primary-tg-sample"
  port        = 80
  protocol    = "TCP" # バックエンドにそのまま TCP で転送
  vpc_id      = module.vpc_primary.vpc_id
  target_type = "instance" # 例: EC2 をぶら下げる場合

  health_check {
    protocol            = "TCP"
    port                = "80"
    interval            = 30
    timeout             = 5
    healthy_threshold   = 3
    unhealthy_threshold = 3
  }
}

resource "aws_lb_target_group" "nlb_secondary_tg" {
  provider    = aws.secondary
  name        = "nlb-secondary-tg-sample"
  port        = 80
  protocol    = "TCP"
  vpc_id      = module.vpc_secondary.vpc_id
  target_type = "instance"

  health_check {
    protocol            = "TCP"
    port                = "80"
    interval            = 30
    timeout             = 5
    healthy_threshold   = 3
    unhealthy_threshold = 3
  }
}

# ────────────────────────────────────────────────────────
# 4) EC2 をターゲットグループに紐づける
# ────────────────────────────────────────────────────────
# Primary側 EC2
resource "aws_lb_target_group_attachment" "nlb_primary_tg_attach" {
  target_group_arn = aws_lb_target_group.nlb_primary_tg.arn
  target_id        = aws_instance.web_primary.id   # EC2インスタンスのID
  port             = 80
}

# Secondary側 EC2
resource "aws_lb_target_group_attachment" "nlb_secondary_tg_attach" {
  provider         = aws.secondary
  target_group_arn = aws_lb_target_group.nlb_secondary_tg.arn
  target_id        = aws_instance.web_secondary.id
  port             = 80
}

# ────────────────────────────────────────────────────────
# 5) TLS Listener で ACM 証明書を読み込む
# ────────────────────────────────────────────────────────
resource "aws_lb_listener" "tls_primary_443" {
  load_balancer_arn = aws_lb.nlb_primary.arn
  port              = 443
  protocol          = "TLS"
  certificate_arn   = var.acm_certificate_arn_primary # ここに ACM の ARN

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.nlb_primary_tg.arn
  }
}

resource "aws_lb_listener" "tls_secondary_443" {
  provider          = aws.secondary
  load_balancer_arn = aws_lb.nlb_secondary.arn
  port              = 443
  protocol          = "TLS"
  certificate_arn   = var.acm_certificate_arn_secondary

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.nlb_secondary_tg.arn
  }
}

route_53.tfを以下のように変更する。ヘルスチェックはHTTPSで送り、Elastic IPのアドレスに対して送る。TCPだとうまくいかない。

複数回答ルーティングのレコードは、1個のDNSレコードに対して複数のレコードを登録するのではなく、複数のDNSレコードを定義するのでOK。これでよしなにルーティングされる。

# ────────────────────────────────────────────────────────
# (1) Hosted Zone の取得
# ────────────────────────────────────────────────────────
data "aws_route53_zone" "main" {
  name         = var.hosted_zone_name
  private_zone = false
}

# ────────────────────────────────────────────────────────
# (2) NLB の EIP に対して Route53 ヘルスチェックを作成
# ────────────────────────────────────────────────────────
# NLB (primary) 用のEIPに対するHTTPSヘルスチェック (エラーが出ないかどうか)
# TCPで443が開いているかだとすり抜ける
resource "aws_route53_health_check" "primary" {
  type              = "HTTPS"
  port              = 443
  resource_path     = "/"               # バックエンドが応答できるパス
  ip_address        = aws_eip.nlb_eip_primary.public_ip
  request_interval  = 10                # なるべく短い方が早い検知
  failure_threshold = 3
  # use_sni = true (証明書のCN/SAN が合致するなら)
}

# NLB (secondary) 用のEIPに対するTCPヘルスチェック
resource "aws_route53_health_check" "secondary" {
  provider          = aws.secondary
  type              = "HTTPS"
  port              = 443
  resource_path     = "/"               # バックエンドが応答できるパス
  ip_address        = aws_eip.nlb_eip_secondary.public_ip
  request_interval  = 10                # なるべく短い方が早い検知
  failure_threshold = 3
}

# ────────────────────────────────────────────────────────
# (3) Route53: マルチバリューアンサールーティング で A レコードを2つ登録
# ────────────────────────────────────────────────────────
resource "aws_route53_record" "multi_value_primary" {
  zone_id                          = data.aws_route53_zone.main.zone_id
  name                             = var.record_name # 例: "www"
  type                             = "A"
  set_identifier                   = "multivalue_answer_routing_policy_primary"
  multivalue_answer_routing_policy = true
  health_check_id                  = aws_route53_health_check.primary.id
  ttl                              = 60

  records = [
    aws_eip.nlb_eip_primary.public_ip
  ]
}

# secondary 用レコード
resource "aws_route53_record" "multi_value_secondary" {
  zone_id                          = data.aws_route53_zone.main.zone_id
  name                             = var.record_name
  type                             = "A"
  set_identifier                   = "multivalue_answer_routing_policy_secondary"
  multivalue_answer_routing_policy = true
  health_check_id                  = aws_route53_health_check.secondary.id
  ttl                              = 60

  records = [
    aws_eip.nlb_eip_secondary.public_ip
  ]
}

(番外)Global Accelerator

Route 53を使ったマルチリージョンのフェイルオーバーを試すをから以下の変更を加える

global_accelerator.tfに以下を追加

# 1. Global Accelerator の作成
resource "aws_globalaccelerator_accelerator" "example" {
  name            = "example-accelerator"
  ip_address_type = "IPV4"
  enabled         = true
}

# 2. GA のリスナー (TCP 80/443 を転送する例)
resource "aws_globalaccelerator_listener" "example" {
  accelerator_arn = aws_globalaccelerator_accelerator.example.id
  protocol        = "TCP"

  # HTTP(80)とHTTPS(443)の2つのポート範囲を指定
  port_range {
    from_port = 80
    to_port   = 80
  }
  port_range {
    from_port = 443
    to_port   = 443
  }

  # 必要に応じて設定 (クライアントアフィニティなど)
  client_affinity = "NONE"
}

# 3. Endpoint Group (リージョン単位で分けるのが一般的)
#   ap-northeast-1 用
resource "aws_globalaccelerator_endpoint_group" "primary" {
  listener_arn          = aws_globalaccelerator_listener.example.arn
  endpoint_group_region = "ap-northeast-1"

  # GA が行うヘルスチェック設定 (デフォルトHTTPSなどに変更可)
  health_check_path     = "/"
  health_check_port     = 80
  health_check_protocol = "HTTP"

  endpoint_configuration {
    # ALB の ARN を指定
    # (例: aws_lb.alb_primary.arn など)
    endpoint_id = aws_lb.alb_primary.arn
    weight      = 100
  }
}

#   us-east-1 用
resource "aws_globalaccelerator_endpoint_group" "secondary" {
  listener_arn          = aws_globalaccelerator_listener.example.arn
  endpoint_group_region = "us-east-1"

  health_check_path     = "/"
  health_check_port     = 80
  health_check_protocol = "HTTP"

  endpoint_configuration {
    endpoint_id = aws_lb.alb_secondary.arn
    weight      = 100
  }
}

route_53.tfを以下に変更

# --------------------------------------------------------------------------------
# 既存の Hosted Zone を取得 (あるいは新規作成でもOK)
# --------------------------------------------------------------------------------
data "aws_route53_zone" "main" {
  name         = var.hosted_zone_name
  private_zone = false
}

# Route53 から Global Accelerator を参照する
resource "aws_route53_record" "ga_alias" {
  zone_id = data.aws_route53_zone.main.zone_id
  name    = var.record_name
  type    = "A"

  # Global Accelerator の DNS 名とホストゾーンIDを alias として指定
  alias {
    name                   = aws_globalaccelerator_accelerator.example.dns_name
    zone_id                = aws_globalaccelerator_accelerator.example.hosted_zone_id
    evaluate_target_health = false
  }
}

Route 53 : 加重ルーティング

Route 53を使ったマルチリージョンのフェイルオーバーを試すをから以下の変更を加える

route_53.tfの変更だけでOK

# --------------------------------------------------------------------------------
# Route53 のHosted Zone は既存を仮定 (あるいは新規作成でもOK)
# data で取得したり、resource で作成したりする
# --------------------------------------------------------------------------------
data "aws_route53_zone" "main" {
  # 既存のドメインを使う例
  name         = var.hosted_zone_name
  private_zone = false
}

# --------------------------------------------------------------------------------
# ヘルスチェック (Weighted でも使用可能)
# --------------------------------------------------------------------------------
resource "aws_route53_health_check" "primary" {
  # ALB Primary に対する HTTP ヘルスチェック
  type              = "HTTP"
  resource_path     = "/"
  fqdn              = aws_lb.alb_primary.dns_name
  port              = 80
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_health_check" "secondary" {
  # ALB Secondary に対する HTTP ヘルスチェック
  type              = "HTTP"
  resource_path     = "/"
  fqdn              = aws_lb.alb_secondary.dns_name
  port              = 80
  failure_threshold = 3
  request_interval  = 30
}

# --------------------------------------------------------------------------------
# 加重ルーティング用レコード: Primary
# --------------------------------------------------------------------------------
resource "aws_route53_record" "weighted_primary" {
  zone_id = data.aws_route53_zone.main.zone_id
  name    = var.record_name # 例: "www"
  type    = "A"

  set_identifier  = "primary"
  health_check_id = aws_route53_health_check.primary.id

  weighted_routing_policy {
    weight = 50
  }

  alias {
    name                   = aws_lb.alb_primary.dns_name
    zone_id                = aws_lb.alb_primary.zone_id
    evaluate_target_health = true
  }
}

# --------------------------------------------------------------------------------
# 加重ルーティング用レコード: Secondary
# --------------------------------------------------------------------------------
resource "aws_route53_record" "weighted_secondary" {
  zone_id = data.aws_route53_zone.main.zone_id
  name    = var.record_name
  type    = "A"

  set_identifier  = "secondary"
  health_check_id = aws_route53_health_check.secondary.id

  weighted_routing_policy {
    weight = 50
  }

  alias {
    name                   = aws_lb.alb_secondary.dns_name
    zone_id                = aws_lb.alb_secondary.zone_id
    evaluate_target_health = true
  }
}

Route 53 : レイテンシールーティング

Route 53を使ったマルチリージョンのフェイルオーバーを試すをから以下の変更を加える

route_53.tfの変更だけでOK

# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Route53 のHosted Zone は既存を仮定 (あるいは新規作成でもOK)
# data で取得したり、resource で作成したりする
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
data "aws_route53_zone" "main" {
  # 既存のドメインを使う例
  name         = var.hosted_zone_name
  private_zone = false
}

# ヘルスチェック (レイテンシールーティングでも利用可能)
resource "aws_route53_health_check" "primary" {
  type              = "HTTP"
  resource_path     = "/"
  fqdn              = aws_lb.alb_primary.dns_name
  port              = 80
  failure_threshold = 3
  request_interval  = 30
}

resource "aws_route53_health_check" "secondary" {
  type              = "HTTP"
  resource_path     = "/"
  fqdn              = aws_lb.alb_secondary.dns_name
  port              = 80
  failure_threshold = 3
  request_interval  = 30
}

# レイテンシールーティング用 レコード: Primary (例として ap-northeast-1)
resource "aws_route53_record" "latency_primary" {
  zone_id        = data.aws_route53_zone.main.zone_id
  name           = var.record_name  # 例: "www"
  type           = "A"
  set_identifier = "ap-northeast-1" # 識別子(任意)

  health_check_id = aws_route53_health_check.primary.id

  latency_routing_policy {
    # 実際に ALB があるリージョンを指定
    region = "ap-northeast-1"
  }

  alias {
    name                   = aws_lb.alb_primary.dns_name
    zone_id                = aws_lb.alb_primary.zone_id
    evaluate_target_health = true
  }
}

# レイテンシールーティング用 レコード: Secondary (例として us-east-1)
resource "aws_route53_record" "latency_secondary" {
  zone_id        = data.aws_route53_zone.main.zone_id
  name           = var.record_name
  type           = "A"
  set_identifier = "us-east-1"      # 識別子(任意)

  health_check_id = aws_route53_health_check.secondary.id

  latency_routing_policy {
    # 実際に ALB があるリージョンを指定
    region = "us-east-1"
  }

  alias {
    name                   = aws_lb.alb_secondary.dns_name
    zone_id                = aws_lb.alb_secondary.zone_id
    evaluate_target_health = true
  }
}

所感

  • Route 53がだいぶわかった!
  • 複数回答でエイリアスレコード使えないのは初めて知った。NLBは思ったより玄人向けだった


Shikoan's ML Blogの中の人が運営しているサークル「じゅ~しぃ~すくりぷと」の本のご案内

技術書コーナー

北海道の駅巡りコーナー


Add a Comment

メールアドレスが公開されることはありません。 が付いている欄は必須項目です