概要
Let's encryptの証明書でSSL化していたが、認証の強度を上げるためにAWS Certificate Manager発行の証明書を使用するように変更したい。
変更前の構成はELBなしのEC2インスタンス1台にnginxサーバを設置していた。
そのままnginxにACMの証明書を適応しようとしたのですが、それには
Nitro System上に構築されるEC2インスタンスで、CPUが4vCPU以上
ACMのSSL証明書(Amazonの無料証明書)をEC2(Apache)で利用してみた
と制約が多くめんどくさそうでした。
一方ALBにACM証明書適応するのは簡単そうなうえ、１台のEC2でもELBを使うメリットについてまとめてみました によるとALBかませる方が健全っぽいのでALBの後ろに1台のEC2をつけることにしました。
構成
最終的な構成はこんな感じです。非常に簡素。
実装
ターゲットグループ作成
ターゲットはEC2が1台だけなので、ターゲットタイプにインスタンスを選択。
ALB,TG間は、httpでの通信のみなのでリスナーのプロトコルは80のみ設定。
次のhealth checkは結構ハマりがちなのでちゃんとしましょう。
他の記事などではデフォルトでOKとありますが、動かすアプリによります。
私は、ルートドメイン(DOMAIN/)にアクセスあった場合にログイン画面(DOMAIN/login)に301でリダイレクトにする設定にしていました。
なのでデフォルトのヘルスチェックだと200が返らずずっとunhealthyでした。
しっかりAdvanced Settingまで開き、uccessコードに301を追加しましょう。
(私の場合だと、もしくはHealth check pathを/loginにするのでもいいです。)
次の画面でターゲットにするEC2インスタンスを80ポートで追加して作成。
ALB作成
一番左のALBを作成。
Listeners and routing欄では、
80ポートのリスナーに443ポートへのリダイレクト処理、
443ポートには先ほど作成したターゲットグループへのルーティングを設定して作成。
nginx側の設定
最後に、通常のウェブアプリならhttpをhttpsにリダイレクトする処理などがあるはずなので、それを削除してhttpのみ受け付ける設定にしましょう。
そうしないとALBからはhttp通信しか来ないので永遠にリダイレクトされます。
大体のnginxであれば、
/etc/nginx/conf.d/app.conf
などで、listen 443とリダイレクトやってるはずなのでコメントアウトして80のみ受け付けるようにしてください。