【AWS×Django】サイトにアクセスができてもHealth checks failed with these codes:[404]

awsとdjangoを利用してwebサイトを開発しているときに発生したエラーです。

デプロイ済みのサイトに私がブラウザでアクセスした時は問題なくサイトは表示はされるですが、awsのEC2のターゲットグループでヘルスステータスを確認した時は、unhealthyのステータス表示にされています。

本記事では、このターゲットグループの状態がunhealthyが表示される問題を解決していきます。

発生原因

発生タイミングは、djangoのsettings.pyのALLOWED_HOSTSを書き換えると表示がhealthyからunhealthyに変わります。

awsのターゲットグループではaws内部の自動化された内部ツールがサイトに連続的なアクセスを試みているものと思われますが、ALLOWED_HOSTSで全てを許可（”*”）を書き換えたためクライアントがアクセスしたにも関わらず何らかの誤りや問題があり400エラーで起因したものと考えられます。

初期状態は以下のような表示になっています。

settings.py

私の場合も、webサイトを作成して取得したドメインを以下のように書き換えてからunhealthyに変わっていることに気づきました。

settings.py

ALLOWED_HOSTS = [“*”]のように全てを許可することで、unhealthyの回避ができますが、セキュリティ上よくはありません。

自らが設定したい正しいURLをALLOWED_HOSTSに記述してこそ、セキュリティ的にも安心できます。

解決方法

解決方法として、awsのインスタンスメタデータを実行中のインスタンスから取得して、djangoのsettings.pyのALLOWED_HOSTSに追加することで回避することができます。

まずはこれを利用するためにrequestsモジュールが必要になりますので、インストールを実行します。

以下の内容はそのままコピペして何も変更をせずに使用可能です。

EC2_PRIVATE_IPに関してはここでは割愛しますので、後述する参考よりawsをご確認ください。

settings.py

準備ができたので、改めてawsのターゲットグループでヘルスステータスを確認します。

ヘルスステータスが問題ないことを確認できました。

以上。

参考

aws：https://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html

stack overflow：https://stackoverflow.com/questions/54739178/elastic-beanstalk-health-severe-failing-with-a-code-400-even-though-i-can-vi

最後に

いかがでしたでしょうか。

以上が、「【AWS×Django】サイトにアクセスができてもElastic Beanstalk Health Severe, failing with a code 400 — even though I can visit my site」の紹介記事になります。