概要

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

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

まとめ

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

S3 バケットはパブリックアクセス可能にしない。
S3 バケットの Static Website Hosting は有効にしない。
- 有効にしても実害はないと思いますが、 CloudFront が S3 バケットに直接アクセスするこの構成では、意味はありません。(多分)
CloudFront は Origin Access Identity を使って S3 バケットにアクセスする。

S3 バケットへ直接アクセスされることを防げる。
- → S3 バケットに大量アクセスがきて、課金額が膨れ上がってしまうケースを防げる。
S3 バケットの直接アクセスを考えなくていいため、 CloudFront の機能だけである程度のアクセス制限を実現できる。
- AWS WAF や Lambda@Edge によるプログラマブルな制御など。

サブディレクトリのインデックスファイルが効かない。
- S3 バケットに foo/index.html というファイルがあり、 https://[CloudFront]/foo および https://[CloudFront]/foo/ という URL でアクセスしようとしても、エラーになってしまう。
- インデックスファイルは、ルートディレクトリでのみ効く。
- Lambda@Edge を使えば、この機能をある程度エミュレートすることが可能。
  - 参考: できた！S3 オリジンへの直接アクセス制限と、インデックスドキュメント機能を共存させる方法｜ Developers.IO
  - ただし (オリジンへの) 全アクセスに対して Lambda が起動するので、パフォーマンス&コストには注意が必要。
S3 バケットを us-east-1 以外のリージョンで作成した場合、そのバケットを作成してから 1-2 時間？経たないと、正常に動作しない。
- Cloudfront,S3で307リダイレクトに苦しめられた - パパエンジニアのアウトプット帳
- その他【CloudFront S3 リダイレクトされる】で検索

S3 バケットの名前が漏れると、 S3 バケットへ直接アクセスされてしまう。
- Amazon S3 + CloudFront で始める静的サイトホスティング | kuune.org にある通り、バケットのポリシーで User Agent による制限を行うことは可能だが……。
- S3の静的ウェブサイトをカスタムオリジンとしてCloudFront運用する場合のS3側接続制限について - Qiita では、S3 バケットのバケットポリシーを定期的に自動更新し、 CloudFront の IP アドレスからのみアクセスできるようにする構成が解説されている。
S3 バケットに直接アクセスされてしまうため、 CloudFront でアクセス制限を行っていても、それだけでは不十分になってしまう。