はじめに
AWS を触り始めたばかりの頃にやらかした初歩的なミスをまとめたアドベントカレンダー、題して「AWS初歩ミス図鑑」の 8 日目です。
今回はS3 のインデックスドキュメントを軽んじていた話を書いていきます。
やっていたこと
社内の静的サイトを S3 + CloudFront で配信する構成に移行する作業を行っていました。既存のサイトは EC2 上の Apache で動いていて、サーバー内の index.html というファイルがデフォルトで表示される状態になっています。
こちらのサイトには index.html の役割を兼ねるページが複数あり、既存の構成では「一度 index.html へアクセスする → メニューから目的の index.html へアクセスする」という経路だったのですが、今回の構成変更を機に「index.html を経由することなく、最初から URL で表示したいページを選べたらいいよね」というかねてからの要望を実装することになりました。
つまり、既存環境ではデフォルトページがindex.htmlでしたが、構成変更によりtop-index.htmlのようなファイル名へ変更となったのです。
S3 や CloudFront 等リソースの設定は私が行い、実際に配置するコンテンツは別部署の方が用意したものを使用することになっていました。静的コンテンツの設定は、新規作成こそないもののリプレイスなどで経験があるので、自信もばっちりです、
何もかもが順調に見える中で、ついに構成変更の日を迎えます。
結果
もう察されている方もいるかと思いますが、インデックスドキュメントの修正を忘れ、期待通りのページが表示されませんでした。
「どれだけページを更新しても別部署の方に修正してもらったindex.html表示されない…！なぜ…！」「S3 にキャッシュとかなかったよね…？ブラウザの問題…？」とめちゃくちゃに頭を悩ませていた私に、先輩が「いちどバケット名/ファイル名でアクセスして、ファイル自体が正常に表示されるか試してごらんよ」という鶴の一声を授けてくださり、無事に原因を切り分けることができました。
何を考えていたのか
いままで触っていたのがほとんどデフォルト構成だったので、インデックスドキュメントを別途設定する必要がある、ということを失念していました。
「S3で静的コンテンツを表示したい＝index.htmlという名前のファイルがあればとりあえず良い」という思い込みで、そもそも index.html が存在しないときは別途それを設定しなければならないという考えがありませんでした。
まとめ
静的ウェブサイトホスティングは、チェックボックス一つで設定を有効化できるわりには、意外とたくさんの設定項目があります。（なんとリダイレクトルールも設定できます。）
すべてデフォルトなら問題ないですが、今回のようにインデックスやエラーページに独自の要件がある場合は、設定ページを注視し、私のように慌てふためくことがないようにしていただければと思います。