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

はじめに

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

• オリジンアクセスアイデンティティを使って、S3バケットへのアクセスをCloudFrontディストリビューションからのみに制限する方法
• S3の静的ウェブサイトホスティングを有効化し、CloudFrontにカスタムドメインとして設定する方法

前者がベターに思えるかもしれませんが、後者の方が良い場合もあります。それは ランディングページなどのシンプルな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であることが分かりやすく表示されています。

エラーページの扱いが楽

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

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

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

まとめ

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