SW BBANG J

本番EC2インスタンスが深夜に突然ダウンした経験があるなら、DNSフェイルオーバーの重要性は身に染みているはずだ。Route 53のヘルスチェックとフェイルオーバールーティングを組み合わせれば、EC2が応答しなくなった瞬間にS3の静的サイトへ自動的にトラフィックを切り替えられる。このガイドでは、 Route 53 DNSフェイルオーバー の仕組みから実際の設定手順まで、プロダクション環境で使える形で解説する。 TL;DR：Route 53 DNSフェイルオーバーの全体像 項目 内容 目的 EC2障害時にS3静的サイトへ自動DNS切り替え 主要コンポーネント Route 53ヘルスチェック、フェイルオーバールーティングポリシー、S3静的ウェブサイトホスティング 切り替えの目安 ヘルスチェック失敗判定後、TTL経過で切り替わる（TTL設定値に依存） 必要なレコードタイプ PRIMARY（EC2向け）とSECONDARY（S3向け）の2レコード コスト要因 ヘルスチェック料金、Route 53クエリ料金（最新料金は公式ドキュメント参照） 主な注意点 S3静的ウェブサイトエンドポイントはHTTPSを直接サポートしない Route 53フェイルオーバーの仕組み フェイルオーバールーティングポリシーは、レコードをPRIMARYとSECONDARYの2種類に分類する。Route 53はPRIMARYレコードに紐付けられたヘルスチェックを定期的に実行し、失敗と判定した場合にSECONDARYレコードを返すよう切り替える。ヘルスチェックはRoute 53のグローバルなヘルスチェッカーネットワークから実行されるため、単一リージョンの問題ではなく、広域での到達不能を検知する。 重要なのは、DNS応答の切り替えはTTLに依存するという点だ。ヘルスチェックが失敗を検知してもTTLが長ければ、クライアントはキャッシュされた古いIPアドレスを使い続ける。フェイルオーバーの応答速度を重視するなら、TTLを低く設定する必要がある。ただし、TTLを下げるとRoute 53へのクエリ頻度が上がり、コストに影...

ALBをデプロイしてドメインを向けようとしたとき、多くのエンジニアが最初にCNAMEレコードを設定しようとする。しかし example.com のようなゾーンの頂点（Zone Apex）でCNAMEを設定しようとすると、Route 53のコンソールがそれを拒否する。これはDNS仕様の制約であり、Route 53の Aliasレコード がその解決策として設計されている。 TL;DR — AliasとCNAMEの比較 比較軸 CNAMEレコード Route 53 Aliasレコード ゾーンの頂点（example.com）での使用 ❌ 不可（RFC 1034制約） ✅ 可能 DNSクエリ料金 通常のクエリ料金が発生 Route 53リソースへのクエリは無料 TTL制御 任意に設定可能 Route 53が自動管理（設定不可） ヘルスチェック統合 制限あり ターゲットリソースのヘルスチェックと統合可能 IPアドレスの自動追従 不可（CNAMEが指すホスト名のAレコードに依存） ALBのIPが変わっても自動的に追従 対応ターゲット 任意のホスト名 ALB、CloudFront、S3、API Gatewayなど特定AWSリソース Route 53 AliasレコードとCNAMEレコードの仕組み CNAMEレコードはDNSの標準機能で、あるホスト名を別のホスト名に対応付ける。クライアントがCNAMEを解決するとき、DNSリゾルバーは最終的なAレコード（IPアドレス）に到達するまで複数回のクエリを実行する。この仕組み自体は問題ないが、RFC 1034の規定により、ゾーンの頂点（ネイキッドドメイン）にはCNAMEを設定できない。ゾーンの頂点にはSOAレコードとNSレコードが必ず存在しなければならず、CNAMEは他のレコードと共存できないためだ。 Route 53のAliasレコードはAWSが独自に実装したDNS拡張機能で、外部から見るとAレコード（またはAAAAレコード）として振る舞う。Route 53の権威DNSサーバーがAliasを解決するとき、ターゲットリソース（ALBなど）の現在...