準備・注意
前回のハンズオンの続きから
EC2が2台立ち上がっており、RDSも利用可能、WebページもHTTPS通信で閲覧できること
このハンズオンでは料金が約10〜11円/時間かかります
手順
今回はHTTPS通信でELBとの間にCloudFrontを設置して、EC2のWebページをキャッシュしている状態にしていきます
1, Route53でドメイン名とELBが紐づくレコードを修正して一旦、alb.aws-demo.gaに変更
2, CloudFront作成
3, Route53に独自のドメイン名とblog.aws-demo.gaが紐づくレコードを追加
以上の設定でクライアントが blog.aws-demo.ga にアクセスしたら、Route53の設定でCloudFrontに通信が流れて、CloudFront(alb.〜)からRoute53でELB配下のEC2のWebページが表示される。
ACMはblog.aws-demo.gaのようにドメイン名を固定できるが、ワイルドカード(*.aws-demo.ga)で作成することで複数のドメインをまかなえる。
CloudFrontでもHTTPS通信をするので、証明書が必要ですが、CloudFrontの証明書は発行元リージョンは北米のバージニアリージョンでアタッチします。(※ELBの証明書は日本の東京で発行します)
↓ 以降のデモでは両方のACMをワイルドカードに作り直します。
Route53でドメイン名とELBが紐づくレコードを修正して、alb.aws-demo.gaに変更
Route53< ホストゾーンを開く
ハンズオンで設定したホストゾーンで、２つ(プライマリとセカンダリ)のフェイルオーバールーティングを変更していく
チェックボックスにチェックをいれ、編集ボタンを選択
レコード名にblogと入っている文字をalb（任意）に変更して変更の保存を選択
もう一つのレコードも同じように変更したら一旦放置して次の行程に進みます
ACMに*を使用し再作成
ロードバランサーにアタッチされている証明書が（blog.aws-demo.ga）という固定の名前となっているため、どのサブドメインでも使用可能なように*の証明書を新しく作成していきます
EC2< ロードバランサーの画面から
既存のリスナーを一度削除し、リスナーを新しく追加していきます
プロコトル:ポートをHTTPSを選択
デフォルトアクションの設定を転送先を指定し、ターゲットグループ(TG-1)を選択
下の新しいACM証明書をリクエストを選択してACMの設定をしていく
証明書のリクエストでドメイン名を*.aws-demo.gaと入力し次へを選択
検証方法をDNSの検証のまま次へを選択
タグは追加せず、確定とリクエストを選択
検証< タブを開き、Route53でのレコードの作成を選択し作成する
続行を選択すると検証保留中となります
Route53の画面に戻る
古い固定ドメイン(blog.~~~)で始まるドメインのレコードが残っているので削除します
ACMの画面に戻る
新しく作成した*で始まる証明書の状況が発行済みに変わっています。
blogで始まる証明書はアクションから削除しておきます
リスナー追加画面に戻る
デフォルトのSSL証明書に作成した*から始まるものを選択し、保存します
(確認)この時点でalb.aws-demo.gaのURLから閲覧できることを確認します
CloudFront作成
準備
CloudFront用の証明書を作成するために、まず現在のリージョンを米国東部(バージニア北部)リージョンに変更
証明書のプロビジョニングを今すぐ始めるを選択します
証明書のリクエストを選択
ドメイン名の追加で上と同様に*.aws-demo.gaと入力
進めていき、検証でRoute53でのレコードの作成を選択し検証用のレコードを追加する
証明書の状況が発行済みとなっていることを確認します
作成
CloudFrontでcreate Distributionを選択
delivery methodを選択する画面でWebのGet Startedを選択します
※RTMP・・・Adobeが開発しているストリーミングのプロトコルのこと
Origin Dmain Name(Originはどのドメインか)を今回はalb.aws-demo.gaと入力
Origin Protocol PolicyのHTTPS Onlyにチェックをいれる
Viewer Protocol PolicyのHTTPS Onlyにチェックをいれる
Cache PolicyのCreate a new policyを選択
今回はテスト用に短いTTLのキャッシュポリシーを作成します
InfoのNameにShortCasheと名付け
TTL Settingsの数値を60(秒)と設定し他の項目はデフォルトのままCreate cache policyを選択
Cashe Policy選択画面に戻り更新ボタンを押すと、今作成したShortCacheがあるので選択
SSL Certificateの設定項目をCustom SSLにチェックをいれ、入力欄に*.aws-demo.ga(バージニアで作成した証明書)を選択
Alternate Domain Names(CNAMEs)の入力欄にblog.aws-demo.gaを入力
以上の設定でCloudFrontを作成します
StatusがDeployedとなれば完了(5分ほどかかる)
完了したCloudFrontを選択すると設定内容を確認できる
(確認)Domain Nameにある文字列にアクセスしてもCloudFrontにアクセスできる
Route53に独自のドメイン名とblog.aws-demo.gaが紐づくレコードを追加
Route53でレコードを作成していく
ルーティングポリシーはシンプルルーティングを選択して次へ
シンプルなレコードを定義を選択
レコード名はこれまでの通りblog.aws-demo.gaとなるよう入力
値/トラフィックのルーティング先はCloudFront distributionへのエイリアスを選択
リージョンを米国東部(バージニア北部)を選択すると先ほど作成したCloudFrontのドメイン名が候補に出てきます
あとはデフォルトの状態でレコードを定義を選択し、レコードの作成を行います
↓(確認)↓
blog.〜始まるドメインはCloudFrontと紐付き、キャッシュされた状態
alb.〜で始まるドメインは直接ロードバランサーのドメインと紐付いた状態となっています
テスト
blogで始まるドメインとalbで始まるドメインの比較を行います。
EC2インスタンスにログインしてindex.phpを編集して反映されているか確認します。
すぐに変更が反映されるのが、alb.〜から始まる方、
blogで始まる方はすぐには反映されません。
これはキャッシュポリシーで設定した60秒を経過しないとキャッシュの期限が切れるまで反映されません。
60秒経過するとalb.〜で始まるドメイン名のページにも変更が反映されます。
参考
この記事はAWS初学者を導く体系的な動画学習サービス
「AWS CloudTech」の課題カリキュラムで作成しました。
https://aws-cloud-tech.com