🌏

CloudFrontのCNAMEレコードをAWSアカウント間でダウンタイムなしで移行する手順

に公開

概要

異なる2つのAWSアカウントに存在するCloudFront(CF)ディストリビューション間で代替ドメイン名(CNAMEレコード)をダウンタイムなしで移行する方法について解説します。
ワイルドカード(*.example.com)を先に移行先ディストリビューションに追加し、その後 DNS と移行元側の具体的な CNAME(www.example.com)を切り替える手順について詳しく紹介します。

対象読者

  • CloudFrontのアカウント間移行に伴って、CNMAEレコードも移行する方
  • CNAMEの向き先変更すれば移行出来るのは知っているけど、ダウンタイムをゼロにしたい方

前提条件

  • CFのオリジンは移行元と移行先で同等の設定をしていること
  • 有効な証明書は事前に移行先のAWSアカウント側に用意していること

手順

それでは早速手順を見ていきましょう。

初期状態

  • 例としてwww.example.com を移行します
  • 移行元(Source)にはwww.example.comがCNAMEとして設定されており、www.example.comは移行元のCloudFrontのDNS名に名前解決されており、当然リクエストも移行元にルーティングされてれいます
  • 移行先(Target)は移行先のアカウント内でCFを作成し、オリジンの設定など済んでおりCNAME以外の設定は完了している状態

① ワイルドカード付きのCNAMEをターゲットCFに追加する

  • ターゲットCFにワイルドカードドメインの*.example.com を追加
  • ワイルドカードは www.example.com と競合しないため、追加しても"CNAMEAlreadyExists"のエラーには当然ならず、問題なし

② DNSをターゲットCFに向ける

  • www.example.com のDNSをターゲットのCFに向ける
  • この時点では、リクエストはまだ旧ディストリビューションへルーティングされている(理由は下記なぜこの方法でダウンタイムが発生しないのか?、のセクションで詳しく解説)

注意点

既存の www.example.com レコードの DNS TTL が切れない限り、一部クライアントのキャッシュに古い向き先情報が残り、最大 TTL 期間中は旧ディストリビューションにリクエストが送られ続ける可能性があります。作業前に十分にTTLを短く設定しておくことを推奨します。

③ ソースCFからCNAMEを削除する

  • ソース側CFから www.example.com を削除
  • CloudFrontは www.example.com のルーティング先として *.example.com にマッチし、ターゲットCFへ切り替え。この時点からTargetにリクエストが到達する

④ ターゲットCFに www.example.com を追加する

  • ソース側から削除されたため、ターゲットCFでも www.example.com を登録できるようになる

⑤ (任意)ターゲットCFから *.example.com を削除する

  • ソースCFは不要になる
  • ターゲットCFのワイルドカードドメインも設定は不要になるので、整理したい場合は削除する

なぜこの方法でダウンタイムが発生しないのか?

AWSの公式ドキュメントに以下のような記載がある通り、CloudFrontのルーティング仕様により、より具体的な名前が一致する代替ドメイン名へ優先してリクエストが転送されるためです

2 つのディストリビューションで代替ドメイン名が重複している場合、CloudFront は、DNS レコードが指しているディストリビューションに関係なく、より具体的な名前が一致しているディストリビューションにリクエストを送信します。

https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html

つまり、手順②の際にDNSで www.example.com がターゲットCFに向いていたとしても、CloudFront側で www.example.com がソースCFに設定されていれば、そちらが使用されます。

ワイルドカード(例:*.example.com)はあくまでフォールバックとして動作し、CloudFrontが具体的な www.example.com を持たなくなった瞬間に自動的にルーティングが切り替わるため、ダウンタイムが発生しません。

まとめ

CloudFrontのルーティングの仕様を適切に利用することで、アカウント間でCloudFrontを移行する際のDNSの切り替えやCloudFront設定変更の作業の際に発生するダウンタイムをゼロにできます。
そう多くは発生しない作業だと思いますが、よろしければご参考にどうぞ!

参考記事

  • CNAMEAlreadyExistsのエラー回避方法についての包括的な記情報は以下記事が分かりやすいです。フロー図のワイルドカードCNAMEを経由してつけ替え、の部分の具体的な手法について記載しました。

https://dev.classmethod.jp/articles/cloudfront-cnamealreadyexists-fix-flowchart/#toc-

  • 同一AWSアカウント内のCloudFrontでCNAMEの移行を実施する場合はこちらの記事が参考になると思います。

https://dev.classmethod.jp/articles/atomic-swap-cloudfront-cname/

Accenture Japan (有志)

Discussion