CodlessCode
AWS

CloudFront + S3 で 静的 Webサイトを配信

CloudFront と S3 で静的コンテンツを配信するメモです。

静的コンテンツとは、
だれが見ても同じように表示されるコンテンツやWebページのことを指したりします。

動的コンテンツとはその逆で、ユーザーによって見せる情報が違ってくるコンテンツです。(例えばユーザーの登録情報とか)

クラウドでは、このようなコンテンツを分けて配信することで
コスト削減やパフォーマンス向上、さらに可用性を高められるので重要視されます。

今回やるのは
CloudFront と S3 を使って静的コンテンツを配信する
よくある方法です。

アプリケーションの規模は関係なく、この方法はよく取られる手法なので、知っておいて損はないはずです^^

 

CloudFront と S3 で 静的 コンテンツを配信する概要

全体像

静的コンテンツ配信設計図

とてもシンプルな構成です!

 

S3 を準備

バケットを作成

以下のように入力して「バケットを作成」します。
任意で入力する箇所は適宜読み替えてください。

S3バケット作成1
S3バケット作成2
S3バケット作成3

バケット名任意で入力
AWSリージョンアジアパシフィック(東京)ap-northeast-1
オブジェクト所有者ACL無効(推奨)
パブリックアクセスをすべてブロックチェックはずす
デフォルトの暗号化有効にする、SSE-S3
その他デフォルト設定のまま

パブリックアクセスをブロックすると、バケットポリシーの変更などの
この後の作業ができないので注意です。

 

バケットポリシーを修正

バケットポリシーとは、このバケットを見ていい人、ファイルをアップロード・削除していい人など決めるための
バケットに対する操作権限の設定です。

作成したバケットを開き、アクセス許可タブのバケットポリシーを以下のように編集して保存します。
Resourceは、作成したバケットARNに合わせて置き換えてください。

{
	"Version": "2012-10-17",
	"Statement": [
		{
			"Sid": "Statement1",
			"Principal": "*",
			"Effect": "Allow",
			"Action": "s3:GetObject",
			"Resource": "【バケットARN】/*"
		}
	]
}
S3バケットポリシー
 

HTMLファイルを配置

index.htmlとerror.htmlを作成してバケット直下にアップロードします。

S3バケットの中身

ファイルの中身は以下のようにしました。

 

index.html

<html>
    Welcome
    Tokyo Region
</html>

 

error.html

<html>
    Error
    Tokyo Region
</html>
 

静的 ホスティングを有効化

バケットポリシーを修正したら、
プロパティタブに移動して一番下までスクロールし、静的ウェブサイトホスティングを編集します。

以下のように入力して「変更の保存」をします。

静的ウェブサイトホスティング有効にする
ホスティングタイプ静的ウェブサイトをホストする
インデックスドキュメントindex.html
エラードキュメント – オプションerror.html
 

静的 ウェブサイトの動作確認

再びプロパティタブの一番下までスクロールし、静的ウェブサイトホスティングのバケットウェブサイトエンドポイントをブラウザで開いてみましょう。

バケットウェブサイトエンドポイント

以下のようになったら成功です。
バケットウェブサイトエンドポイントへHTTP接続によって、ウェブサイトにアクセスできました!

静的ウェブサイトの動作確認
 

静的 ウェブサイトのドメインをメモ

静的ウェブサイトの動作確認ができたら
そのドメイン(http://を除いたもの)をメモしておきます。
これをCloudFront作成の時にオリジンドメインとして設定します。

 

CloudFront を準備

ディストリビューションの作成

以下のように入力して「ディストリビューションを作成」する。

オリジンドメインはプルダウンから選択せず、先ほどメモしたドメインを入力します。

オリジンドメインさっきメモしたドメイン
名前自動で入力されるので触らない
ビューワー/ビューワープロトコルポリシーHTTPS only
キャッシュキーとオリジンリクエスト
  • Cache policy and origin request policy (recommended)
  • CachingDisabled
その他の項目デフォルトのまま

CachingDisabledにしてキャッシュを無効にしているのは、開発中の変更がすぐに反映されるようにするためです。
通常は CachingOptimized とかで適切なキャッシュ期間を設定します。

 

ディストリビューションのデプロイ完了まで待つ

CloudFrontのデプロイが完了するまで数分くらいかかるので待ちます。
以下のようにディストリビューション一覧でデプロイが日付になっていたら完了です👇

作成直後
CloudFront作成直後

デプロイ完了
CloudFrontデプロイ完了

これで完了です!

 

動作確認

CloudFront にアクセス

作成したCloudFrontの一般タブに移動し、詳細のディストリビューションドメイン名をブラウザで開いでみましょう。
S3の静的ウェブサイトと同じように表示されたら成功です!
HTTPS接続によって、安全な接続で静的ウェブサイトにアクセスできました!

CloudFrontにアクセス
 

index.htmlを削除すると…?

S3バケットのindex.htmlを削除してみましょう。
すると以下のようにエラーページ表示されたはずです。

エラーページを表示

S3の静的ウェブサイトホスティングを有効にした際、オプションであったエラーページも設定したからです。

万が一、ウェブサイトでエラーが発生した場合でも、エラーページを設定しておけば、このように表示することができます。

終わりに

お疲れ様でした😊
とても簡単にウェブサイトを公開できましたね。

次のアクション

次のアクションはアクセス制限をすることです。

今のままでは、S3のバケットウェブサイトエンドポイントからアクセスできてしまいます。
これによるデメリットは

  • HTTPアクセスできるので安全な接続でない
  • CloudFrontを使わないアクセスの信頼性とパフォーマンスを最適化できない
  • S3への直アクセス分、余計にコストがかかる

などでしょう。それに
せっかく、CloudFrontからHTTPSアクセスできるようにして安全な接続経路を作ったのだから、入口はこれ1つにしちゃいたいですね。
その方法として、カスタムヘッダー(Referer)を使う方法があります。

注意点として、Refererヘッダーで不正アクセス対策をするのは不十分だということです。ヘッダー値は見れますし偽装できますからね。
セキュリティとしては他の対策も導入したうえで、併用するのが良さそうです。

とはいえ、ウェブサイトへの入口を1つにする方法としてある程度は有効なのかなと思ってますので
次回はカスタムヘッダーで制限された静的ウェブサイトを構成してみようと思います。
こちらです👇

【 S3 + CloudFront 】カスタムヘッダーで制限された 静的 ウェブサイトを構成して入口をひとつにするCloudFrontとS3で配信する静的ウェブサイトに対し、Refererヘッダーを設定して、CloudFront経由のアクセスのみ通すように構成します。前回は、CloudFrontとS3で静的コンテンツを配信できるようにしました。CloudFrontとS3どちらからでもサイトにアクセスできる状態なので、ウェブサイトへの入口をCloudFrontのみにしてみます😊...

参考になれば幸いです👋

リソースが不要になったら削除することをお忘れなく!