Route 53の多彩なルーティングとフェイルオーバー手法
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の中の人が運営しているサークル「じゅ~しぃ~すくりぷと」の本のご案内
技術書コーナー
北海道の駅巡りコーナー