この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので十分ご注意ください。
わたしは「マルチAZ構成のWordPressサイトにCloudFront＆S3を組み合わせてみた」を構築している際に、CloudFrontディストリビューションの設定に悩まされました。
作成したドメイン名でアクセスしようとすると、表示されるのは、
“502 ERROR”
“403 ERROR”
“エラー”
“エラー”
“エラー”。
今回の構築でわたしが直面したCloudFront由来のエラーとの戦いと、どのように戦ったのかを紹介していきます。他にも戦い方があるよ！という方は、コメント欄などでぜひご教示お願いいたします。
齊藤 VS CloudFront
齊藤とCloudFrontとの戦いは、「マルチAZ構成のWordPressサイトにCloudFront＆S3を組み合わせてみた」の構築終盤で起こりました。Route53で自身のドメインのレコード編集から、ルーティング先をALBからCloudFrontディストリビューションに変え、ドメイン名でサイトにアクセスしようとした時のことです。
第1ラウンド:502エラー
最初に表示されたのは、“502 ERROR”です。
まずはAWS公式ドキュメントを確認しました。
解決法を読んでみると、オリジンの設定に問題がありそうでした。とりあえず解決方法を上から試しましたが、ずっと502エラーが表示されます。
CloudFrontディストリビューションにはオリジン以外に、ビヘイビアの設定もあります。次にビヘイビアの設定を見直しました。
ビヘイビアの設定の中に、オリジンに関係しそうな項目の“キャッシュキーとオリジンリクエスト”がありました。
現在設定しているキャッシュポリシーは“CachingOptimized”です。AWS公式ドキュメントで上記のキャッシュポリシーに関して調べてみました。
名前: CachingOptimized
ID: 658327ea-f89d-4fab-a63d-7e88639e58f6
このポリシーは、CloudFront がキャッシュキーに含める値を最小限に抑えることで、キャッシュ効率を最適化するよう設計されています。CloudFront は、キャッシュキーにクエリ文字列や Cookie を含めず、正規化された Accept-Encoding ヘッダーのみを含めます。これにより CloudFront は、オリジンがオブジェクトを返すときまたは CloudFront エッジ圧縮が有効になっているときに、Gzip 圧縮形式と Brotli 圧縮形式でオブジェクトを個別にキャッシュできます。
ポリシー設定
最小 TTL: 1 秒。
最大 TTL: 31,536,000 秒 (365 日)。
デフォルト TTL: 86,400 秒 (24 時間)。
キャッシュキーに含まれるヘッダー: 明示的に含まれているものがありません。圧縮オブジェクトのキャッシュの設定が有効になっているため、正規化された Accept-Encoding ヘッダーが含まれます。詳細については、「圧縮のサポート」を参照してください。
キャッシュキーに含まれる Cookie: なし。
キャッシュキーに含まれるクエリ文字列: なし。
圧縮オブジェクトのキャッシュの設定: 有効。詳細については、「圧縮のサポート」を参照してください。
ポリシーの内容を変えて試してみます。ポリシー作成をクリックしてください。
他のブログを参考にヘッダーとクエリ文字列を変更してみました。
↓
↓
無事サイトのトップページが表示されました。WordPressにログインしようとすると、次の戦いが待っていました。
第2ラウンド：ログインエラー＆403エラー
https://ドメイン名/wp-admin でログイン画面にアクセスし、IDとパスワード入れてみると、
“Cookiesがブロックされているか、お使いのブラウザーで未対応のようです。WordPressを使うにはCookieを有効化する必要があります。”と表示されています。
ログインを数回試していると、
ログインエラーが出たときはブラウザの問題かと思っていましたが、403エラーが出たおかげでCloudFrontの問題だと認識できました。
AWS公式ドキュメントでCloudFrontの403エラーに関するトラブルシューティングを読むと、今回もオリジン関係が多いです。
まず本当にCloudFrontの問題なのか、ルーティング先をCloudFrontディストリビューションからALBに変更してみます。※すぐに反映されないので、時間をおきましょう。
無事WordPress画面にログインできました。CloudFrontの設定に問題があるようなので、ルーティング先をALBからCloudFrontディストリビューションに戻しておきます。
502エラーの時に問題になったキャッシュポリシーを探ってみました。AWSが用意している管理キャッシュポリシーは、
- CachingOptimized
- CachingOptimizedForUncompressedObjects
- CachingDisabled
- Elemental-MediaPackage
- Amplify
の5つがあり、すべて試してみました。
試した結果、キャッシュポリシーがAmplifyの場合、ログインすることができました。
502エラーの際に作成したキャッシュポリシーと、Amplifyのポリシーの中身を比較すると、
↓502エラーの際に作成したキャッシュポリシー
↓管理キャッシュポリシー“Amplify”
両者の違いは、
- ヘッダーの“CloudFront-Viewer-Country”
- cookieがすべて
の2点です。
WordPressログイン時にcookieに関するエラーが表示されていましたので、作成したキャッシュポリシーのcookieのキャッシュキー設定を“すべて”に変更してみます。
WordPressログイン画面からログインしてみます。https://｛ドメイン名｝/wp-admin にアクセスし、ユーザ名とパスワードを入力してみてください。
無事ログインすることができました。お疲れさまでした。
まとめ
今回紹介したCloudFrontディストリビューションの設定に関しては、まだまだ検証途中です。しかし、CloudFrontディストリビューションの設定を触っていて、ビヘイビア設定にある“キャッシュキーとオリジンリクエストの設定”が重要であると感じました。
特にキャッシュポリシーに関しては、パスパターンによってキャッシュキー設定を変える必要があると感じています。もしCloudFrontの設定でわからない部分がありましたら、AWS公式ハンズオンのAmazon CloudFrontおよびAWS WAFを用いて エッジサービスの活用方法を学ぼうを参考にしてみてください。「#5 Amazon CloudFrontのハンズオン その2 (コンテンツキャッシュの設定)」は必見です。
今後もCloudFrontの学習を続け、記事に追記していきますのでよろしくお願いいたします。
参考リンク：CloudFront からの 403 エラーをトラブルシューティングするにはどうすればよいですか?,CloudFront からの 502 「リスエストに失敗しました」エラーをトラブルシューティングするにはどうすればよいですか?,AWS Hands-on for Beginners
↓ほかの協栄情報メンバーもCloudFrontに関する記事を公開しています。ぜひ参考にしてみてください。
■S3静的ウェブサイト+CloudFrontの構築(INAMURA)
https://cloud5.jp/cloudfront_statically_page_hosting_by_s3/
■CloudFrontでOrigin Access Control (OAC)を利用したアクセス制御のハンズオン(INAMURA)
https://cloud5.jp/oac_used_access_control/