AWSのs3やcoudFrontなどのサービスを使うと、安く全世界にCMSを使って静的ファイルを公開できると聞いて触ってみました。 結果としてはめんどくさかったです。awsのいちサービスを知れて良かったというのはあるかもしれない。
以下はS3+CloudFrontで静的サイト作ってみて躓いたポイントのメモです。
参考文献は公式のS3のチュートリアルがまず一番だと思います。検索すると、やってみた系の記事はヒットするのですが、簡略化されていたりで、あまり良くなかったです。（この記事もそうなんで気をつけてね）
S3にはチュートリアルが4つあって、主に上3つを使います。
-
(2) 例: 独自ドメインを使用して静的ウェブサイトをセットアップする - Amazon Simple Storage Service
-
(3) 例: Amazon CloudFront でウェブサイトを高速化する - Amazon Simple Storage Service
(1)と(2)がシンプルにwebサイト化する方法。話はhttpに限られ、独自ドメインを使う方法が示されています。
(3)ではhttps化については（すでに出来ているものとして）触れずに、「wwwの付いたドメインhttps://www.exsample.comにアクセスすると、付いてないドメインhttps://exsample.comの内容をドメインはwwwのまま返す方法」が載っています。
ポイントとして、
-
(1)(2)と(3)の間はちょっと空いててssl化を行っている。
-
https化（ssl化）するチュートリアルはS3には無い。行うにはcloudFrontやAWS Certificate Manager (ACM)の機能を使うので、そちらのドキュメント等を読む。
-
(1)(2)と(3)で設定方法も違う。
* (1)、(2)では「バケットのリダイレクト機能」をつかって、wwwの付いたアドレスに対処しているが、(3)では、その機能は使っていない、バケットは一つ。- cloudFrontが指すOriginの設定が(1)、(2)ではバケットそのものだが、(3)では、「バケットのアドレス」になっている。
ここで自分がハマったことがあって、
S3の静的サイトのssl化について検索すると、「https://www.exsample.comにアクセスすると、https://exsample.comのアドレスにリダイレクトする方法」がヒットするんですね。これはwww付きからwww無しへのリダイレクトなので、これは(3)と違うし、cloudFrontとバケットを２つ立てるなど少し応用で難しいです。
www付きからwww無しへのリダイレクトは、ユーザーがサイトにアクセスしたらわざわざリダイレクトが返されてしまうし、www付きアドレスの所有者確認もしづらいし、そこまでwww無しアドレスをブラウザに強要する必要ないしで、個人的には必要なかったので、まずそれが必要か気をつけてください。
ssl化は、cloudFrontとAWS Certificate Managerで素直に行うと、httpアクセスを禁止して、http://exsample.comをhttps://exsample.comにリダイレクト出来ますし、チュートリアル(3)にある設定で、http://www.exsample.comをhttps://www.exsample.comのアドレスにリダイレクトすることが出来ます。これでたぶん求めるssl化は出来ると思います。
というわけで、長くなりましたけど、まず公式チュートリアルがまず大事ということで、そのあたり確認しました。
次は各ステップで、躓いたことを説明します。
独自ドメインの購入は、お名前ドットコムを利用しました。取得時、Whois情報公開代行にチェックを入れました。（後から頼むと別料金がかかるので。）
これは世界に公開されるwhois情報にダミーデータを載せてくれるサービスです。
しかし後でssl化するときに、AWS Certificate Managerからくる本人確認メールを開く必要があるのですが、そのメールが届かなくなります。
なのでそのステップの時に、一旦Whois情報公開代行を解除し、そして確認できたら、また代行を設定します。（ここでまた料金を取られることはありません。）そういうステップが必要でした。
DNSは、AWSのRoute 53を使いました。（チュートリアルを参考に）取得したドメイン名でRoute 53でCreate Host Zoneしたとします。
お名前ドットコムの設定でそのホストゾーンに書かれているサーバーを使うことを設定します。
お名前ドットコムのドメインnavi > ネームサーバー変更 > 変えたいドメインにチェックを入れて他のネームサーバーを利用のタブをクリック > Route 53 で作ったhostゾーンのNSレコードの４つのサーバーをお名前ドットコムの方に設定します。
ドメインを移管するなどするときは別の方法を使うようです。
AWS Certificate Manager（以下ACM）で証明書を作り、cloudFrontでその証明書を使うことを設定して、ssl化が完了します。
ACMをコンソールで開くと、東京リージョンになります。しかし東京リージョンで証明書を作ると、cloudFrontの証明書の選択部分で証明書が出てきません。なのでバージニア北部で作る必要がありました。
自分が試しに作ったのが、数ページの階層のないサイトだったので、この項目ちょっとよくわかってないです。
・バケットのwebサイトホスティングの設定により、exsample.comではindex.htmlが帰りますが、となりのページにアクセスするにはexsample.com/tonari.htmlのようにアドレスに.htmlを付ける必要があるようです。
・HTMLファイルの名前から、.htmlの拡張子を外して、Content-type : text/htmlというヘッダー設定を付けてアップロードすると、https://exsample.com/tonariというアドレスでtonariファイルが返ってくることがわかりました。
・index.htmlという名前のファイルは、デフォルトでそのフォルダにアクセスするアドレスに返されるようです。例hoge/index.htmlはexsample.com/hoge/で返される。
・S3はファルダ構造に見えてkey,value式の構造なので、tonari/hogeという名前をつけてS3に置くとexsample.com/tonari/hogeというアドレスでアクセス出来るらしいです。
参考：インデックスドキュメントのサポートの設定 - Amazon Simple Storage Service
でもCloudFrontのキャッシュ機能との関連とかまだよくわからないです。
・複雑なルーティングの場合、サーバーを置く必要があるっぽい
・SPAで必要な、派生アドレスにアクセスしてもindex.htmlを返すようにするには、CloudFront + S3だけだと、CloudFrontのエラーを返す設定をハックするみたいです。
amazon web services - S3 Static Website Hosting Route All Paths to Index.html - Stack Overflow
アドレスなどが上手く行っているか確認にはCLIを使うと良いです。
CloudFrontの確認をする時は、CloudFrontに繋ぐアドレスがあり、S3の確認をする時は、S3のアドレスがあり、設定の項目から確認できます。
curl ・・・windowsはgit bashで実行できます。
curl -I
デプロイなどは、aws cli を使うのが便利です。
aws s3
CloudFrontは、保存するオリジン先（バケット）が返すCache-Controlヘッダーを見てその期間保存してくれます。
デフォルトで24時間になっています。
なので初めてS3にファイルをアップロードして、CloudFrontを立てて試して、おかしいなーとなってまたファイルを書き換えてS3にアップロードしても、CloudFrontにとって24時間立たないと、新しいファイルを取りに行ってくれません。
ここから、S3の変更を即座にCloudFrontに反映させには、CloudFrontのキャッシュを削除します。DistributionsからInvalidationsタブのCreate Invalidationで削除するファイルを指名します。（この削除は何度もするとお金が必要になるらしいです）
普段から、S3にファイルをアップロードする時に、Cache-Controlヘッダーを付けてキャッシュ期間を設定しておくと期間を操作できます。
例えば１時間を設定するなら以下のようになります。
aws s3 sync dist/ s3://exsample.com/ --cache-control "max-age=3600" --acl public-read --delete
www対応するときには公式チュートリアル3つ目を参考にします。
- CloudFrontの設定でオリジンを指定する時、欄に自動でバケットが出てきますが、バケットではなくバケットのアドレスを入力する必要があります。これわかりづらい。
- CNAMEの設定の欄で、wwwなしとありのアドレスを改行して入力します。これもわかりづらい気がする。
- 返すオブジェクトにindex.htmlを設定しないと動きません。