【AWS_50】Amazon Route 53 、Application Load Balancer (ALB)、AWS Certificate Manager (ACM) を連携し、HTTPS通信のWEBサーバを構築する

先日、Amazon Route 53 でドメイン名を取得し、WEBサーバの名前解決を検証してみました。

【AWS_49】Amazon Route 53 でドメイン名を取得し、WEBサーバの名前解決を検証する

今回はその延長としてAmazon Route 53 、Application Load Balancer (ALB)、AWS Certificate Manager (ACM) を連携し、HTTPS通信のWEBサーバ環境を構築したいと思います。
流れとしては、一度、ALBの負荷分散環境を構築してHTTP通信を確認した後、HTTPS通信できるように設定していきます。
そのため、全体としてはちょっと長くなっています。

以下サイトを参考にさせていただきました。

AWSチュートリアル（Webサーバを作ってみよう）第2章：ALB編②（Route53、ACM）
https://www.k-friendly.com/18974

本検証では、セッションマネージャーを利用してパブリックサブネットのEC2インスタンスへSSH接続します。
記事の中では設定方法に触れておりませんため、必要な場合は以下の記事を参考にしてください。
※TeratermなどでSSH接続しても設定はできますのでセッションマネージャーの設定は必須ではありません

【AWS_48_01】セッションマネージャーを利用してパブリックサブネットのEC2インスタンスへSSH接続する

今回の構成は、以下のとおりです。セッションマネージャーに関しては触れておりません、ご了承ください。

　　　

Route53へドメインの登録

AWSマネジメントコンソールで「route53」を検索します。
「Route53の使用開始」が表示された場合は、「開始する」をクリックします。
「Route53ダッシュボード」画面が表示されている場合は、「ドメインの登録」をクリックして進めます。
今回私は、はじめて利用するので「Route53の使用開始」が表示されましたのでその手順で進めます。

「開始する」をクリックします。

「開始点を選択」で「ドメインを登録」を選択し、「開始する」をクリックします。

取得したいドメイン名を入力し、空きがあるか確認します。
どのような状態になったら空きがあるのか確認するため、このサイトのドメイン名である「tkjzblog」を入力しています。
すると「tkjzblog.com」は利用不可となり、なんとなくこの画面のつくりが理解できました。

使い方がわかったのでドメイン名の候補を入れて検索します。
「.com」が年間 15.00 USD となっているのでこれで進めたいと思います。
「選択」をクリックすると「選択済み」に変わるので画面右側の「チェックアウトに進む」をクリックします。

ドメインの料金オプション画面で自動更新されたくないので「自動更新」のチェックを外します。
「次へ」をクリックします。

連絡先(氏名、住所、電話番号、メールアドレス)を入力します。その他はデフォルトのままとします。
入力した内容がwhoisで検索可能になるのを抑止するため、「xxxxx.comの連絡先のプライバシー保護をオンにする」をチェックします。
「次へ」をクリックします。

確認して送信画面で入力内容を確認します。
利用規約を一読し、チェックを入れて「送信」をクリックします。

登録済みドメイン画面へ遷移します。ドメイン登録のリクエストが進行中というメッセージが表示されます。
「ステータスを確認」をクリックすると状況が確認できます。

リクエスト画面でステータスが「進行中」であることが確認できます。

登録したメールアドレスに確認メール(タイトル：Verify your email address for xxxxx.com)が来るので、本文中の確認用リンクをクリックします。

メールに届いた確認用リンク押下後、AWS画面へ戻り、左ペインのドメイン >  リクエスト を選択すると新規申請したドメインが「成功」になっていることが確認できます。

左ペインのドメイン >  登録済みドメイン にも登録されました。

さらに左ペインのホストゾーン をクリックします。パブリックホストゾーンが登録されました。

　　　

VPC などの作成

今回は、VPC作成時にサブネットやインターネットゲートウェイなどもいっきに作成されるように進めたいと思います。
AWSマネジメントコンソールで「vpc」を検索します。
左ペインのお使いのVPCをクリック、画面右上の「VPCを作成」をクリックします。

作成するリソースは、「VPCなど」を選択します。
名前タグの自動生成の欄に任意の名前を入力します。今回は「20250828-vpc」としました。自動作成のチェックは入れたままにします。
IPv4 CIDR ブロック は、デフォルトままの 10.0.0.0/16 とします。
テナンシーは、デフォルトのままにします。

アベイラビリティゾーン(AZ)の数が 2 になっていることを確認します。
「AZのカスタマイズ」をクリックして、アベイラビリティゾーン選択が以下になっていることを確認します。
第 1 アベイラビリティゾーンが apne1-az4（ap-northeast-1a）
第 2 アベイラビリティゾーンが apne1-az1（ap-northeast-1c）

パブリックサブネットの数が 2 になっていることを確認します。
プライベートサブネット数が 2 になっていることを確認します。（本検証では利用しませんが・・・）
「サブネット CIDR ブロックをカスタマイズ」をクリックして以下を入力します。
　1番目のサブネットの CIDR ブロックのap-northeast-1aを 10.0.1.0/24 に変更
　2番目のサブネットの CIDR ブロックのap-northeast-1cを 10.0.2.0/24 に変更
　3番名のサブネットの CIDR ブロックのap-northeast-1aを 10.0.3.0/24 に変更
　4番目のサブネットの CIDR ブロックのap-northeast-1cを 10.0.4.0/24 に変更

NAT ゲートウェイは「なし」を選択します。
VPC エンドポイントは「なし」を選択します。
DNS オプションはデフォルトのまま(チェックが入ったまま）にします。
追加のタグもデフォルトのままにします。
「VPC を作成」をクリックして、VPCを作成します。

VPCワークフローの作成画面で作成状況が確認できます。
ルートテーブルは全部で３つ作成されたことも確認できます。
「VPCを表示」をクリックします。

作成したVPCの詳細画面が表示されます。
「リソースマップ」タブが選択された状態で「show all details」をONにするとリソースの関連付けが表示されました。
各リソースをクリックすると色枠が付いて関連付けがわかりやすくなっていました。
※以下は、パブリックサブネットに関連付けられているルートテーブルを選択した画面キャプチャです。

パブリックサブネット用のルートテーブルを見ると「 0.0.0.0/0 はインターネットゲートウェイへ」というルートも追加されていることが確認できます。

　　　

サブネットの名前変更

名前の変更は必須ではありませんが、自動作成されるリソース名は見にくいため変更します。

左ペインから「サブネット」をクリックします。
20250828-vpc-subnet-private1-ap-northeast-1a を一覧から探して、右側の編集アイコン（鉛筆）をクリック、編集して保存します。

■変更前

■変更後

　　　

パブリックサブネットへEC2インスタンスを作成

EC2 インスタンスを パブリックサブネット-1a 上に 1台作成します。

パブリックサブネットへEC2インスタンスを作成します。作成方法がわからない方は、以下記事を参考にしてください。

【AWS_07】仮想サーバー（インスタンス）の作成

※サーバ名は、web-sv01　にしました
※キーペアは、「キーペアなしで続行」を選択します
※VPC」は作成した VPC を選択します。
※サブネットは、パブリックサブネット-1a を選択します
※パブリック IP の自動割り当ては、有効化にします
※セキュリティグループ名は、web-sv01-sg　にしました
※セキュリティグループは、以下のとおり設定します。
　　・インバウンドルール
　　　タイプ：SSH ⇒ HTTP へ変更
　　　ソース：マイIP　※自身の個人端末からのみアクセスを受け付けます
　　・アウトバウンドルール：デフォルトのまま（すべてのトラフィックを許可）

インスタンスが作成されました。

ログインできることを確認しておきます。（当検証では、セッションマネージャーを利用して接続します）

　　　

EC2インスタンスにApacheをインストール

Apacheのインストール

EC2インスタンスをインスタンスにApacheをインストールします。作成方法がわからない方は、以下記事を参考にしてください。

【AWS_09】インスタンスにApacheをインストール

以下コマンドでネットワークの待ち受け状態を確認します。

sudo lsof -i -n -P

ブラウザから「 http://パブリック IPv4 アドレス 」へアクセスし、Apacheが正常に稼働していることを示す確認画面が表示されることを確認します。

参考：
EC2インスタンスのパブリック IPv4 アドレスは、以下手順で確認できます。
１．AWSマネジメントコンソールで「route53」を検索します。
２．左ペインのインスタンスをクリック、作成したインスタンスの左側にチェックを入れます。
３．画面下「詳細」タブを選択、パブリック IPv4 アドレスを確認します。

ブラウザからの確認をわかりやすくするため index.html を作成してみました。

　　　

Apache のサーバ名を設定

Apache の設定ファイルである httpd.conf ファイルのServerName ディレクティブを編集し、Apache サーバが自分自身のホスト名を示す時に使われる名前を指定します。

httpd.conf ファイルを以下のとおり書き換えた後、httpdサービスを再起動（systemctl restart httpd）します。
Apache サーバ自分自身のホスト名は、「www.ドメイン名」としました。

■httpd.conf 編集前

■httpd.conf 編集後

　　　

Application Load Balancer (ALB)の作成

 L7 ロードバランサーである ALB (Application Load Balancer)を作成し、作成済みの EC2 インスタンス（WEBサーバ１号機）をロードバランサー配下に登録します。

ターゲットグループの作成

最初にELB ターゲットグループ（ロードバランサーに登録する EC2 インスタンスグループ）を作成します。
ALBのリスナールールにて転送先として登録されたターゲットグループに、Webアクセス（HTTPリクエスト）が転送されます。
また、ターゲットグループは、AWSのロードバランサーにおいて、リクエストの振り分け先となるサーバー（EC2インスタンスなど）をまとめて管理する機能です。

AWSマネジメントコンソールで「ec2」を検索します。
左ペインから 「ターゲットグループ」 をクリックします。
「ターゲットグループの作成」をクリックします。

ターゲットタイプの選択 から 「インスタンス」 を選択します。
ターゲットグループ名 に任意の名前を入力します。今回は、「target-web-sv」としました。

プロトコルは「HTTP」、ポートは「80」にします。
IP アドレスタイプは 「IPv4」 を選択します。
VPC に 自分のVPC を選択します。 （例：hadson-user1）
プロトコルバージョンは、デフォルトのまま（HTTP1）にします。

ヘルスチェック、属性、タグは、デフォルトのままとし、「次へ」をクリックします。
※ヘルスチェックパスに「/」を指定した場合、ドキュメントルート「/」に対する定期的なHTTPリクエストが送信されるという意味になります。他のディレクトリを指定することも可能です。

ターゲットグループに登録する EC2 インスタンスを指定します。

作成済みの EC2 インスタンスをチェック （web-sv01 ）します。
「保留中として以下を含める」 をクリックします。

「保留中として以下を含める」 をクリックすると「ターゲットを確認」画面にEC2インスタンスの情報が反映されます。
「ターゲットグループの作成」をクリックします。

ターゲットグループが作成されていることを確認します。

　　　

ALB用セキュリティグループの作成

次に、ALB 用のセキュリティグループを作成します。
その後、EC2 インスタンス用のセキュリティグループを修正して、ALB から EC2 インスタンス（web-sv01）にアクセスできるようにします。

自分のグローバルIPからのみ HTTP を許可するALB用のセキュリティグループを作成します。

左ペインから 「セキュリティグループ」 をクリックし、「セキュリティグループを作成」をクリックします。

セキュリティグループ名、説明　共に 任意の名前を入力します。今回は「alb-sg」としました。
「VPC」で 今回作成したVPC を選択します。

インバウンドルール で 「ルールを追加」をクリックします。
「タイプ」を 「カスタム TCP」 から 「HTTP」 に変更します。
「ソース」を カスタム から マイIP に変更して、「ソース」に 自分のグローバルIPが表示されていることを確認します。
それ以外はデフォルトのままにして、「セキュリティグループを作成」をクリックします。

これで、ALB 用のセキュリティグループが作成されました。
ルールは、自端末のパブリック IP アドレスからの HTTP アクセスを許可する設定になっています。

　　　

EC2インスタンス用セキュリティグループの修正

次に、EC2インスタンス用のセキュリティグループ「web-sv-sg」を修正して、ALB から EC2 インスタンスへ接続できるようにします。
左側ペインから セキュリティグループ をクリックします。
表示されたセキュリティグループ「web-sv-sg」をクリックします。
画面中部あたりの 「インバウンドルール」タブ をクリックし、「インバウンドのルールを編集」 をクリックします。

「ルールの追加」 をクリックします。
「タイプ」を カスタム TCP から HTTP に変更します。
「ソース」を カスタム に変更します。
その横の検索ボックスから ALB 用セキュリティグループ 「alb-sg」を選択します。
「ルールを保存」 をクリックします。

※セキュリティグループをルールの送信元として指定すると、 その送信元セキュリティグループに関連付けられたリソース（今回の場合は、ALB）からのトラフィックが許可されます。

EC2インスタンス用のセキュリティグループ「web-sv-sg」へALB から EC2 インスタンスへ接続できるように設定が追加されました。

　　　

ALBの作成

ロードバランサー「ALB」を作成し、作成済みの EC2 インスタンス「web-sv01」をロードバランサー配下に登録します。

AWSマネジメントコンソールで「ec2」を検索します。
左ペインから 「ロードバランサー」をクリックします。
「ロードバランサーの作成」をクリックします。

ロードバランサータイプで「Application Load Balancer」の「作成」 をクリックします。

ロードバランサー名に任意の名前を入力します。今回は「20250828-alb」としました。
スキーム、ロードバランサーの IP アドレスタイプはデフォルト値のままにします。

ロードバランサーを、既に作成済みの 2つのパブリックサブネット(1aと1c) に配置します。
VPCに 作成済みの VPC を選択します。
IPプールは、デフォルトのまま（チェック無し）にします。
ap-northeast-1a のチェックを入れて パブリックサブネット-1a を選択します。
ap-northeast-1c のチェックを入れて パブリックサブネット-1c を選択します。

セキュリティグループ から 作成した ALB 用セキュリティグループ「alb-sg」を選択します。
default という名前のセキュリティグループが選択されている場合は、×印をクリックして選択を解除して、alb-sg のみが選択されているように変更します。

リスナー（ALBの待ち受けプロトコルとポート）とターゲットグループの設定を行います

プロトコル、ポートはデフォルトのままにします。
デフォルトアクション へ事前に作成したターゲットグループ「target-web-sv」を選択します。
リスナータグやロードバランサータグもデフォルトのまま(何も変更しない）にします。

サービスの統合で最適化は、デフォルトのまま（チェックはしない）にします。

設定の確認を行い、「ロードバランサーの作成」をクリックします。

ALB の DNS 名をコピーして、忘れないようにメモしておきます。
　
　　20250828-alb-440830165.ap-northeast-1.elb.amazonaws.com

ALB 配下に EC2 インスタンスが正常に登録されているか確認します。
「リスナーとルール」タブを選択します。
デフォルトアクションの「target-web-sv」をクリックして、ターゲットグループの詳細ページに遷移します。

ヘルスチェックに成功している、つまり、ロードバランサーを通じて EC2 インスタンスにアクセスできる状態になっていることを確認します。

「ターゲット」タブを選択します。
ヘルスステータスが 「healthy」 になっていることを確認します。
これで、作成した ALB が正常に機能していることが確認できました。

　　　

動作確認（ALBを介した通信）

ブラウザから ALB の DNS 名へアクセスしてWEBページが表示されるか確認します。

ブラウザから ALB の DNS 名へアクセスしてWEBページが表示されるか確認します。
　
　　http://20250828-alb-440830165.ap-northeast-1.elb.amazonaws.com

　　　

Amazon Machine Image (AMI) の作成

作成した EC2 インスタンスから Amazon Machine Image (AMI) を取得し、 EC2 インスタンスを複製する準備を行います。
今回は、作成済みのEC2インスタンス「web-sv01」 を元に AMI を作成します。
この AMI をもとに 2 つ目の EC2 インスタンス「web-sv02」を作成します。
EC2 インスタンス「web-sv02」作成後、index.htmlの中身を編集し、ブラウザからアクセスした時に1号機、2号機がわかるようにしておきます。

　　　

AMI（イメージ）の作成

AWSマネジメントコンソールで「ec2」を検索します。
左ペインから 「インスタンス」をクリックします。
「web-sv01」にチェックを入れます。
右上の アクション > イメージとテンプレート > イメージを作成 をクリックします。

イメージ名、イメージの説明に任意の名前を入力します。今回は「ami-web-sv」としました。
「インスタンスを再起動」のチェックは、そのままにします。
新規タグを追加をクリックして「キー」に Name、「値」にami-web-svと入力します。
その他の項目はデフォルトのまま イメージを作成をクリックします。

左ペインから AMI をクリックし、AMI 一覧を表示します。
作成した AMI 名「ami-web-sv」のステータス が 「保留中」 になっていること確認します。

AMI の作成が完了する（下図のように ステータスが 利用可能 になる) まで、数分待ちます。

　　　

2つ目の EC2 インスタンスの作成

さきほど作成した AMI を利用して、2 つ目の EC2 インスタンスを作成します。
EC2インスタンスの名前は「web-sv02」とします。

　　　

AMI から EC2 インスタンスを作成

AWSマネジメントコンソールで「ec2」を検索します。
左ペインから 「AMI」 をクリックします。
作成した AMI「ami-web-sv」 のチェックボックスにチェックをいれます。
「AMI からインスタンスを起動」をクリックします。

名前に「web-sv02」と入力します。

アプリケーションおよび OS イメージ (Amazon マシンイメージ)とインスタンスタイプは、どちらもデフォルトのままにします。
「カタログからの AMI」タブの「名前」に「ami-web-sv」が設定されていることを確認します。
インスタンスタイプは、「t2.micro」 が選択されていることを確認します。

キーペア名に「キーペアなしで続行」を選択します。　※セッションマネージャーでアクセスするため

2つ目の EC2 インスタンスは、パブリックサブネット-1c 上に作成するため、その設定を行っていきます。

「ネットワーク設定」の右にある 編集 をクリックします。
「VPC」で 今回作成したVPC を選択します。
「サブネット」で パブリックサブネット-1c を選択します。
「パブリック IP の自動割り当て」で 有効化 を選択します。
「ファイアーウォール(セキュリティグループ)」で 既存のセキュリティグループを選択する を選択します。
「共通のセキュリティグループ」から web-sv01-sg を選択します。

他の設定は、全てデフォルトのままにします。
「概要」から インスタンスを起動 をクリックして、インスタンスを起動します。

作成した EC2 インスタンスの詳細を確認していきます。すべてのインスタンスを表示をクリックし、作成したインスタンスの詳細を確認します。

インスタンス作成完了には数分かかります。
表示されない場合は、更新アイコンをクリックします。
「初期化しています」となっていたら、しばらく待ちます。

初期化が終わり、2つ目のEC2インスタンスの作成が完了しました。

ログインできることを確認しておきます。（当検証では、セッションマネージャーを利用して接続します）
ついでに index.html の内容も変更しておきます。

　　　

2つ目の EC 2インスタンスを ALB に登録

作成した 2 つ目の EC2 インスタンスを ALB に登録することでALB には 2つの EC2 インスタンスが登録されているため、Webレイヤー(EC2 インスタンス) は負荷分散かつ冗長構成になります。

　　　

ターゲットグループの選択

AWSマネジメントコンソールで「ec2」を検索します。
左ペインからターゲットグループを選択します。
作成したターゲットグループ「target-web-sv」をクリックして、ターゲットグループの詳細ページに遷移します。

「ターゲット」タブをクリックすると、1 つ目の EC2 インスタンス「web-sv01」が登録されていることが確認できます。
「ターゲットの登録」をクリックし、2 つ目の EC2 インスタンスを登録します。

作成した 2つ目の EC2 インスタンス「web-sv02」をチェックします。
「保留中として以下を含める」をクリックします。

ターゲットに 2 つ目の EC2 インスタンス「web-sv02」が表示されていることを確認します。
確認できたら、保留中のターゲットの登録をクリックします。

もし、「保留中のターゲットのみ登録しますか？」が表示された場合は、「次へ」をクリックします。

追加した EC2 インスタンスのヘルスステータスが initial から healthy に変わるまで待ちます。
healthy に変わると、2 つ目の EC2 インスタンスが ALB に正常に登録され、負荷分散かつ冗長構成になりました。

　　　

動作確認

ブラウザから ALB の DNS 名へアクセスしてWEBページを表示します。何度かページを更新して１号機、２号機と両方のページが表示され、負荷分散されていることを確認します。
　
　　http://20250828-alb-440830165.ap-northeast-1.elb.amazonaws.com

　　　

Route53へサブドメイン（www.ドメイン名）のAレコードを登録

Route53へサブドメインである「www.ドメイン名」のAレコードを登録し、「http://www.ドメイン名」でブラウザからアクセスできるか確認します。

　　　

Aレコードを登録

AWSマネジメントコンソールで「route53」を検索します。
左ペインのホストゾーンをクリック、画面中央のホストゾーン名をクリックします。

ホストゾーンの詳細画面にて、「レコード」タブ > 「レコードを作成」をクリックします。

レコードを作成画面で「レコード名」にサブドメイン名「www.ドメイン名」の「www」を入力します。
「レコードタイプ」は、Route53と同一AWSアカウント内のALBの場合はAレコードを選択します。「A -IPv4アドレスと一部のAWSリソースにトラフィックをルーティング」
「エイリアス」は、有効にします。
「トラフィックのルーティング先」は、「Application Load BalancerとClassic Load Balancerへのエイリアス」を選択します。
「リージョン」は、利用しているリージョンを選択します。
「ロードバランサーを選択」は、対象のALBを選択します。
「ルーティングポリシー」は、「シンプルルーティング」を選択します。
その他はデフォルトのままとし、「レコードを作成」をクリックします。

「www.ドメイン名」のAレコードが登録されました。

　　　

動作確認

インターネット経由で名前解決できるか確認します。
自端末（Windows）のコマンドプロンプトで nslookup を実行し、名前解決できました。
　　nslookup www.ドメイン名

次にブラウザからサブドメイン名「www.ドメイン名」でアクセスしてページが表示されることを確認できました。何度か更新すると１号機、２号機と負荷分散されていることも確認できます。
　　http://www.ドメイン名

　　　

AWS Certificate Manager (ACM)で証明書を作成

他機関で証明書を作成するパターンもあるようですが、今回はACMを利用します。
AWSの証明書（ACM）は無料のようです。はじめてなので参考サイトを参考に進めさせていただきます。

AWSマネジメントコンソールで「acm」を検索します。「Certificate Manager」をクリックします。
画面中央の「証明書をリクエスト」をクリックします。
※料金についてもこの画面で無料と触れられていました

「パブリック証明書をリクエスト」を選択し、「次へ」をクリックします。

「完全修飾ドメイン名」は、サブドメイン名のFQDNを入力します。
「エクスポートを許可」は、「エクスポートを無効にする」を選択します。
「検証方法」は、「DNS検証 – 推奨」をチェックします。
※Eメール認証のほうが汎用的のようですが、Route53を利用している場合は、Route53が推奨のようです
「キーアルゴリズム」は、「RSA 2048」を選択します。
その他は、デフォルトのままとし、「リクエスト」をクリックします。

以下画面が表示されます。
この画面は、左ペインの「証明書を一覧」からも確認することができます。
登録したサブドメイン（FQDN）の証明書の「ステータス」が「保留中の検証」と表示されていることが確認できます。

　　　

Route53でDNS認証向けのレコードを登録

検証した際、手動でCNAMEレコードを利用しているDNSサーバ（Route53）へ登録しましたが待てど暮らせどACMのステータスが「保留中の検証」から変更されませんでした。おそらく私がミスっているのですが・・・
そのためもっと楽で確実そうな手順で進めてみます。

※参考サイトに「DNSベンダの仕様による制約」という注意書きがありました。Route53を利用している場合は問題ありませんが、DNSベンダによっては仕様の制約によりこのCNAMEレコードを登録できない場合があるそうです。

私は、CNAMEレコードを作成する理由がわからなかったのでchatgptへ聞いてみました。すると以下のような回答があり、少し納得できました。
　
■DNS検証：
AWS ACMでは、証明書を発行するにあたって「本当にそのドメインの所有者か？」を確認する必要があります。これをドメイン検証と呼びます。
　
■CNAMEを使ったDNS検証の仕組み：
　　１．ACMがランダムなCNAMEレコードを提示
　　２．提示されたCNAMEレコードをDNS（Route53）に登録
　　３．ACMがインターネット越しにそのDNSレコードを見に行く
　　４．正しく登録されていれば、ACMにドメインの所有者であると判断される
　　５．証明書が「発行済み」となる

　　　

ACM画面からRoute53へCNAMEレコードを登録

ACMからRoute53へCNAMEレコードを自動作成することができます。
AWSマネジメントコンソールで「acm」を検索します。「Certificate Manager」をクリックします。
左ペインの「証明書を一覧」をクリックし、該当の証明書IDをクリックします。

画面中ほどの「Route 53でレコードを作成」をクリックします。

自動的にCNAMEレコードが作成されているので、チェックされていることを確認し、「レコードを作成」をクリックします。

以下の画面が表示されます。

　　　

Route53でCNAMEレコードの確認

AWSマネジメントコンソールで「route53」を検索します。
左ペインのホストゾーンをクリック、画面中央のホストゾーン名をクリックします。

ホストゾーンの詳細画面にて、「レコード」タブ を選択すると CNAME レコードが作成されていることが確認できました。

　　　

ACM画面から証明書のステータスを確認

ACMからRoute53へCNAMEレコードを自動作成後、しばらく待ちます。※私の場合、5分ほど待ちました
ACM画面に戻りステータスが「保留中の検証」から「発行済み」や「成功」へ変更されているか確認します。

AWSマネジメントコンソールで「acm」を検索します。「Certificate Manager」をクリックします。
左ペインの「証明書を一覧」をクリックし、該当の証明書IDをクリックします。

ステータスが「発行済み」や「成功」へ変更されていることが確認できました。

　　　

ALBにリスナーを追加、ACMの証明書を設定

この時点では、HTTPに関するルールしか設定してないので、HTTPSに関するルールとACMの証明書を登録していきます。

AWSマネジメントコンソールで「ec2」を検索します。
左ペインから 「ロードバランサー」をクリックし、該当のロードバランサーの名前をクリックします。

「リスナーとルール」タブを選択し、「リスナーの追加」をクリックします。

プロトコルは、「HTTPS」を選択します。ポートは自動で「443」が入ります。

デフォルトアクションは、以下のとおり設定します。
　　ユーザーを認証：チェックしない
　　アクションのルーティング：ターゲットグループへ転送
　　ターゲットグループ：該当のターゲットグループを選択
　　重み：1
　　ターゲットグループの維持をオンにする：チェックしない

セキュアリスナーの設定は、以下のとおり設定します。
　　セキュリティカテゴリ：「すべてのセキュリティポリシー」
　　ポリシー名：「ELBSecurityPolicy-TLS13-1-2-2021-06」
　　証明書の取得先：「ACMから」
　　証明書：事前に発行した証明書を選択
　　相互認証 (mTLS)：チェックしない

その他は、デフォルトのままとし、「リスナーの追加」をクリックします。

　　　

HTTPSに関するルールが追加されました。ですが「到達不可能」というアラートが表示されています。
「到達不可能」をクリックします。

ロードバランサーのセキュリティグループでHTTPSポート（443）が許可されていないのでリスナーポートに到達できないとメッセージが出ています。

　　　

ALB用セキュリティグループへHTTPSポート（443）を追加

既に適用しているALB用のセキュリティグループへ自分のグローバルIPからのみ HTTPS を許可するルールを追加します。

AWSマネジメントコンソールで「ec2」を検索します。
左ペインから 「セキュリティグループ」 をクリック、ALB用のセキュリティグループの名前をクリックします。
「インバウンドルール」タブを選択し、「インバウンドのルールを編集」をクリックします。

「インバウンドのルールを編集」画面で「ルールを追加」をクリックします。

「タイプ」を 「カスタム TCP」 から 「HTTPS」 に変更します。
「ソース」を カスタム から マイIP に変更して、「ソース」に 自分のグローバルIPが表示されていることを確認します。
右下の「ルールを保存」をクリックします。

これで自端末のパブリック IP アドレスからの HTTPS アクセスを許可する設定になりました。

　　　

ALBのリスナーとルールの画面の確認

ALBにおいてHTTPSに関するルールを追加した後、「到達不可能」というアラートが表示されていました。
ALBのセキュリティグループでHTTPSポート（443）が許可されていなかったためで今回追加したので再確認してみます。

AWSマネジメントコンソールで「ec2」を検索します。
左ペインから 「ロードバランサー」をクリックし、該当のロードバランサーの名前をクリックします。

「リスナーとルール」タブを選択します。
「到達不可能」の文字が消えていることが確認できました。

　　　

動作確認（HTTPS接続）

HTTPS接続の設定が完了したのでブラウザで動作確認します。
証明書が正しく動作して「https://www.ドメイン名」で表示されました！負荷分散もされています。
これで検証は完了となります。

　　　

検証後のリソースの削除

簡単にですが、作成したリソースの削除について記載します。
Route53のドメイン名は、しばらく利用するのでここでは削除しません。

・Route53
　　Aレコードの削除
　　CNAMEレコードの削除
　
・EC2インスタンス
　　削除
　
・Amazon マシンイメージ (AMI)
　　AMIの登録解除（関連づけられたスナップショットも削除）
　
・ALB
　　削除
　
・ターゲットグループ
　　削除
　
・VPC
　　削除
　
・ACM
　　証明書の削除
　

　　　

まとめ

Amazon Route 53 、Application Load Balancer (ALB)、AWS Certificate Manager (ACM) を連携し、HTTPS通信のWEBサーバを構築することができました。ACM証明書を発行するにあたり、CNAMEレコードを作成する意味がわかりませんでしたが検証することで理解が深まりました。参考にいただければ幸いです。

　　　

　以下、他の記事をまとめた一覧です。AWSもまとめています。

記事一覧