はじめに
概要
Route 53を使用した独自ドメインの管理、およびAWS Certificate Managerを使用したSSL証明書の発行方法について取り上げます。
前提条件
- AWSアカウント作成済み
- お名前.comアカウント作成済み
- 以下記事の環境構築済み
動作環境
- Windows 11 Home（24H2）
- Java 21
- Maven 3.9.9
- Spring Boot 3.4.5
本手順
前提条件に記載の記事の内容で環境が構築されていることを前提に進めます。
1. セキュリティグループの修正
ロードバランサー用セキュリティグループ（qiita-spring-ec2-sg-elb）について、以下のインバウンドルールを追加します。
- タイプ：HTTPS、ソース：0.0.0.0/0
2. ドメイン名の取得（お名前.com）
お名前.comの管理画面にログインし、ドメイン登録から「qiita-spring-ec2」と検索します。
今回は「.site」を選択します。
「すでにサーバーをお持ちの方はこちら」を選択します。
オプションなどは設定せず、「次へ」を選択します。
その後、支払い情報を入力して申し込みます。
以上で、「qiita-spring-ec2.site」というドメイン名の取得が完了しました。
3. ホストゾーンの作成（Route 53）
名前は取得したドメイン名と同一の「qiita-spring-ec2.site」とします。
外部に公開するドメイン名を扱うため、タイプは「パブリックホストゾーン」を選択します。
4. ネームサーバーの設定（お名前.com）
作成したホストゾーンを確認し、タイプがNSとなっているレコードの値に記載されている4つのネームサーバーをメモしておきます。
お名前.comから取得したドメイン情報を確認し、「ネームサーバーの変更」を選択します。
その他のネームサーバーから、メモしておいた4つのネームサーバーを入力して完了です。
何をしているのか❓
上記設定により、「qiita-spring-ec2.site」というドメイン名の名前解決に関する管理権限を、お名前.comのネームサーバーからAWSのネームサーバーに委譲しています。具体的には、.siteレジストリ（～.siteという名前を持つ各ドメイン名に関する情報を管理するネームサーバー）に登録されている情報を以下の通り変更しています。
変更前：
qiita-spring-ec2.siteの名前解決はdns1.onamae.comのサーバに聞いて
qiita-spring-ec2.siteの名前解決はdns2.onamae.comのサーバに聞いて
変更後：
qiita-spring-ec2.siteの名前解決はns-711.awsdns-24.net.のサーバに聞いて
qiita-spring-ec2.siteの名前解決はns-1056.awsdns-04.org.のサーバに聞いて
qiita-spring-ec2.siteの名前解決はns-1875.awsdns-42.co.uk.のサーバに聞いて
qiita-spring-ec2.siteの名前解決はns-153.awsdns-19.com.のサーバに聞いて
このように、AWSのネームサーバーが管理を担うようにすることで、AWSサービスとの統合（ACMとの連携やロードバランサーへのマッピングなど）が容易になります。
5. SSL証明書の発行（ACM）
ACMから、「パブリック証明書をリクエスト」とします。
ドメイン名は「qiita-spring-ec2.site」「*.qiita-spring-ec2.site」の2つを設定します。
今後、サブドメインを使用した拡張を考慮して、ワイルドカード証明書もリクエストしています。
検証方法は「DNS検証」とし、その他はデフォルトのままでリクエストとします。
このリクエストが承認されると、指定したドメインの信頼性が第三者（今回はAWS）によって担保されるので、HTTPSで通信できるようになります。
承認を受けるために、今回はリクエストの検証方法としてDNS検証を選択したので、発行した証明書から「Route 53でレコードを作成」を選択します。
ホストゾーンを確認すると、タイプがCNAMEのレコードが自動で作成されていることが分かります。
これによりDNS検証が行われ、証明書のステータスが「発行済み」に変われば完了です。（5分～10分ほどかかります）
6. ロードバランサーの修正（ELB）
1) リスナーの追加
はじめに、HTTPSでの通信を受け付けるようリスナーを追加します。
プロトコルは「HTTPS」、ポートは「443」、デフォルトアクションは「qiita-spring-ec2-tg」とします。
セキュアリスナーの設定から、証明書は「qiita-spring-ec2.site」を選択します。
その他はデフォルトの設定のまま、リスナーを追加とします。
2) 既存リスナーの修正
続いて、HTTPでのアクセスに対しては、HTTPSでリダイレクトするよう設定します。
既存のリスナー（HTTP:80）を選択し、デフォルトのリスナールールを編集します。
デフォルトアクションのルーティングを「URLにリダイレクト」に変更し、リダイレクト先のプロトコルは「HTTPS」、ポートは「443」とします。
以上で保存します。
7. DNSレコードの作成（Route 53）
最後に、取得したドメイン名とロードバランサーの紐づけを行います。
ホストゾーンからレコードを作成とし、レコード名は空白、レコードタイプは「Aレコード」、エイリアスをオンにし、トラフィックのルーティング先に「作成したロードバランサー」を設定します。
その他の設定はデフォルトのままでレコードを作成します。
これにより、AWSが管理する世界中のDNSサーバー（初めの4つのネームサーバーの実体）上に、「qiita-spring-ec2.siteというドメイン名が指すサーバはxx.xx.xx.xxというIPアドレス（ロードバランサーに割り当てられているパブリックIP）」という情報が拡散されます。
8. 動作確認
実際に、取得したドメイン名に対してHTTPSでアクセスしてみます。
https://qiita-spring-ec2.site
無事に動いています！
URL横の鍵マークから、SSL証明書が発行済みのサイトであることも確認できます。
また、HTTPでアクセスしても、正常にHTTPSによる通信にリダイレクトされることが分かります。
後片付け
本手順において、AWSサービスに対する必要以上の課金を防ぐ必要がある場合、最低限行う対応は以下の通りです。
- ロードバランサーの削除
- EC2インスタンスの停止
- SSL証明書の削除
- ホストゾーンの削除
おわりに
以上で、Route 53とACMを使用した、独自ドメインおよびHTTPS通信の実現が完了しました。
今回のようにドメイン取得を外部サービスで行う場合、まずはAWSに管理権限を移し、その後ACMとの連携やロードバランサーとの紐づけを行うことで、AWSサービス上で簡単に実現することができました。
最後に、他にも基礎的なAWSインフラ構築関連の記事を書いているので、よければご参照ください。