ちょっと話題の記事

Amazon S3 + Amazon CloudFrontでWebサイトを構築する際にS3静的Webサイトホスティングを採用する理由

静的Webサイトを構築する際、CloudFrontを使う場合でもS3静的Webサイトホスティングを有効化した方が良い場合があります。本記事では、どういったメリットがあるか解説します。
2020.03.17

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

はじめに

静的Webサイトを構築する際にAmazon S3とAmazon CloudFrontを利用するアーキテクチャは定番ですが、これらを利用したアーキテクチャには2つの手法があります。

前者がベターに思えるかもしれませんが、後者の方が良い場合もあります。それは ランディングページなどのシンプルなHTMLベースで構築するWebサイトの場合 です。

本記事では、どういった理由でS3のウェブサイトホスティングを採用するか解説します。

リダイレクト設定がかんたん

静的Webサイトホスティングにはリダイレクトを自由にカスタマイズできるRedirection Ruleという機能があります。この機能を使うことで、すでに公開しているパスを変更したとしても、変更後のパスに誘導することができます。

index.html が無くてもアクセスが可能

例えば /hoge というパスのページ用意する場合 index.html まで書く、書かないに関わらずアクセスさせたいという要件がよく出てきます。

ランディングページなどはSNSでシェアされることなども考慮しますが、シェアされるリンクにブレが出てくる場合があります。例えば以下の3つのURLは微妙に異なりますが、全てアクセス可能にできるようになっていることが理想です。

  • https://xxxxx/hoge
  • https://xxxxx/hoge/
  • https://xxxxx/hoge/index.html

オリジンアクセスアイデンティティを利用した場合はLambda@Edgeを併用しなければ実現が難しいですが、静的Webサイトホスティングの場合はデフォルトでこれが有効です。

一目で公開されているS3バケットだと分かる

管理目的でS3のバケットを確認しようとした場合、静的Webサイトホスティングが有効であることが分かります。S3のManagement ConsoleではPublicであることが分かりやすく表示されています。

s3-static-website-hosting01

エラーページの扱いが楽

静的Webサイトにおけるエラーページといえば概ね「404」ですが、この扱いが楽か、そうでないかが異なります。

オリジンアクセスアイデンティティの場合、存在しないパスへのアクセスは構成上の関係で「403」となります。これはS3に該当のキーのオブジェクトが存在しないためです。CloudFrontのCustom Error Responseで404に変更することも可能ですが、本当に403を返したい場合との兼ね合いも考える必要があります。

s3-static-website-hosting02

静的ウェブサイトホスティングの場合はデフォルトで404のエラーページに飛びます。

s3-static-website-hosting03

まとめ

SPA (Single Page Application)が主流になってきた現在では、何となく「Webサイト構築はS3のオリジンアクセスアイデンティティでやるもの」という認識を持ちがちですが、S3のWebサイトホスティングにはオリジンアクセスアイデンティティの方法にはないWebサイト向けの機能がいくつかあります。本記事の内容を、静的Webサイト構築時の参考情報としていただけると幸いです。