こんにちは。ES課で研修中の田原です。
以前にSorryページの構成検討を考えるブログを執筆しましたが、 今回はその中でも一般的な構成である「Route53 フェイルオーバールーティング」の実装方法をこちらでご紹介致します。
※2024/10時点の構築手順となります。アップデート等で変更になっている個所は適宜読み替えを実施してください。
※Sorryページの各構成の構成概要やメリット・デメリットの紹介については、「AWSにおけるSorryページ構成について考えてみた」の前回のブログをご参照ください。
- 最終構成と前提について
- 構築の流れについて
- ステップ①：ベーシック構成のCloudFormationでのデプロイ
- ステップ②：手動でのベーシック構成の最終セットアップ
- ステップ③：Sorryページ用S3の構築
- ステップ④：Sorryページ用CloudFrontの構築
- ステップ⑤：Route53のフェイルオーバルーティングの構築
- 動作確認
- お片付け（作成リソースの削除）
- まとめ
最終構成と前提について
・今回構築する「Route53 フェイルオーバールーティング」の最終構成は以下です。（赤文字箇所が、Sorryページに関わる構成要素となります。）
・以前のブログ同様、「HTTPS」通信を必須とした「ALBとEC2を用いたベーシックな構成」を前提としたSorryページを実装を行います。
・作業の前提として、ALBへの接続やACM証明書に登録をおこなうための「名前解決使用するドメイン名は事前に取得できている」事を前提と致します。 （今回は、Route53で既にドメイン取得済み・ホストゾーンの登録済みの状態からスタートすることを想定しています。）
・本検証に準備した、「事前準備したドメイン名」と「構築予定のサブドメイン」は以下となります。
- hiroki.tahara.ie.serverworks.tech ： 事前準備したドメイン名です。Route53にホストゾーンとして登録済みとなります
- www.hiroki.tahara.ie.serverworks.tech ： 正常時のALBの接続用・フェイルオーバー時のCloudFront接続用として、Route53に「www」をサブドメインのレコード設定をおこなっていきます
構築の流れについて
以下が構築の全体像となります。5つのステップを踏んで構築を進めていきます。
| ステップ | 概要 | 対応内容 |
|---|---|---|
| 1 | ベーシック構成のCloudFormationでのデプロイ | 「ALBとEC2を用いたベーシックな構成」を事前準備のCloudFormationでデプロイします（VPC、SecurityGroup、EC2、ALB一部の構築が含まれます） |
| 2 | 手動でのベーシック構成の最終セットアップ | ステップ①のCloudFormationでは作成されていない「ALBとEC2を用いたベーシックな構成」の、ACM証明書発行、Route53のレコード登録、ALBリスナー作成を手動で最終セットアップします |
| 3 | Sorryページ用S3の構築 | Sorryページ用S3の作成とSorryページのHTMLをアップロードします |
| 4 | Sorryページ用CloudFrontの構築 | Sorryページ用のCloudFrontを作成し、ACM証明書のセットアップ、S3バケットポリシーの作成、CloudFrontのカスタムレスポンスのセットアップをします |
| 5 | Route53のフェイルオーバルーティングの構築 | Route53のフェイルオーバルーティングの設定をします |
ステップ①：ベーシック構成のCloudFormationでのデプロイ
それではこちらの章より実際の構築をおこなっていきます。
・ステップ①の構築範囲は以下の赤枠となります。
・手動ですべての構築は煩雑となるため、以下のgithubのリンクの先に今回利用をするCloudFormationを準備しています。こちらをPC等にダウンロードします。
「ALBとEC2を用いたベーシックな構成」の事前準備CloudFormationファイル一式
| ファイル | 内容 |
|---|---|
| 01_VPC.yml | ネットワークに関連する項目の作成をおこなうファイル（VPC、サブネット、ルートテーブル、インターネットゲートウェイ、NATゲートウェイ、EIP） |
| 02_SecurityGroup.yml | ALBとEC2のSecurityGroupを作成するファイル |
| 03_EC2-WebServer.yml | WebサーバとなるEC2（AmazonLinux2023）を1台作成するファイル（nginxのインストールまでCloudFormation内で自動で実施します） |
| 04_ALB.yml | ALBを作成するファイル（HTTPSのリスナールールはACM証明書発行対応後の実施が必要となるため、CloudFormation内では未作成となります） |
・下記の手順にてCloudFormationのデプロイを実行します。
・「CloudFormation」から「スタック」→「スタックの作成」→「新しいリソースを使用」→「既存のテンプレートを選択」→「テンプレートファイルのアップロード」より、ファイルのアップロードをおこないます。 ・「01_VPC→02_SecurityGroup→03_EC2→04_ALB」の順番にデプロイをおこないます。 （各「スタック名」は任意の入力で問題ございません。 依存関係があるため、順番にデプロイを行う必要があります。） ・すべてのスタックのステータスが「CREATE_COMPLETE」で、問題無くデプロイされたことを確認します。
ステップ②：手動でのベーシック構成の最終セットアップ
・ステップ②の構築範囲は以下の赤枠となります。
2-1. [ALB用]ACM（AWS Certificate Manager）での証明書発行
・正常時にALBへ接続する為に利用する、サーバ証明書をACM（AWS Certificate Manager）で発行します。
・「Certificate Manager」から「証明書を一覧」→「リクエスト」→「パブリック証明書をリクエスト」をクリックします ・「完全修飾ドメイン名」にALBへ接続をおこなうFQDN名を入力します ・「検証方法」に「DNS 検証」を選択します。 ・「リクエスト」をクリックします。 ・ステータスが「保留中の検証」になっていることを確認します。 ・Route53レコードに登録をする「CNAME名」、「CNAME値」をメモしておきます。（※次項で利用します。）
2-2. Route53での正常時レコード設定
・正常時接続のALB接続レコード、ACM証明書検証のレコード設定をおこないます。
・「Route53」から「ホストゾーン」を選択し、管理対象のドメイン名をクリックします。 ・「レコード」タブ→「レコードを追加」を選択し以下の2つのレコードを追加します。 ①ACM証明書検証用レコード ・レコード名： ※ACM証明書を発行時のCNAME名（ドメイン名は除く）※ ・レコードタイプ： CNAME ・値：※ACM証明書を発行時のCNAME値※ ②ALB接続用レコード ・レコード名： ※ALB接続予定のサブドメイン（本検証環境は「www」で設定しています）※ ・レコードタイプ： Aレコード ・エイリアス：有効（※CloudFormationで作成されたALBを選択※）
①ACM証明書検証用レコード
②ALB接続用レコード
2-3. ALBのHTTPSリスナー作成
・発行をしたACM証明書を適用したHTTPSのリスナールールを以下の手順で作成します。
・「EC2」から「ロードバランサー」を選択し、名前が「alb01」となっているロードバランサーを選択します。 ・「リスナーとルール」タブから「リスナーの追加」をクリックして新規のリスナールールを作成します。 ・以下の項目を入力します。 ・プロトコル：HTTPS ・ターゲットグループ： ※CloudFormationにて作成済みの「tg-web」を使用※ ・証明書 (ACM から)： ※作成したACM証明書を選択※
2-4. 接続確認
・新規ブラウザを開いて、ALB接続用のFQDNにHTTPSアクセスをおこないます。
・NginxのWebページ画面が開いたら、ベーシック構成のセットアップが完了です。
ステップ③：Sorryページ用S3の構築
・ステップ③の構築範囲は以下の赤枠となります。
3-1. Sorryページ用S3バケットの作成
・以下の手順で新規のS3バケットを作成します。
・「S3」から「バケット」を選択し、「バケットを作成」をクリックして新規のバケットを作成します。 ・バケット名： 任意のバケット名（※バケット名は全世界で一意にする必要があります。） ・その他設定はデフォルト設定とします。（バケットポリシーは次項で作成します。）
3-2. Sorryページ用のHTMLファイルのアップロード
・作成したS3にSorryページとなるHTMLファイルを設置します。
・作成したS3バケットを選択します。 ・「オブジェクト」から「アップロード」を選択してSorryページのファイル（index.html）をアップロードします。
・今回アップロードしたSorryページとなるHTMLは以下となります。
<html>
<h1>S3 Sorry Page</h1>
</html>
ステップ④：Sorryページ用CloudFrontの構築
・ステップ④の構築範囲は以下の赤枠となります。
4-1. [CloudFront用]ACM（AWS Certificate Manager）での証明書発行
・CloudFrontはHTTPS通信時のACM証明書発行は、「バージニア北部（us-east-1）」にて発行した証明書のみ利用可能となります。*1
・そのため、「ステップ② [ALB用]ACM（AWS Certificate Manager）での証明書発行」にて発行した証明書が、「バージニア北部（us-east-1）では無い」場合は、本手順でCloudFront用のACMの発行が必要となります。
・また、ACMで発行した同一のFQDN名は、DNS検証で登録したCNAME名やCNAME値は同一となるため、「ステップ② Route53での正常時レコード設定」を行っている場合は、追加でのRoute53のレコード登録は不要です。*2
・以下の手順でCloudFront用のACMの証明書発行を実施していきます。
・リージョンを「米国東部 (バージニア北部) us-east-1」に変更します。 ・「Certificate Manager」から「証明書を一覧」→「リクエスト」→「パブリック証明書をリクエスト」をクリックします ・「完全修飾ドメイン名」にALBへ接続をおこなうFQDN名を入力します ・「検証方法」に「DNS 検証」を選択します。 ・「リクエスト」をクリックします。 ・ステータスがすぐに「発行済み」になったことを確認します。
4-2. CloudFrontの作成
・CloudFrontのオリジンアクセスコントロールを以下の手順で作成します。
・「CloudFront」から「オリジンアクセス」を選択し、「コントロール設定を作成」をクリックします。 ・以下の項目を入力します。 ・名前 ： ※任意のOAC名※ ・その他はデフォルト値
・CloudFrontのディストリビューションを以下の手順で作成します。
・「CloudFront」から「ディストリビューション」を選択し、「ディストリビューションを作成」をクリックします。 ・以下の項目を入力します。 ・Origin domain ： ※作成を行ったSorryページが格納されているS3バケット※ ・オリジンアクセス ： Origin access control settings ・Origin access control ： ※作成を行ったOACを選択※ ・ビューワープロトコルポリシー ： HTTPS only ・ウェブアプリケーションファイアウォール (WAF) ：セキュリティ保護を有効にしないでください ・代替ドメイン名 (CNAME) ： ※ACM発行時に入力したFQDN名を入力※ ・Custom SSL certificate ： ※作成したACMを選択※ ・その他の項目はデフォルト値
4-3. OAC用S3バケットポリシーの作成
・CloudFront作成後、バケットポリシー更新のバナーが表示されるため、ポリシーをコピーします。
※ポリシー更新のバナーが消えてしまった方は、こちらのドキュメントの「例 CloudFront OAC への読み取り専用アクセスを許可する S3 バケットポリシー」を参照し、バケット名、AWSアカウント、CloudFront distribution IDを書き換えて作成も可能です。
・S3のバケットポリシーの更新は以下で実施します。
・「S3」から「バケット」を選択し、作成をしたSorryページが保存されているバケットを選択します。 ・「アクセス許可」タブ→「バケットポリシー」→「編集」でバケットポリシー編集画面を開きます。 ・OACの読み取り許可を許可する先ほどのコピーしたバケットポリシーを貼り付けて、保存します。
4-4. CloudFrontのカスタムエラーレスポンスの作成
・Sorryページの保存されているS3バケットは「REST API エンドポイント」*3という方式でCloudFrontから接続をおこないます。
・Sorryページのファイル名（例：index.html）にアクセスを行うと表示されますが、Sorryページ以外のファイル名やバケットのルートにアクセスをおこなうと「Access Denied（403エラー）」が表示されてしまいます。
・そのため、CloudFrontのカスタムエラーレスポンスを設定し、「Access Denied（403エラー）」がCloudFrontを通過した際は、Sorryページのファイルパスをレスポンスとして表示する設定を入れ、ユーザが任意のパスにアクセスした際にもSorryページが表示される様にします。
・ CloudFrontのカスタムエラーレスポンスの作成は以下の手順でおこないます。
・「CloudFront」から「ディストリビューション」を選択し、対象のCloudFrontを選択します。 ・「エラーページ」タブから、「カスタムエラーレスポンス」をクリックし、以下を入力します。 ・HTTP error code ： 403: Forbidden ・Customize error response ： Yes ・Response page path ： ※ / + S3にアプロードしたファイル名を入力 ※ ・HTTP Response code ： 503: Service Unavailable
ステップ⑤：Route53のフェイルオーバルーティングの構築
・ステップ⑤の構築範囲は以下の赤枠となります。
5-1. 正常時 ALB用レコードの作成
・既存で作成したALB用レコードをフェイルオーバーに変更をします。
・「ターゲットのヘルスを評価」を行うことでALBのヘルス状態からフェイルオーバの切り替えを行ってくれる形となります。
・「Route53」から「ホストゾーン」を選択し、管理対象のドメイン名をクリックします。 ・ALB接続用のレコードを選択します。 ・以下の内容に修正をします。 ・ルーティングポリシー ： フェイルオーバー ・フェイルオーバーレコードタイプ ： プライマリ ・ターゲットのヘルスを評価 ： はい ・レコード ID ： ※任意の値で問題無い為「01」とします※
5-2. フェイルオーバー時 CloudFront用レコードの作成
・ プライマリーに障害時のCloudFront用レコードを作成します。
・「Route53」から「ホストゾーン」を選択し、管理対象のドメイン名をクリックします。 ・「レコード」タブ→「レコードを追加」を選択し以下のレコードを追加します。 ・以下の内容に修正をします。 ・レコード名 ： ※接続対象のサブドメイン名※ ・レコードタイプ ： Aレコード ・エイリアス ： 有効化 ・トラフィックのルーティング先 ： ※作成をしたCloudFrontを選択 ※ ・ルーティングポリシー ： フェイルオーバー ・フェイルオーバーレコードタイプ ： セカンダリ ・レコード ID ： ※任意の値で問題無い為「02」とします※
動作確認
・正常時の接続、Webサービスが停止した際の切り替わりの動作、Webサービスが復旧した際の切り戻り動作を確認していきます。
1. 正常時
・新規ブラウザを開いて、FQDNにHTTPSアクセスをおこない、NginxのWebページ画面が開いたら正常時の状態となっています。
2. [障害時]切り替り
・「EC2」→「インスタンス」から、「web01」の名前のインスタンスを選択して、「接続」→「セッションマネージャ」でインスタンスへ接続します。
・以下のコマンドでnginxサーバを停止させます。
sudo systemctl stop nginx
・正常時のページをリロードしてSorryページに変更されることを確認します。
※Chromeの場合キャッシュを行わずページを読み込むには「Ctrl + Shift + R」を使用してページのリロードをおこないます。
※検証では「4分程度」で切り替わることを確認しました。
3. [復旧時]切り戻り
・再度インスタンスに接続し、以下のコマンドでnginxサーバを起動させます。
sudo systemctl start nginx
・Sorryのページをリロードして正常時のページに変更されることを確認します。
※Chromeの場合キャッシュを行わずページを読み込むには「Ctrl + Shift + R」を使用してページのリロードをおこないます。
※検証では「3分程度」で切り戻ることを確認しました。
お片付け（作成リソースの削除）
・本手順で構築したリソースは課金が発生致します。検証が終わって不要なリソースは以下の流れで削除をおこないます。
・各リソースは依存関係があるため、以下の順番で削除をお願いします。
1. Route53の追加レコード削除（プライマリ、フェイルオーバ、ACMの3つ） 2. CloudFrontの削除 ・停止→削除を行う必要があります。（削除を行えるまで5分程度かかります。） ・オリジンアクセスコントロール（OAC）の削除をおこないます。 3. S3バケットの削除 ・バケットの中身を空にしてからバケットの削除を行う必要があるります。 4. ALBのリスナールールの削除 5. ACMの削除 ・東京（ALB用）とバージニア（CloudFront用）2つを削除する必要があります。 6. CloudFormationでデプロイしたリソース（以下の順番で削除） 1. ALB 2. EC2 3. SG 4. VPC
まとめ
いかがでしたでしょうか？
Sorryページの「Route53 フェイルオーバールーティング」の実装方法をご紹介いたしました。
とても長い記事になってしまいましたが、ゼロベースでRoute53のフェイルオーバールーティング部分の環境を整えるためには、多くのコンポーネントの実装が事前に必要となることが、本動作確認で分かりました。
本ブログが誰かの学びになれば幸いです。
田原宏樹(執筆記事の一覧)
子供とのお出かけとPodcastを聞くことが趣味です。
