なぜ S3 の前段に CloudFront を置くと良いのか
2020-06-28AWS 上で静的サイトをホスティングする際に Amazon S3 と Amazon CloudFront をセットで使うことは多いと思います。ただ単にホスティングするだけであれば S3 だけでも可能ですが、 CloudFront を前段に置くことで色々とメリットがあります。今回は個人的にメリットだと思う部分について簡単にまとめてみたいと思います。
目次
概要
AWS 上で静的サイトをホスティングする際に、 S3 のみを利用する場合に比べて CloudFront をセットで使うことで得られるメリットについてまとめてみます。
今回触れるメリットは、次のような内容です。
- キャッシュによる表示速度の高速化
- 独自ドメインの SSL 対応
それぞれについて簡単にまとめていきます。
キャッシュによる表示速度の高速化
CloudFront は AWS が提供している CDN サービスです。
エンドユーザーにコンテンツをより低いレイテンシーで届けるため、Amazon CloudFront では 42 か国 84 都市にある 216 の POP (Point Of Presence) (205 のエッジロケーションと 11 のリージョン別エッジキャッシュ) のグローバルネットワークを使用しています。
このように、世界中にエッジサーバ (エッジロケーション) があり、クライアントに近いエッジサーバからキャッシュしたコンテンツを配信することができます。
まあ、これは CloudFront というか CDN というサービス自体による恩恵です。とは言え、クライアントに対して高速にコンテンツを配信できるというのは大きなメリットです。
CloudFront では Cookie や クエリ文字列によるキャッシュ制御も柔軟に設定できるので、上手く利用していきたいところです。
独自ドメインの SSL 対応
S3 のみの場合、 S3 + CloudFront の場合ともに、各サービスが提供しているドメインでは SSL/TSL 暗号化が有効になっており、 https でコンテンツを配信することができます。S3 であれば https://<bucket-name>.s3-ap-northeast-1.amazonaws.com 、 CloudFront であれば https://<distribution-id>.cloudfront.net のようなドメインとなっています。
しかし、独自ドメインで SSL/TSL 経由でコンテンツを配信しようと思うと、 CloudFront を利用する必要があります。
S3 のみで独自ドメインを利用することもできます1が、その場合は SSL 証明書を配置する場所がなく、 SSL/TSL 経由での配信ができません。 CloudFront を利用すれば、 ACM (AWS Certificate Manager) で作成した証明書をディストリビューションに設定することができるので、独自ドメインで SSL/TSL 経由での配信が可能になります。
AWS Certificate Manager について
ACM についても簡単におさらいしておきます。
AWS Certificate Manager (以下、ACM) は SSL/TLS 証明書を管理できるサービスで、管理している証明書を AWS の各種サービスで利用することができます。また、 ACM での証明書発行は無料で、且つ更新作業も不要です。個人的に証明書の管理ってかなり面倒だと思っているので、 ACM はとてもありがたいサービスだと思っています。
ACM で管理している証明書を利用できるサービスは次のとおりです。
- Amazon CloudFront
- Amazon API Gateway
- Elastic Load Balancing
つまり、 AWS で Web サービス (サイト) や API を SSL/TLS 経由で配信する場合は、上記のサービスに ACM で管理した証明書を配置するか、 EC2 などに直接証明書を配置することになります。(後者の場合は証明書の更新を自分たちでやる必要があります)
今回のように、 S3 で・独自ドメインで・SSL/TLS 経由で 静的サイトをホスティングする場合には、 CloudFront を利用するしか方法がないということになります。
AWS Certificate Manager（SSL/TLS 証明書のプロビジョン、管理、およびデプロイ）| AWS
他にもメリットはあるもよう
この記事を書くにあたってあらためて S3 の仕様について調べていたのですが、どうやら S3 にもスロットリングの仕様があるようです。
S3 では、バケット内の一つのプレフィックスにつき 1 秒間に 3,500 件の PUT/COPY/POST/DELETE 、5,500 件の GET/HEAD と、それぞれリクエストスロットリングが設定されています。これを超えるリクエストが発生すると、 S3 は 503 Slow Dwon エラーを返す場合があるようです。
CloudFront を S3 の前段に置けばこのスロットリングを回避することもできそうです。
またコスト面でもメリットはありそうです。 S3 のみの場合、 CloudFront 経由の場合ともにインターネットへのデータ転送にかかる料金はほぼ同じですが、 CloudFront を利用すれば S3 オブジェクトへのリクエスト回数を減らすことができるので、その分はコスト削減ができそうです。ただし、 S3 オブジェクトへのリクエストにかかる料金は 1,000 リクエストあたり 0.00037 USD (東京リージョン) と かなり少額なので、そもそもリクエスト数が少ない場合にはあまりコスト削減は見込めないと思います。
まとめ
AWS 上で静的サイトをホスティングする際に Amazon S3 と Amazon CloudFront をセットで使うことで得られるメリットについて簡単にまとめてみました。
S3 だけでホスティングできるという手軽さはありますが、表示速度の高速化や独自ドメインでの SSL 対応など、得られるメリットは大きいと思います。ただし、 CloudFront の設定変更には多少時間がかかるので、色々設定をいじって変更して…という作業が頻繁に発生する場合にはちょっとストレスを感じるかもしれません。とは言っても、一時期に比べてそれらにかかる時間も相当短縮されているのでストレスもだいぶ軽減されています。
- Slashing CloudFront change propagation times in 2020 – recent changes and looking forward | Networking & Content Delivery
- CloudFrontの作成や更新時間が約5倍高速になりました | Developers.IO
CloudFront まで設定するハンズオンはあまり無いので面倒だと思われることもあるかもしれませんが、得られるメリットは大きいのでぜひ S3 と CloudFront はセットで使ってみてください。
-
Static website hosting を有効にして Route 53 で独自ドメインを設定 ↩︎
comments powered by Disqus