はじめに

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へリダイレクトする設定も行い、より実運用に近い構成へ修正していきます。