はじめに
AWS を触り始めたばかりの頃にやらかした初歩的なミスをまとめたアドベントカレンダー、題して「AWS初歩ミス図鑑」の 11 日目です。
今回はワイルドカードというものを知らず、CloudFrontと和解できなかったを書いていきます。
やっていたこと
画像などの静的コンテンツは S3 から配信し、API へのリクエストは ALB に転送するというような構成の CloudFront を実装する必要がありました。
CloudFront をきちんと構築するのは初めてだったので、ドキュメントとにらみ合いをしながら以下のようなビヘイビアを作成します。
/images/image.pngのようなパスは一番上のビヘイビアで処理をされ、/api/exampleのようなパスは次のビヘイビアへ、どれにも当てはまらない場合は一番下のデフォルトへ飛び、ソーリーページが表示される想定でした。
こちらを読んでくださっている皆様におかれましては、送付の画像をご確認いただいた時点で何が起きるのか、何がだめなのかに気が付いた方がほとんどかとは思いますが、この次の段も読んでいただけますと幸いです。
結果
構成後の検証で、どんなパスへアクセスをしてもソーリーページが表示されるという事象が発生しました。
原因の切り分けとして、ALB のエンドポイントへアクセスしたり、S3 の中身をのぞいたりしてみますが、当時の私は何が悪いのか理解できません。
決して少なくはない時間を浪費した後、CloudFront にもログというものがある、ということに気が付き、さっそく確認をすると、すべてのアクセスがデフォルトのビヘイビアに飛ばされていました。
「もしかして、/images/image.pngのようなパスは、/imagesというパスパターンではいけないのでは？」と気が付いたのは、ログを確認してからさらに後でした。その後、ワイルドカードというものの存在を知り、/images/*のような正しいパスパターンを設定することで、無事に解決をすることができました。
まとめ
ワイルドカードという基礎的な仕組みを知らなかったために、無駄な時間を費やしてしまいました……。
また、問題が発生した際の切り分け手順の重要性も痛感しました。ALBかな、S3かな、といろいろなところを見ずに、最初から CloudFront のログを確認していればもっと早く原因に辿り着けたはずです。想定外の動きをしたらまずログを見るという考えは、シンプルですがとても重要だと思います。
余談
この時に得たワイルドカードの知識は、のちに ACM で証明書を取得するときにとても役立ちました。失敗から得る学びもある…というかっこよさげな言葉を残し、この記事を終わりにしようと思います。