ALB⇔CloudFront間SSL/TLS対応記録

概要

ALBの前段にCloudFrontを設置しているインフラ構成のALB⇔CloudFront間の通信をSSL/TLS通信に対応させる手順の記録。

Laravel製のWEBサービス側でx-forwarded-protoやx-forwarded-portといったヘッダ情報の取得がうまくいかず、Breezeによるログイン処理の一部の機能で期待しない動作をする箇所があったため対応した。

詳細

１．【Rotue53】ALB・CloudFront間の通信に利用するサブドメインの取得

参考：

【AWS】Route 53で新しいドメイン・サブドメインを取得する - Qiita

＊ドメインはすでに取得していて、ACMで*.ドメイン名で証明書を取得している前提

やること

• Route53のホストゾーンの中で、新規レコードを作成する
• 「alb.ドメイン名」に設定し、Aレコード、エイリアスレコードを指定
• ALBを設定している東京リージョンを指定し、dualstackから始まるDNS名を指定

２．【ALB】リスナールールの追加

コンソール画面：EC2 > ロードバランサー > alb名 > リスナーの追加

やること

• プロトコルをHTTPSに指定
• アクションのルーティングでターゲットグループへ転送を指定
• ターゲットグループの指定
• 「セキュアリスナーの設定」
  • 証明書の取得先を「ACMから」に指定
  • 証明書を指定

３．【ALB】リスナールールからHTTP用の設定を削除

選択して消すだけ。

戻せるようにはしておきましょう。

４．【CloudFront】ALB用のオリジンのオリジンドメインを書き換える

やること

• Origin domainの欄を編集し、1.の手順で作成したレコードを指定。（alb.ドメイン名）
• プロトコルをHTTPSのみに変更

最後に

動作確認を行います。

設定がミスっていれば502エラーが発生しているかもしれません。

アプリケーションが正常に動作していれば完了です。

今回解決したかった、LaravelのBreezeを利用した認証機能の確認メールの部分の処理がヘッダ情報の不足によって正常に動作しない問題はこちらで解決することができました。