はじめに
ALBのDNS名（xxxx.ap-northeast-1.elb.amazonaws.com）のままでもアプリにはアクセスできますが、この状態では「独自ドメインで公開できない」「HTTPS化できない」といった問題があります。
実運用では、独自ドメインを設定し、ALBに紐付けることが前提になります。
本記事では、Route53を使って独自ドメイン「example.com」と
アプリ用サブドメイン「app.example.com」をALBに紐付ける手順を解説します。
本シリーズの構成
１. VPC編
２. Route53 独自ドメイン編（本記事）
３. ACM HTTPS化編
４. WAFセキュリティ編
５. ECS Auto Scaling編
６. CI/CD編
今回のゴール
今回のゴールは次の通りです。
- Route53のホストゾーンを利用する
- ALBへ向けるAレコード（Alias）を作成する
- 独自ドメインでNext.jsアプリにアクセスできるようにする
すでにドメインを取得済みという前提で進めます。
独自ドメインアクセスの仕組み
ユーザーが独自ドメインへアクセスすると
- DNS Resolver（DNSサーバー）がRoute53へ問い合わせ
- Route53がALBのDNS名を返す
- ユーザーがALBへアクセス
という流れになります。
DNS管理の方針
DNSはインフラの中核であり、アプリケーションより長いライフサイクルを持ちます。
そのため、CDKのスタック削除に伴って意図せず削除されることを防ぐため、アプリケーション用スタックとは分離して管理します。
前提条件
- ドメインを取得済みであること
もしドメインをRoute53以外（お名前.comなど）で取得している場合は、
ネームサーバーをRoute53へ変更する必要があります。
この手順は後ほど説明します。
2-1. ホストゾーンを作成する（事前準備）
Route53にホストゾーンを作成します。
ホストゾーン作成手順
AWSコンソール → Route53 → ホストゾーン
①ホストゾーンの作成を押下します。
②以下を入力し、作成処理を実行します。
- ドメイン名:
example.com
※example.comはサンプルです。実際には、ご自身で取得済みのドメイン名に置き換えてください。 - タイプ:
パブリックホストゾーン
実行すると、自動で2つのレコードが作られます。
example.com NS
example.com SOA
これらはDNSの基本レコードで、ホストゾーンの管理に必要なため自動で作成されます。
2-2. Route53でALBへ向ける仕組み
Route53のAliasレコードを使って、ALBに独自ドメインを設定します。
- Route53のホストゾーンを利用する
- AliasレコードでALBのDNS名を参照する
ALBは固定IPではなくDNS名で公開されるため、通常のAレコード（IP指定）は使用できません。
そのため、Route53ではAWSリソースを直接参照できるAliasレコードを使用します。
AliasレコードはRoute53独自の仕組みで、ALBなどのAWSリソースの状態に応じて動的に名前解決されます。
2-3. Route53の設定をCDKに追加する
ホストゾーンを作成したら、次にCDKからそのホストゾーンを参照し、
ALBへ向けるAliasレコードを作成します。
対象ファイル
今回のコードは、ALBを作成しているスタックに追記します。
前回シリーズの構成では、lib/alb-stack.tsが対象ファイルになります。
2-3-1. Route53関連のimportを追加する
まずは lib/alb-stack.ts に Route53 関連の import を追加します。
import * as route53 from 'aws-cdk-lib/aws-route53';
import * as targets from 'aws-cdk-lib/aws-route53-targets';
2-3-2. 既存ホストゾーンを参照する
AlbStackのコンストラクタ内に以下を追加します。
const hostedZone = route53.HostedZone.fromLookup(this, 'HostedZone', {
domainName: 'example.com',
});
これにより、「example.com」のホストゾーンをCDKから参照できるようになります。
2-3-3. ALBへ向けるAliasレコードを作成する
次に、独自ドメインをALBへ向けるAliasレコードを作成します。
AlbStackのコンストラクタ内に以下を追加します。
new route53.ARecord(this, 'AliasRecord', {
zone: hostedZone,
recordName: 'app',
target: route53.RecordTarget.fromAlias(
new targets.LoadBalancerTarget(alb)
),
});
ポイント
recordName: 'app' とすることで、app.example.com が作成されます。
これにより次のDNSルーティングが作成されます。
app.example.com → ALBのDNS名（xxxx.ap-northeast-1.elb.amazonaws.com）
ユーザーが「app.example.com」へアクセスすると、
Route53がALBのDNS名を返し、ユーザーはその情報をもとにALBへアクセスします。
ALBは固定IPを持たず、
xxxx.ap-northeast-1.elb.amazonaws.com
のようなDNS名のみで公開されています。
そのため、通常のAレコード（IP指定）では登録できません。
この問題を解決するために、Route53ではAliasレコードを使用します。
AliasレコードはALBなどのAWSリソースを直接指定でき、
内部的に適切なIPへ名前解決してくれるRoute53特有の仕組みです。
2-4. CDKをデプロイする
ここまでの設定をデプロイします。
本記事ではALBへのDNS設定のみを行うため、AlbStackのみをデプロイします。
※関連スタックはデプロイ済の想定です。
cdk deploy NextjsInfraAlbStack --profile <プロファイル名>
デプロイ後、Route53に次のレコードが作成されます。
app.example.com
A (Alias)
→ ALB
本記事で作成したスタックに含まれるAWSリソースは、削除するまで料金が発生します。
検証が不要になった場合は、以下のコマンドでスタックを削除してください。
cdk destroy <スタック名> --profile <プロファイル名>
2-5. ネームサーバーを変更する
この手順はドメインをRoute53以外で取得している場合のみ必要です。
ネームサーバーの変更を行わないと、Route53でレコードを作成しても反映されませんので注意してください。
| ドメイン取得場所 | 対応 |
|---|---|
| Route53 | ネームサーバー変更不要 |
| お名前.com / ムームードメイン など | ネームサーバー変更が必要 |
Route53でホストゾーンを作成しただけでは、まだドメインはRoute53を参照していません。
そのため、ドメイン取得サービス側でネームサーバーをRoute53へ変更する必要があります。
2-5-1. Route53のネームサーバーを確認する
１．AWSコンソール → Route53 を開く
２．左メニュー → 「ホストゾーン」をクリック
３．対象ドメイン（example.com）をクリック
４．「レコード」タブを開く
５．NSレコードを確認する
次のようなネームサーバーが表示されます。
ns-xxxx.awsdns-xx.com
ns-xxxx.awsdns-xx.net
ns-xxxx.awsdns-xx.org
ns-xxxx.awsdns-xx.co.uk
2-5-2. ドメイン取得元でネームサーバーを変更する
ドメイン管理画面から、ネームサーバーの設定を変更します。
設定項目の名称や画面構成はサービスによって異なりますが、
「ネームサーバー（NS）」の設定画面を開き、Route53のネームサーバーの値を設定します。
2-6. DNS反映を待つ
ネームサーバー変更後、DNSが反映されるまで少し時間がかかります。
一般的には数分〜数時間程度です。
DNSが正しく反映されているかを、次の手順で確認します。
まず、ドメインのネームサーバーがRoute53へ切り替わっているかを確認します。
nslookup -type=ns example.com
Route53のネームサーバーが表示されれば、
ドメインの参照先がRoute53へ正しく委任されています。
example.com nameserver = ns-xxxx.awsdns-xx.com
example.com nameserver = ns-xxxx.awsdns-xx.net
example.com nameserver = ns-xxxx.awsdns-xx.org
example.com nameserver = ns-xxxx.awsdns-xx.co.uk
次に、作成したサブドメインがALBに向けて正しく名前解決されているかを確認します。
nslookup app.example.com
以下のように名前解決の結果が返ってくれば、
「app.example.com → ALB」へのDNS設定（Aliasレコード）が正しく機能しています。
Name: app.example.com
Address: xxx.xxx.xxx.xxx
Address: xxx.xxx.xxx.xxx
※名前解決に失敗する場合やエラーとなる場合は、
ネームサーバーの設定やレコード設定が正しく反映されていない可能性があります。
2-7. 動作確認
ブラウザで次のURLへアクセスします。
http://app.example.com
HTTPS化は次回実施予定です。
この時点ではHTTPでの動作確認を行います。
Next.jsアプリが表示されれば、独自ドメインの設定は完了です。
ここまでの成果
今回の対応により、ALBのDNS名ではなく、独自ドメイン（app.example.com）でアプリを公開できるようになりました。
次回
次回は「ACM証明書を使ってALBをHTTPS化」します。
最終的に次のようなURLになります。
https://app.example.com
HTTPアクセスをHTTPSへリダイレクトする設定も行い、より実運用に近い構成へ修正していきます。