キャッシュサーバーを配置する　ハンズオン

##準備・注意
前回のハンズオンの続きから
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でのレコードの作成を選択し検証用のレコードを追加する
証明書の状況が発行済みとなっていることを確認します

https://qiita.com/tr76aquarius/items/fcc81647b076583ecc46

###作成
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](https://qiita.com/tr76aquarius/items/fcc81647b076583ecc46#%E7%94%A8%E8%AA%9E)のキャッシュポリシーを作成します
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