Q&A
> CloudFront とオリジン間の通信をHTTPSのみを利用するようにする→変わらず301応答
> オリジンプロトコルはHTTPSのみ
と書いてありますが、これは途中からオリジンプロトコルをHTTPSに変えたということでしょうか。
CloudFrontがALBの返す301をキャッシュしちゃってるなんてことはないですか？
CloudFrontのキャッシュを一度消したらどうなりますかね。
前提
ECSをターゲットにしたALBをオリジンにして、CloudFrontを新規でたてました。
curl -IでCloudFrontの挙動を確認したら、HTTP/2 301でリダイレクトでレスポンスが返ってきます。
ブラウザ上でも、代替えドメイン名からALBのドメインにリダイレクトされます。
実現したいこと
通常の200でレスポンスが返ってくるようにしたい
サブドメインがALBのドメインにリダイレクトされないようにしたいので
原因、解消方法をアドバイス頂きたいです。
発生している問題・エラーメッセージ
試したこと
- キャッシュキーにhostヘッダーを含める→今度は502を返すようになる(error from CloudFront)
- CloudFront とオリジン間の通信を最初はHTTPのみにしていて、試しにマッチビューワーにした→変わらず
- CloudFront とオリジン間の通信をHTTPSのみを利用するようにする→変わらず301応答
- キャッシュポリシーをCachingOptimizedにする→変わらず
参考にしたドキュメント
https://qiita.com/yuta_vamdemic/items/f717a022539a3e6836f7
https://repost.aws/questions/QUC9nkA3S1Ti2y9vUyL7e2ZA/cloud-front-redirects-301-to-custom-origin-elb-instead-of-caching
https://aws.amazon.com/jp/premiumsupport/knowledge-center/custom-origin-cloudfront-fails/
補足情報（FW/ツールのバージョンなど）
オリジン
- オリジンにはALBを指定
- ALBのターゲットはポート80でECS(FAGATE)に向けている
- リスナーはhttp(80)とhttps(443)で、httpはhttpsにリダイレクトされるようにしている
- 証明書発行で指定しているサブドメインはCloudFrontとは別(例：test1.test.com)
CloudFront
- サブドメインとして代替えドメインと証明書を発行して、Route53でエイリアスで指定している(例:test2.test.com)
- オリジンプロトコルはHTTPSのみ
- ビヘイビアはビューワープロトコルがHTTPからHTTPSへリダイレクト
- httpメソッドはGET, HEAD, OPTIONS, PUT, POST, PATCH, DELETE
- キャッシュポリシーのヘッダーにAuthorizationHeaderを含めるようにしている
- 他はデフォルト設定
不足情報あったらすみませんが教えてください、宜しくお願い致します。
情報抜けていてすみません、最初はhttpのみにしていて、途中からマッチビューワー→httpsのみに変更しました。
その可能性もあるような気がするので、キャッシュを消す方法調べて試してみます。
@yu_1985
https://dev.classmethod.jp/articles/aws-amazon-cloudfront-deleting-cache-by-invalidation/
上記を参考に同じやり方でキャッシュを削除してみたのですが、今度は502のError from cloudfrontが返ってきてしまうようになりました。
やり方を間違えたのでしょうか。。
CloudFrontのステータスコードとそのときに考えられる原因についてはドキュメントにあるのでそちらを確認してみてください。
https://docs.aws.amazon.com/ja_jp/AmazonCloudFront/latest/DeveloperGuide/http-502-bad-gateway.html
ALBへのリクエストをHTTPSにするのはいいんですが、そのALBはちゃんとCloudFrontからのHTTPSのリクエストを受けることはできるようになっていますか？
カスタムドメインを使って証明書を適用する必要があるかと思いますが…。
ありがとうございます、確認します。
ALBへのリクエストをHTTPSにするのはいいんですが、そのALBはちゃんとCloudFrontからのHTTPSのリクエストを受けることはできるようになっていますか？
上記についてはリスナーの設定のことであってますか？httpsを有効にするように、カスタムドメインで証明書を適用しています
オリジンを指定するときにちゃんとALBのカスタムドメインを指定していますか？
オリジンを指定するときに、プルダウンで出てくるALBを選択しています。
証明書発行したときのカスタムドメイン名で指定するのが正しい、ということでしょうか？
そうしないと証明書のドメインと別のドメインでアクセスしてることになって証明書が効かないと思います。
なるほど、、CloudFrontでもALBでも、同じカスタムドメインのそれぞれ違うサブドメインを使っているのですが
それだと証明書が効かない、またはドキュメントにあるように502エラーの要因になっているということですかね？
ALBとバックエンドのサーバーに影響でないように、サブドメインでCloudFrontをたてて、CloudFrontの証明書もそのサブドメインで発行しているので、そこをALBと同じにしないといけないってことですよね
> なるほど、、CloudFrontでもALBでも、同じカスタムドメインのそれぞれ違うサブドメインを使っているのですがそれだと証明書が効かない、またはドキュメントにあるように502エラーの要因になっているということですかね？
いえ、そうではなくCloudFrontのオリジンとしてALBを指定するときにALBに割り当てたドメインで指定しないとHTTPSでオリジン（ALB）にアクセスするときに証明書のエラーになるのではないかということです。
失礼しました、証明書のエラーが起きてるのって目視で確認できるのでしょうか？
今のところ、改めて確認しても301応答は変わらずですがそれっぽいエラーが出ているようには見えなくて
キャッシュを消したら502になったと書いてあるのでそうではないかと思ったのですが、また何か設定を変えましたか？
すみません、そうですよね
CloudFrontのオリジンを、一度ALBに割り当てているドメインに変更して、curl -Iで試してみたら、今度は401エラーが返ってきたので、
一度もとのプルダウン式で出るALBを指定し直したら、301に戻りました
「xxxのエラーが出た」だけではあまり状況がわかりません。
まずCloudFrontが返しているエラーなのかオリジンが返しているエラーなのかを切り分けてください。
CloudFrontが返したエラーならドキュメントを読んでからさらに切り分けてください。
オリジンが返しているならALBのえらーなのかその先のサーバーやアプリケーションのエラーなのかを切り分けてください。
知識不足で説明がかけてしまいすみません。
恐らく、オリジンサーバーのAPIで Bearer認証をするようにしているので
Authorization: Bearerをリクエストで渡す必要があったんじゃないかと思います。
curl -H GET 'https://XXXX' -H 'Authorization: Bearer XXXX'
上記を試したら
curl: (92) HTTP2 stream 0 was not closed cleanly:PROTOCOL_ERROR(err 1)
を返されたので、プロトコルに問題がありそうな気がしてます。
仰るようにドキュメントなど読んで原因追及したいと思います。
回答1件
0
自己解決
cloudfront側の設定が問題でした。
CloudFrontのオリジンとしてALBを指定するときに、ALBに割り当てたドメインで指定していなかった。
HTTPSでオリジン（ALB）にアクセスするときに証明書のエラーになる要因となった。
（コンソールでオリジンドメインを指定する時に、プルダウンで出てくるALBを選択していた）
投稿2022/09/30 10:06
総合スコア11
あなたの回答
tips
プレビュー
