Route53以外で取ったドメインで、静的サイトをS3でホスティングしたい。

### AWS S3で静的サイトを公開したい。加えて、
#### 公開するサイトは当然SSL接続。
#### ドメインはGoogleDomainsでまとめて管理したい。
#### メールアドレスもGoogleで同時に取って、メールサービスは本家GoogleWSで使いたい。
AWSでのお手軽ウェブサイト公開方法として、S3で静的ホスティングというやり方が知られています。ただ、これだけだとあんまり実用的じゃないんですよね。


S3にindex.htmlを頭にした素材をポイと置いて、静的ホスティングを設定する。ここまではいいんですよ。そこから「◯◯のためには別の××ってAWSサービスも使おう」という話になり、ググると独特な文体の公式のガイドラインが出てくるんだけど、頼んでもいないさらに別のAWSサービスを使う前提で書いてあったりして。出来の悪いRPGをやってる気分になってくる。
「S3でのサイト公開するって簡単だって聞いてたんだけど…大人しくお○前○ットコム使っとけば良かったのでは…」となった際の攻略情報が少なかったので、今回、実際のドメインを使って、一通り、納品できる状態まで構築する流れをまとめておきます。

### やること
一歩ずつ組み立てていきます。
まず __S3__ にindex.htmlと、配下にcssを設置し、サイトとして公開します。
こうして公開したサイトには`https://s3.console.aws.amazon.com/s3/buckets/XXXX/XXXXX/index.html`といったURLが割り振られます。(https接続はS3のホスティング機能がやってくれてます。)このURLを好きなドメインに設定するには、 __Route53__ を使用します。
Route53はDNS構築を含めたルーティングを司る司令塔のようなサービスです（AWS用語でいう"フルマネージドサービス"）。あとで詳しく説明しますが、DNSの設定は仕組みを理解できれば簡単です。__ネームサーバー__ (以下NS)の __レコード__ を書き換えることで、目的のドメインのサーバーの場所を指定します。今回、Route53でのこの作業を何度か行います。また、Route53ではwww付きURLのリダイレクト設定も行います。
Route53の主要機能の一つとしてドメインの取得を行えますが、今回はあえてここではドメインを取りません。
というのも、Route53とは別のドメインサービス（今回でいえば __GoolgeDomains__ 、基本はどこの __レジストラ__ でも大丈夫なはずです)でドメインを取得し、その親ドメインを変更せず、AWSで使用したいケースがあるからです。とりわけ、Google Domainsの利用価値は、メールサービスを含めた統合アプリケーションサービスであることです。 __GoogleWorkspace__ 側から見れば Google Workspaceのメールを含めて他サービスは使い続けながら、ウェブサイトだけAWSで運用したいわけです。こうした構成は、GoogleDomainsとRoute53の各NSを設定することで可能です。今回はGoogleDomainsのNSでAWSを指定し、一方のRoute53ではメールのルーティングに関してはGoogleのメールサーバーに投げ返すように設定します。

Route53でS3バケットに独自ドメインを設定すると、https接続が効かなくなります。公開したサイトを(再度)https接続できるようにするには、 __AWS Certificate Manager(ACM)__ での証明書の発行と、 __Amazon CloudFront(CloudFront)__ の設定が必要になります。CloudFrontには、ACMで作った証明書を設置すると同時に、httpsに絞るルーティングと、403/404エラーの処理を担ってもらいます。なおCloudFrontの本来の機能は、世界中のAWSリージョンに配置されている __Edge location__ と呼ぶサーバーにコンテンツを分散して持たせ、トラフィック性能を向上することにあります。

以下の表の順番で構築していきます。章立ては下の目次を見てください。1章と2章はGoogleDomainsとS3での、各々の独立した設定ですので、表では互いの項目にハイフンを入れています。

|章| 使うサービス | サイトをHTTPS化 | サイトを独自ドメインで公開 |  ドメインメールのGメールでの使用 |
|:--:|:--:|:--:|:--:|:--:|
|1| GoogleDomains(GD)| - | - |  ○ |
|2| S3| ○ | × |  - |
|3~4| GD,S3,Route53| × | ○ | ○ |
|5~7| GD,S3,Route53,CloudFront,ACM| ○ | ○ |  ○ |

### 読者対象
・ウェブサイトを独自ドメインで設置したい方
・とりわけS3でホスティングしたい方
・AWSに触れたことはあるけど、Reute53,CloudFront,AWS Certificate Managerのいずれかはまだ触ったことがない方
・DNSの仕組みを一回は聞いたことがあるけど、レコードをいじったことはない方

どれか当てはまる方には、役に立つかもしれません。
少し長いですが、張り切ってやっていきましょう。

# 目次
### [0.DNSの仕組みと今回作るシステムの構成](#0-dnsの仕組みと今回作るシステムの構成)
### [1.Google Domainsでドメインを取得](#1-googledomainsでドメインを取得)
##### 1-1. 好きなドメインを購入する
##### 1-2. [オプション]Google Workspaceでadmin@~などのメアドを作成する
### [2.S3の設置](#2-s3の設置)
##### 2-1. sample-program用のバケットを作成する
##### 　2-1-1. バケットを作成する
##### 　2-1-2. ブロックパブリックアクセス設定を設定する
##### 　2-1-3. オブジェクトをアップロードする
##### 　2-1-4. 静的ウェブサイトホスティングを有効にする
##### 　2-1-5. バケットポリシーを編集する
##### 2-2. www用のバケットを作成・リダイレクト設定する
### [3.Route53の設定](#3-route53の設定)
##### 3-1. ホストゾーンを作成する
##### 3-2. S3でホストされているウェブサイトのサブドメインに対してAレコードを作成する
##### 3-3. www付きのアクセスを受けるAレコードを作成する
##### 3-4. [オプション]メールのDNSを設定する
##### 　3-4-1. MXレコードを設定する
##### 　3-4-2. TXTレコードを設定する
### [4.GoogleDomainsでDNS設定](#4-googledomainsでdns設定)
##### 4-1. DNS > カスタムネームサーバー　でRoute53のNSのアドレス4つを入力する
##### 4-2. DNS設定画面上部の「これらの設定に切り替える」をクリックする
##### 4-3. 待つ
### [5.CloudFrontでSSL接続設定](#5-cloudfrontでssl接続設定)
##### 5-1. Cloud Frontでディストリビューションを作成する
##### 5-2. パブリック証明書をAWS Certificate Managerで発行してCloudFrontに設定する
##### 5-3. 403/404の処理を設定する
### [6.Route53のCloudFrontとの接続設定](#6-route53のcloudfrontとの接続設定)
##### 6-1. AレコードでCloudFrontのディストリビューションドメイン名を指定
##### 6-2. wwwのAレコードを再編集
### [7.S3のCloudFrontとの接続設定](#7-s3のcloudfrontとの接続設定)
##### 7-1. S3のバケットポリシーを設定する



# 0. DNSの仕組みと今回作るシステムの構成

### DNSの仕組み
今回のシステムを作るにあたり、DNSの仕組みを理解できているとできていないでは、難易度が大きく変わってきます。遠回りに聞こえるかもしれませんが、DNSの仕組みからまずはおさらいしましょう。

IPアドレスとは、インターネット上の住所に当たるものです。そしてIPアドレスに、人間が読みやすいためのラベルをつけたものがドメインです。

ユーザーが目的のIPに辿り着くには、割り振られたドメインを誰が持っているかを記録して、誰かがそれを尋ねてきたら返答するという仕組みも必要です。これを行う仕組みが、DNS(Domain Name System)です。DNSでドメインからIPアドレスを特定する流れを名前解決と呼びます。

DNSサーバーにはデータが直接置いてあるわけではありません。データの置き場所のIPアドレスとドメインを紐付ける対応表が載っています。
すなわちDNSとは、アクセスするユーザーがドメイン名で指し示したデータサーバーまで辿り着く（名前解決する）ための、IPアドレスとドメインの対応表が記載されたDNSサーバーのネットワークが実現しているシステムです。DNSサーバーの中に書いてある対応表は、 __レコード__ といいます。
![Route53_S3_GDomain_SSL-simpledns-trim.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/4777c4e1-8024-f5b1-63cc-c9ae4de43236.png)
IPアドレスもドメインも、インターネット上で一意である必要があります。すなわちドメインが機能するには、重複がないように管理する仕組みが必要です。

重複しないために少数のDNSサーバーで管理してしまうと、そこにみんながアクセスしてパンクしてしまいます。ここをうまいこと分散できる仕組みこそ、インターネットが拡張できた理由の一つです。アドレスの一意性とシステムの拡張性/可用性を両立させる仕組みをもう少し細かく解説します。一意性を担保しているのは論理的な階層構造で、拡張性/可用性を担保しているのが物理的なネットワーク構造です。

ドメイン管理の最上位団体はICANN(アイキャン)という組織です。ICANNにより、トップレベルドメインの種類が定められています。馴染み深い .jp や.uk など国別のトップレベルドメインの他にも、.comや .appなど、トップレベルドメインは沢山あります。こうしたトップレベルドメインはICANNが割り振った会社(レジストリ）が管理しています。例えば.comはVeriSignという会社が、.appはGoogle Registryという会社が管理しています。
管理者は、代理店(レジストラ)を通じ、割り振られたドメインをサーバーレベルドメインの粒度で分割販売します。今回、sample-program.com　というドメインをGoogleDomainsで買うのですが、この場合はGoogleDomainsがVeriSignと契約して代理販売している sample-program.com　というサーバーレベルドメインを、私が買うということです。買ったドメインは、移管しない限り、引き続きGoogleDomainsのサービスで管理できます。このように、アドレス空間を小分けして、それぞれを各々のDNSサーバーで管理する仕組みとなっています。

DNSサーバーには、大きく分けて、「そのドメインの情報ならこのIPが確かだぜ」という __権威DNSサーバー__　と、クライアントから名前解決要求を受けると権威サーバーに聞き込みを行い、その結果をクライアントへ返す、 __キャッシュDNSサーバー__ の2種類があります。

![Route53_S3_GDomain_SSL-authoritative-cashe.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/2d2e9f8c-07e2-cf6d-62d0-a93f1e23603e.png)

キャッシュDNSサーバーは、その名の通り、聞き込みを行うことで取得したレコードを貯めます。キャッシュDNSサーバーが持つレコードは、一時的なもので、新しいDNS情報を取り込んで更新していく性質があります。対して権威DNSサーバーにある対応表はドメイン管理者が直接管理でき、設定するとその情報が世界のDNSに伝わります。

権威サーバーのレコードをカスタムすることで、ドメインとIPアドレスの対応を書き換えることができ、好きなネットワーク構成を作ることができるわけです。

### 今回のシステムの構成図

最初に4章までで作るのは、以下のような構成のシステムです。
![スライド6.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/8c82fb76-87b1-c03a-dc72-e820ab85d739.png)
ここまでに使う主なサービスは、GoogleDomains,S3,そしてRoute53です。
GoogleDomainsではドメインを取得します。この記事では、Googleが代理店販売している「.com」アドレスのうち「sample-program.com」を取得します。
次に、S3に素材を配置します。Route53でAWS側のNSのレコードを書き換えることでS3を指定します。そして、AWS側のアドレスを、GoogleDomainsでGoogleのNSのレコードに記述します。
ここまでの設定で、Googleの管理するドメインでS3の素材を指定することができています。
名前解決は次の図の流れになります。
![Route53_S3_GDomain_SSL-4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/c3a620e7-95dd-f05a-f12e-09e02a693d77.png)


5~6章では以下の構成にしていきます。
![スライド7.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/436cd974-4f4c-55eb-18ed-db2ba0c9882c.png)

CloudFrontとACMが追加されていますね。

少し脱線します。ACMですが、米国バージニア州のリージョンでのみ提供しているサービスです。CloudFrontはそれに合わせてバージニア州のリージョンを使う必要があります。S3は好きなリージョンで立てて大丈夫です。知らないと引っかかるポイントの一つです。以降、「最初に書いとけよ」と思った話には　__ひっかけポイント__ を付けておきます。

CloudFrontは世界中のリージョンに分散配置したEdge locationにデータをキャッシュしておき、最適なルーティングを実現する仕組みです。
リージョンを含めた状況をより正確に描くと、下の構成図になります。
![Route53_S3_GDomain_SSL_eidt1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/8e5e035d-9d1c-8eb6-2e59-2227c5ccc1d0.png)



# 1. GoogleDomainsでドメインを取得
#### 1-1. 好きなドメインを購入する
Google Domainsでドメインを購入します。今回は「sample-program.com」を購入しました。
![1-gd.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/8f580cdf-8c58-2467-b320-0a9635b79bce.png)

購入すると、DNS>デフォルトネームサーバー で、ドメインを管理する4つの権威NSのドメインが確認できます。
![33-gded.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/e8adeb42-b1ac-e973-5891-fd25fc694d37.png)

ここの情報はまた後で使います。

#### 1-2. [オプション]Google Workspaceでadmin@~などのメアドを作成する
次に、このドメインでメアドを取得します。
「goolgleを利用したオンラインサービスの設定」>「Workspaceを入手」に進みます。
バックアップ用のメールは別ドメインのメアドを入れてください。
![2-gws.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/ad874246-45d7-8f9d-7d1f-a33cc7cbd4ff.png)
ちなみに今回作成するadmin@のメールアドレスは、そのドメインの管理者が保有しているべき管理者アドレスです。管理者アドレスにはadmin@のほか
administrator@
hostmaster@
postmaster@
webmaster@
が定められています。この規則はRFCという、インターネットの自主ガイドラインに記載されているもので、EUがGDPRでも準拠している、世界共通ルールです。2018年に施行されたGDPRの影響でWhois情報を見てもメールアドレスが隠されるケースが増えたのですが、この5つのアドレスは管理用アドレスとして、特に非公開にしなくて良いことになっています。

バックアップ用で設定したメアドに届く仮パスワードでログインし、パスワードを設定します。
設定後、Gmailの受信箱が表示されればOKですね。
![6-gws.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/f7063640-0b3c-fe98-1d16-0e5bb6860f72.png)


# 2. S3の設置
AWSのアカウントは作成している前提で進めます。また、以降の全ての操作はAWSマネジメントコンソール上で行います。
#### 2-1. sample-program.com用のバケットを作成する
今回、S3内には2つのバケットを作成します。一つはHTMLファイルをはじめ、データを置くバケットです。もう一つは`www.sample-program.com`へのアクセスを受けるためのバケットです。一つ作ると勝手がわかると思いますので、www用はさらっと解説します。

###### 2-1-1. バケットを作成する
__ひっかけポイント__
バケット名を、ドメインと合わせる必要があります。
ここできちんと合わせておかないと、後々、バケットを作り直すことになります。
![8-s3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/298c0abb-6a6a-b990-81b6-821fe4a576ac.png)


##### 2-1-2. ブロックパブリックアクセス設定を設定する
赤いビックリマークが付いていて怖いですが、チェックします。
![9-s3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/6c9b4fee-1782-9a0d-c66e-bee1b97f8fbf.png)

他はデフォルトの設定で、「バケットを作成」をクリックします。

##### 2-1-3. オブジェクトをアップロードする
今回は1枚のHTMLファイル、index.htmlと、style.cssを入れたcssというフォルダをアップロードします。
![10-s3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/21609197-a4ad-49fc-db97-031f1a10babd.png)

##### 2-1-4. 静的ウェブサイトホスティングを有効にする
プロパティの一番下の「静的ウェブサイトホスティングを有効にする」を開きます。
ここでインデックスドキュメントを設定します。今回はindex.htmlです。
![11-s4.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/2fe95612-f140-b73f-8ca8-e13ef1e9629f.png)

##### 2-1-5. バケットポリシーを編集する
バケットポリシーの右にある「編集」をクリックします。するとポリシーを記述するエディタのような画面が開きます。
![12-s3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/7205713d-8e80-da5c-0bc3-9f078e7386c3.png)
最初に以下のような記述になっています。
![13-s3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/a3f087c4-a77d-7a4f-337c-745dec77856f.png)
以下のように書き換えます

```
{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "Statement1",
			"Principal": "*",
			"Effect": "Allow",
			"Action": "s3:GetObject",
			"Resource": "arn:aws:s3:::sample-program.com/*"
		}
	]
}
```

※Resourceのファイル名はご自身の環境で適宜読み替えてください。
ここまでの設定で、S3に設置した素材にブラウザからアクセスできます。先ほど設置したバケットのURLは ```http://sample-program.com.s3-website-ap-northeast-1.amazonaws.com``` ですね(プロパティ > 静的ウェブサイトホスティングの一番下のところで確認できます)。

#### 2-6. www用のバケットを作成・リダイレクト設定する
`www.sample-program.com`というもう一つのバケットを作成します。
www無しが好まれる時代ですが、www付きもキャッチできなければいけません。
S3でwww付きのドメインのバケットを作成し、S3の機能で先ほどの`sample-program.com`へリダイレクトします。
![21-r53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/4d1d9d06-522a-a758-f972-acaa14136644.png)
![22-s3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/fab37a95-98c6-8ae5-5d81-d823267658af.png)
パブリックアクセスブロックの設定は先ほどと同様です。ただしバケット作成後に少し異なる設定をします。
プロパティ　＞　静的ウェブサイトホスティング　の「編集」をクリックします。
静的ウェブサイトホスティングを有効にし、その下のオブジェクトのリクエストをリダイレクトする　をチェックします。
![23-s3ed.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/da85ba22-ed40-9523-e72b-7b11c4e8cc87.png)
するとホスト名の入力欄が表示されますので、本体のS3内のエンドポイント`sample-program.com`を入力します。

プロトコルはなしで良いです。
![24-s3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/fc785d4e-2226-6ee2-1099-182d2dd1ccf9.png)
変更の保存をクリックします。

最後に、バケットポリシーを、sample-program.comのバケットと同じ要領で変更します。Resourceのファイル名にはwww.を付けてください。

# 3. Route53の設定
次はいよいよRoute53で独自ドメインを付与します。
#### 3-1. ホストゾーンを作成する
Route53のコンソールを開き、「DNS管理」の下の「ホストゾーン」をクリックします。
![14-r53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/c9c5fd09-bf4e-dbf1-c295-c49720c326ca.png)
「ホストゾーンの作成」をクリックします。
![15-r53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/ec691006-282e-8d7a-e8b8-b2ba6ece3390.png)


__ひっかけポイント__　
S3でバケット名をドメインと揃えたのと同じく、ホストゾーンもドメインと揃えます。
ホストゾーンの作成をクリックします。

![16-r53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/2a1c7e7d-6a60-ff8c-13c4-a585dc406057.png)

するとこのような画面になるかと思います。レコードが並んでいますね。初めて見ると面食らうかもしれませんが、意味がわかれば非常にシンプルです。

1行目にある、タイプ「NS」は、ネームサーバーですね。「レコード名」カラムにあるこのドメインを管理するネームサーバーが記述されています。
2行目のタイプ「SOA」は、このドメインの管理者に関する情報を記載しています。

詳しい意味は公式のこちらのページや、「Route53 レコード　タイプ」などでググって出てくるサイトで確認してください。
[Amazon Route 53 がパブリックホストゾーンに作成する NS レコードと SOA レコード](https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/SOA-NSrecords.html)

ここにレコードを追加していきます。

#### 3-2. S3でホストされているウェブサイトのサブドメインに対してAレコードを作成する
最初に追加するレコードはタイプAです。これは、IPv4のアドレスとドメインを結びつけるレコードです。
`sample-program.com`に来たアクセスを、先ほど作成したS3のアドレスに繋げます。

「レコードを作成」をクリックします。
![17-r53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/ec537f8c-1d6f-d925-bf98-74d9c8aebce8.png)
レコード名はそのまま空欄、上の赤枠で囲んだチェックを押します。
![18-r53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/fde1392a-d7b9-8d42-42d8-9118e9d592fd.png)
S3ウェブサイトエンドポイントへのエイリアスを選択します。
![19-r53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/53a8fc44-b813-b49a-d849-c0f167723929.png)
リージョンを間違いなく選べていれば、S3バケットが表示されると思います。リージョンが間違っていないのに表示されないとすると、S3あるいはRoute 53でのバケット/ホストゾーン名を間違えている可能性があります。

ルーティングポリシーはシンプルルーティングでOKです。
![20-r53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/231039e8-61de-6b72-3e08-6c41ea08cc50.png)

次に、`www.sample-program.com` でのアクセスを先ほど作成したS3のwww付きの方のバケットに流すレコードを作成します。

#### 3-3. www付きのアクセスを受けるAレコードを作成する
同じ手順で、Aレコードを作成します。
![26-rt53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/7143540f-0481-06aa-2653-00ef1c2d4094.png)
レコードはこんな感じに並ぶと思います。
![27-rt53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/b0b5758b-b369-78b0-dc16-ae01e69733fc.png)

__ひっかけポイント__　
ここで鋭い方は、「Route53で受けた`www.sample-program.com`宛のルーティングをRoute53の中で`sample-program.com`にAレコードで流せばいいじゃん？それならS3で新しくバケット作る必要なかったじゃん？と気づくと思います。

![これってアホでは.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/d60dce12-c728-1a0a-091d-746785bcad49.png)
![このほうが賢そう.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/248e02a4-e38c-6673-835e-ea1240194d71.png)

実は、この構成でも動きます。ただ、後々に、CloudFrontを使う段階で、www.付きのドメインに対応するS3バケットが無いと困ってしまうんです。CloudFrontでは、カスタムドメイン名を設定する際に、ドメインに対応するS3バケットを紐づける必要があります。

つまり、S3での静的ホスティングでHTTPS接続とwww有り/無しドメインを両立するには、www用のバケットを特に用意する必要があるわけです。

#### 3-4. [オプション]メールのDNSを設定する
本3-4節はオプションです。GoogleWorkspaceでメールアドレスを持っている場合の設定になります。
この後の4章でGoogleDomainsで、Googleの権威NSのレコードをいじります。`sample-program.com`へのアクセスがAWSに来るのですが、その際にメールもAWSに来てしまいます。ですのでRoute53で、メール宛のドメインを再度Googleに投げ返す必要があります。
##### 　3-4-1. MXレコードを設定する
Route53で、レコードを追加します。タイプはMXです。
GoogleDomainsで「デフォルトのネームサーバー」の中の「GoogleWorkspace」を確認します。
![29-gd.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/a576e854-ed47-0bb9-be21-90926d03db4f.png)
この中のタイプMXのレコードのデータ欄を、そっくり、Route53で追加するレコードの「情報」欄へコピーします。レコード名は空欄で良いです。
![30-rt53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/dd56754d-6294-d0cc-4462-035fba9e9489.png)

##### 　3-4-2. TXTレコードを設定する
同じ要領で、google._domainkeyというレコード名にRSA鍵が情報欄に入るTXTレコードと、レコード名空欄で情報欄に`"v=spf1 include:_spf.google.com ~all"`が入るTXTレコードを作ります。SPFレコードも作ってもいいです。
ここまで全部作ると下のようなレコードになります。
![31-rt53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/9a2a3266-fa7c-b919-5bbc-8f5c8c8feda2.png)

# 4.GoogleDomainsでDNS設定
今の状態では、`sample-program.com`へのアクセスはGoogleDomainに行っています。GoogleのNSのレコードを設定することで、ドメインでアクセスできるようになります。
#### 4-1. DNS > カスタムネームサーバー　でRoute53のNSのアドレス4つを入力する
GoogleDomainsのDNS設定から、カスタムネームサーバーを開きます。
![36-gd.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/86cdcce0-c5d4-e0e9-784e-8adc098a6e61.png)
ここに、Route53で確認できるNSタイプのレコードの情報を1こずつ入力します。
![37-gd.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/88aa201c-2dca-8f13-ffa2-1ae743cef880.png)



#### 4-2. DNS設定画面上部の「これらの設定に切り替える」をクリックする
4つのアドレスの入力と保存が終わったら、「これらの設定に切り替える」をクリックし、カスタムドメインを使います。

#### 4-3. 待つ
DNSの設定が反映されるまで、数分から数十分かかります。待ちましょう。
しばらくすると、`sample-program.com`と`www.sample-program.com`で、サイトが閲覧できるようになっているはずです。この後CloudFrontを追加したりして規模が大きくなってくると、DNSの変更後、しばらく経たないと反映されないということがあります。それを知らないと「公開したはずなのにアクセスできない！」と設定をまた変えたりして、さらにDNSを混乱させてしまいます。じっくり待つのが大事です。


# 5. CloudFrontでSSL接続設定
5~7章で、SSH接続をするための手順を行います。まずCloudFrontのディストリビューションの作成を行いますが、その手続きの中でACMで証明書を発行できます。

#### 5-1. Cloud Frontでディストリビューションを作成する
CloudFrontコンソール画面からディストリビューションを作成をクリックします。
![38-cf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/a4858c24-852f-7b6c-bd36-5c5d28b9389e.png)

オリジナルドメインを選択します。ここでS3のバケットを選択しましょう。
![40-cf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/95e5080d-ecc0-6e4a-8edf-eab50bbafc6b.png)

オリジンパス - オプション　は空欄で良いです。

名前は適当に決めましょう。今回は`sample-program.com`と入れました。

S3 バケットアクセス　は「はい、OAI を使用します (バケットは CloudFront のみへのアクセスとなるように制限できます)」を選択します。
OAIは新しく作成します。
![41-cf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/6c97c12b-3d1b-0021-6b36-b6a4cb28f028.png)

バケットポリシーは「はい、バケットポリシーを自動で更新します」を選択します。
これにより、先ほど作成したS3のガバガバポリシーに、最適な設定が追記されます（内容は後で確認します）。

カスタムヘッダーを追加 - オプション　は行いません。
オリジンシールドとその下の追加設定も、デフォルトでいきます。

次に、「デフォルトのキャッシュビヘイビア」項の設定です。
パスパターン　はそのまま
オブジェクトを自動的に圧縮　はYes
ビューワープロトコルポリシー は Redirect HTTP to HTTPS
許可された HTTP メソッド はGET, HEAD
ビューワーのアクセスを制限する　はNo
キャッシュキーとオリジンリクエスト はそのまま
関数の関連付け - オプション　は今回は選択しません。
AWS WAF ウェブ ACL - オプション は選択しません。


代替ドメイン名 (CNAME) - オプションに、ドメイン「sample-program.com」「www.sample-program.com」を入力します。
![42-cf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/e2c01b9e-41a1-8bc5-dbf9-2e50287e8eb3.png)

#### 5-2-1. パブリック証明書をAWS Certificate Managerで発行する
![43-cf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/3d6e6668-1fbd-4e7a-d2e6-dbfef65a3d84.png)
証明書をリクエストをクリックします。
すると別タブでAWS Certificate Manager(ACM)の「パブリック証明書をリクエスト」画面に遷移します。

ドメイン名 に`sample-program.com`と`www.sample-program.com`を追記します。
![44-cf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/a149a762-a903-d096-45d5-e75a13ff215e.png)

また、その下の検証方法を選択　ではDNS検証を選択します。

![45-acm.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/739c8b85-c2f9-ed89-be3e-dfc87ffe221a.png)
リクエスト後のサイトをリロードすると、今回リクエストした証明書が表示されていると思います。IDのリンクをクリックしてください。
![46-acm.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/d9fb8ee4-0a95-8ee5-fecc-0fe43782274d.png)

#### 5-2-2. Route53で発行されたCNAME値を設定する
__ひっかけポイント__　
ここで表示されるCNAME値2つを _Route53_ へ設定します。
![47-rt53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/578a65e9-0d77-be92-f653-3a0458b98c0b.png)
レコードを作成をクリックします。
レコード名にはACMでのCNAME名 をコピペします。全文をコピーすると、末尾の`.sample-program.com`が被ってしまうと思うので、適宜修正を。
情報　にはCNAME値　をコピペします。
![48-rt53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/313de0fc-ced6-0c96-7a80-33622b676cd1.png)
同様に、www用のCNAMEレコードも追加します。
![49-rt53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/6658644a-0768-9006-5929-daf14bd116b8.png)
ACMを確認してください。正しく設定できれば、証明書が通ります。
![50-acm.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/4d4ae6d5-2f25-4638-5364-efc2533aa258.png)
ACMを閉じ、CloudFrontへ戻ります。

カスタム SSL 証明書 - オプションで、今回作成した証明書を選択します。表示されていない場合は、右のボタンで更新してください。
![51-cf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/fb418abf-f6a9-e14b-1cbe-c502ebdf25cc.png)
レガシークライアントサポート - 月額 600 USD の比例配分された料金が適用されます。ほとんどのお客様はこれを必要としません。　はチェックを入れません。
セキュリティポリシー　と　サポートされている HTTP バージョン　はそのままで良いでしょう。
デフォルトルートオブジェクト - オプション　には`index.html`を入力します。
![52-cf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/ab5d4321-6a0d-5da2-7ab2-56771807e941.png)

以上で基本設定は終了です。ディストリビューションを作成してください。

#### 5-3. 403/404の処理を設定する
![53-cf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/3494b4d3-a790-0c7f-3a90-39a915e18022.png)
DloudFrontでは403や404などのエラー処理を設定できます。
エラーページ＞カスタムエラーレスポンスを作成をクリックし、403を選んで作成してください。続いて404を作成してください。
エラーレスポンスをカスタマイズ　はいいえで良いでしょう。
![54-cf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/5c6546cb-83b7-52ca-4bbc-ce2d8f963c2f.png)

以上でCloudFrontの設定は終了です。

# 6. Route53のCloudFrontとの接続設定
##### 6-1. Aレコードを編集してCloudFrontのディストリビューションドメイン名を指定
Route53のAレコードの接続先をCloudFrontに変更します。
`sample-program.com`のAレコードを編集します。トラフィックのルーティング先でCloudFrontディストリビューションへのエイリアス を選択します。するとディストリビューションで作成したディストリビューションが選択欄に出てきますので選択します。
![56-cf.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/4673561b-5d2a-1683-a9dd-e0f2b2f81de2.png)
もし出てこない場合にはCloudFrontの ディストリビューション > 一般 から確認し、コピペしてください。

##### 6-2. wwwのAレコードを編集
`www.sample-program.com`は、リダイレクト先に同ディストリビューションの`sample-program.com`を指定します。
![58-rt53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/974cc52c-669d-d407-6ec0-bfd01792b36a.png)
最終的に、以下のようなレコードになるかと思います。
![59-rt53.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/8f4563fe-223a-a963-f95e-7ac3c7a40674.png)


# 7. S3のCloudFrontとの接続設定
#### 7-1. S3のバケットポリシーを設定する
S3でsample-program.comのバケットを開き、アクセス許可>バケットポリシーを開くと、5-1で行った操作で、ポリシーが変更されていることがわかります。
![55-s3.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/158553/51f8bd9d-1df2-7bd3-6193-c3ed1adf6ff2.png)
前のものの後に、CloudFrontからのアクセスを許可するポリシーが追記されていますね。
前に書いたものを削除してスッキリさせます。
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E3AFA562X0U0AW"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::sample-program.com/*"
        }
    ]
}
```
これによりS3バケットへのアクセスをCloudFrontのみに制限できました。

同様に、wwwのバケットも開き、
```
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "1",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::cloudfront:user/CloudFront Origin Access Identity E3AFA562X0U0AW"
            },
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::www.sample-program.com/*"
        }
    ] 
}
```
を入力します。

# 終わりに

お疲れさまでした。
ここまでの作業でウェブサイトが表示されるかと思います。
また、http接続しようとするとhttpsにリダイレクトされることも確認できると思います。
メールのDNSを設定した方は、メールも確認しましょう。

もしサイトがうまく表示されていなかったら、まずは少し時間を置いてみましょう。それでもダメそうなら、以下を見直してください。
・S3バケットおよびCloudFrontで、インデックスファイルを正しく設定しているか。
・CloudFrontのレコード設定は正しく行われているか（特にCloudFrontとの連携は少しややこしいので、6-2のレコードの様子を参考にして、漏れがないか確認してください)。
・S3のバケットポリシーは適切か。
・GoogleDomainsでカスタムネームサーバーは有効になっているか。

また、CloudFrontの導入後、データ変更を早く反映したい場合は、CloudFrontのエッジサーバー上のキャッシュを削除するということが可能です。簡単ですのでググってみてください。

## 参考になったサイト
__AWS公式：__
【S3】
オリジンアクセスアイデンティティ (OAI) を使用して Amazon S3 コンテンツへのアクセスを制限する
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/private-content-restricting-access-to-s3.html#private-content-granting-permissions-to-oai

Amazon S3 バケットでホストされているウェブサイトへのトラフィックのルーティング
https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/RoutingToS3Bucket.html

【Route53】
親ドメインを移行しないで Amazon Route 53 を DNS サービスとして使用するサブドメインを作成する
https://docs.aws.amazon.com/ja_jp/Route53/latest/DeveloperGuide/CreatingNewSubdomain.html#CreateZoneNewSubdomain

【CloufFront】
CloudFront を使用して Amazon S3 バケット向けに HTTPS リクエストを提供するにはどうすればよいですか。
https://aws.amazon.com/jp/premiumsupport/knowledge-center/cloudfront-https-requests-s3/

__Google公式：__
Google 経由で登録したドメインにウェブサイトを接続する
https://support.google.com/a/answer/7538152?hl=ja

__ブログ__
AWSでWebサイトをHTTPS化 全パターンを整理してみました
https://recipe.kc-cloud.jp/archives/11067

AWSでWebサイトをHTTPS化 その5：CloudFront(+証明書)→S3編
https://recipe.kc-cloud.jp/archives/11256

【AWS】S3+CloudFront+Route53+ACMでSSL化(https)した静的Webサイトを公開する
https://zenn.dev/wakkunn/articles/66a6e8372611dc#%E5%AE%9F%E8%A3%85%E6%89%8B%E9%A0%86