Edited at

CloudFront + S3 で静的サイトを運用する際の注意点

More than 1 year has passed since last update.


概要

CloudFront と S3 で静的サイトを構築する場合、以下の 2 種類の構成があります。


  1. CloudFront のオリジンに、 S3 バケットそのものを指定する構成。

  2. CloudFront のオリジンに、 S3 バケットの Static website hosting のエンドポイントを指定する構成。

できることはだいたい同じですが、微妙に差異があるので、比較します。


まとめ

差異
構成 1
構成 2

S3 Static Website Hosting の設定
不要
必要

サブディレクトリのインデックスファイル※1
利用不可
利用可

S3 バケットの安全性

アクセス制限
CloudFront 側のみで完結
S3 側でも設定する必要あり

※1 https://[CloudFront]/foo および https://[CloudFront]/foo/ という URL に対して、 foo/index.html などインデックスファイルを出力する機能。


構成 1. CloudFront のオリジンに、 S3 バケットそのものを指定する構成。

参考: [CloudFront + S3]特定バケットに特定ディストリビューションのみからアクセスできるよう設定する | Developers.IO


主要点


  • S3 バケットはパブリックアクセス可能にしない。

  • S3 バケットの Static Website Hosting は有効にしない


    • 有効にしても実害はないと思いますが、 CloudFront が S3 バケットに直接アクセスするこの構成では、意味はありません。(多分)



  • CloudFront は Origin Access Identity を使って S3 バケットにアクセスする。


メリット


  • S3 バケットへ直接アクセスされることを防げる。


    • → S3 バケットに大量アクセスがきて、課金額が膨れ上がってしまうケースを防げる。



  • S3 バケットの直接アクセスを考えなくていいため、 CloudFront の機能だけである程度のアクセス制限を実現できる。


    • AWS WAF や Lambda@Edge によるプログラマブルな制御など。




デメリット


構成 2. CloudFront のオリジンに、 S3 バケットの Static website hosting のエンドポイントを指定する構成。

参考: Amazon S3 + CloudFront で始める静的サイトホスティング | kuune.org


主要点


  • S3 バケットはパブリックアクセス可能にする

  • S3 バケットの Static Website Hosting を有効にする


メリット


  • サブディレクトリでもインデックスファイルが効く

  • S3 バケットを us-east-1 以外のリージョンで作成しても、すぐ利用できる。


    • 構成 1 のデメリットの逆。




デメリット


後書き


  • サブディレクトリの URL には必ず末尾に index.html まで付ける、というルール化が可能であれば、何の問題もなく構成 1 が良いです。

  • そうでない場合、構成 2 にするのが設定的には楽ですが、セキュリティに対して留意が必要です。


    • 手間とリターンのバランス次第で。