取得してからかれこれ10年以上使ってるドメイン、個人ブログがあります。

ドメインはお名前.com で取得してお名前.com で管理しています
WordPress を使用したサイトです
Lightsail 1インスタンス内に LNMP を構築して運用しています
記憶が正しければこれまでにさくらVPS → ConoHa VPS → EC2 → Lightsail IPv4&v6 → Lightsail IPv6 Only と移行してきています
インスタンス内に certbot（Let's Encrypt）を導入し、2～3か月おきくらいでワイルドカード証明書の更新（DNS-01 チャレンジ）を行っています
ブログ以外にも勉強用のシェルスクリプトだとか、いくつか静的ページが残っています
円安や IPv4 の利用に追加料金が必要となった件の影響もあって Lightsail が割高に感じるようになった
古い頃の情報がちょっと恥ずかしい（~~黒歴史~~）。かといって更新する気も起きない

といったことがあり閉鎖しようと考えるようになりました。

ただし、ドメイン自体は今後も継続利用したいと考えています。

サーバーレスアプリケーションの前段として存在する CloudFront ディストリビューションの中で代替ドメインとして使用している
10年超も使ってるとさすがに愛着がわく

ここで問題となるのが CloudFront で利用するSSL証明書を発行する場が無くなる点です。
現状は Lightsail の中で certbot を使用して発行したSSL証明書を ACM に手動インポートすることで CloudFront のカスタムSSL証明書設定を行っていたのですが、閉鎖した時点で SSL 証明書を発行する場がなくなってしまいます。。

ということでまずお名前.com で管理してるDNSレコード設定について Route 53 で管理できるようにし、ACMサービス上でACM証明書を発行できるようにするところから作業を始めることにしました

今回の作業においてドメインの「移管」は行いません

以下はこの終活に関する一連の作業予定です

1. 切替先となる Route 53 のホストゾーン作成
2. 既存の DNS レコード設定情報を参考に Route 53 のレコード設定
3. ネームサーバーを お名前.com → Route 53 に切り替え
4. ACM 証明書を発行
5. 既存のサーバーレスアプリケーションに設定中のACM証明書の切替
6. 不要となった方のACM証明書を削除
7. Lightsail内で稼働中のWordPressサイト、その他をバックアップ
8. WordPressサイトについてローカルでの動作環境を構築
9. Lightsailインスタンスを削除
10. Route 53 レコード設定から Lightsail インスタンスのIPv6に向けた設定を削除

この記事の中では 1 ～ 4 の手順を記載しています

1. 切替先となる Route 53 のホストゾーン作成

Route 53 について私の個人アカウントでは一切使用してないので以下のような画面が表示されました。

今回はお名前.comで管理してるDNSレコードを Route 53 で管理したいので「ホストゾーンを作成」を実行する必要があります。
最近は AWS リソースの操作について CloudShell を介した aws-cli での作業を行うようにしているため以下のドキュメントおよび参考サイトを参照して作成しました。

CloudShell で Route 53 ホストゾーン作成

$ aws route53 create-hosted-zone \
  --name imo-tikuwa.com \
  --caller-reference "$(TZ=Asia/Tokyo date +%Y%m%d_%H%M%S)"

CloudShell で作成した Route 53 ホストゾーンを確認

$ aws route53 list-hosted-zones
{
    "HostedZones": [
        {
            "Id": "/hostedzone/Z***************KXJ2S",
            "Name": "imo-tikuwa.com.",
            "CallerReference": "202504**_******",
            "Config": {
                "PrivateZone": false
            },
            "ResourceRecordSetCount": 2
        }
    ]
}

2. 既存の DNS レコード設定情報を参考に Route 53 のレコード設定

移行元のお名前.comのDNSレコード設定画面で「エクスポート」を押下、ゾーンファイル（BIND形式）をダウンロード

AWSのマネジメントコンソール上で「ゾーンファイルをインポート」を押下

テキストエリアの入力欄にダウンロードしたゾーンファイルのテキストをすべてペーストすると登録されるレコードのプレビューが下の方に表示されました

ゾーンファイルに含まれるNSやSOAレコードは良い感じに無視してくれるのでペーストするゾーンファイルは丸ごとでいいみたい（便利）

プレビュー下部の「インポート」を押下でゾーンファイルのうち現在も有効化中のレコードが Route 53 レコードとして登録できました

備考
最初は aws-cli の route53 change-resource-record-sets コマンドを使用する手順を予定していました。
こちら実際に作業中、お名前.com と Route 53 のそれぞれでゾーンファイルのダウンロード→インポートと進めると互換性があってスムーズなことに気づきました...

ということで古い手順を供養

ChatGPT を活用した手順について

route53 change-resource-record-sets コマンドに渡す入力ファイル（JSON）について手作業で作るのは手間なので ChatGPT で以下のような指示を行うことで作成します。

ChatGPT への指示内容

お名前.com で管理してるDNSレコードについて Route 53 への移行を行いたいです。
ホストゾーンの作成は終わってます。
お名前.com のDNSレコード設定画面でダウンロードしたDNSレコード設定情報を共有するので aws-cli の route53 change-resource-record-sets コマンドの change-batch オプションに渡す json ファイルを作成してください。
なお、SOA や NS などのレコードはお名前.com → Route 53 の移行において不要なので作成する json ファイルの中には含めないでください。

~~~ お名前.comでダウンロードしたゾーンファイルのテキストをペースト ~~~

以下のような出力を得られました

形式は合ってそう
ただし、DNSレコードの変更は重要な作業なので元のゾーンファイルの記述と照らし合わせての確認を端折ることはできません...

3. ネームサーバーをお名前.com → Route 53 に切り替え

まず、作成したホストゾーンに含まれるNSレコードを確認、控えておく

お名前.com → Route 53 に向けるための設定（ネームサーバーの切替）を実施、1つ前の手順で控えておいた Route 53 のNSレコード情報を入力

内容を確認してOKを押下（2025/04/21/ 14:10くらい？）

切り替わるまで待機。
反映完了について24時間～72時間掛かるとありますが、今回は10分後の 2025/04/21/ 14:21 頃に切り替わってることを確認できました。
ローカルからの確認と以下のサービスを活用して確認しました。

ローカルから確認

>powershell -Command "Resolve-DnsName imo-tikuwa.com -Type NS"

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
imo-tikuwa.com                 NS     17280 Answer     ns-1040.awsdns********
                                      0
imo-tikuwa.com                 NS     17280 Answer     ns-1761.awsdns********
                                      0
imo-tikuwa.com                 NS     17280 Answer     ns-372.awsdns********
                                      0
imo-tikuwa.com                 NS     17280 Answer     ns-904.awsdns********
                                      0
~~~ 省略 ~~~

反映を確認後、念のため WordPress ブログにアクセスできることを確認

4. ACM 証明書を発行

CloudFront はグローバルなサービスなので、ディストリビューションに設定するACM証明書はバージニア北部リージョン（us-east-1）で作る必要があります。

作業前に certbot で作成して手作業でインポートしている既存の ACM 証明書の存在を確認しました。

タイプ列が「インポート済み」となっているものはACMのサービス上で発行したものではなく、手動インポートしたもの

certbot によって発行してる証明書は冒頭に書いたように DNS-01 チャレンジを行ったワイルドカード証明書になります。
念のため既存の証明書についてサブジェクトの代替名（SAN）などの設定値をブラウザ上で確認。

証明書のリクエストは CloudShell を介した aws-cli によって実施します。
コマンドを実行することで CertificateArn というレスポンスを取得できました。

CloudShell で ACM 証明書のリクエストを実施

$ aws acm request-certificate \
  --domain-name "*.imo-tikuwa.com" \
  --validation-method DNS \
  --subject-alternative-names "imo-tikuwa.com" \
  --region us-east-1
{
    "CertificateArn": "arn:aws:acm:us-east-1:************:certificate/********-****-****-****-************"
}

マネジメントコンソール上で作成できてることを確認

証明書の検証手順について作成時のコマンドの validation-method オプションで DNS レコードでの検証を行うように設定しました。そこでまずは検証待ちの証明書に記載の CNAME 情報を確認します

備考
この操作はマネジメントコンソール上の証明書の詳細画面で「Route 53 でレコードを作成」を押下することでGUI上から簡単に作成できます。

今回は勉強目的であえて aws-cli を使って実施します。

証明書リクエストを行ったときのレスポンスに含まれる CertificateArn を元に ACM 証明書の詳細情報を取得します。
この際、jq コマンドと組み合わせることで後述する route53 change-resource-record-sets コマンドの change-batch オプションで渡すフォーマットに沿った json ファイルを作成します。

CloudShell でリクエストしたACM証明書の情報を取得

$ aws acm describe-certificate \
  --certificate-arn "arn:aws:acm:us-east-1:************:certificate/********-****-****-****-************" \
  | jq '{
    Changes: [
      .Certificate.DomainValidationOptions[] 
      | {
          Action: "UPSERT",
          ResourceRecordSet: {
            Name: .ResourceRecord.Name,
            Type: .ResourceRecord.Type,
            TTL: 300,
            ResourceRecords: [
              {
                Value: .ResourceRecord.Value
              }
            ]
          }
        }
    ]
  }' > acm-dns-validation.json

作成した acm-dns-validation.json の中身を確認

この章の以降の手順について、間違ってる点があるので注意
後で気づいて修正したのですが間違った内容もあえて載せています。

公開しない方が良い情報は適当にマスクしています（111,222,333の部分）。

CloudShell 上で json ファイルの中身を確認

＄ cat acm-dns-validation.json
{
  "Changes": [
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "_11111111111111111111111111111111.imo-tikuwa.com.",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [
          {
            "Value": "_22222222222222222222222222222222.3333333333.acm-validations.aws."
          }
        ]
      }
    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "_11111111111111111111111111111111.imo-tikuwa.com.",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [
          {
            "Value": "_22222222222222222222222222222222.3333333333.acm-validations.aws."
          }
        ]
      }
    }
  ]
}

imo-tikuwa.com、*.imo-tikuwa.com の2レコード分できあがったみたい

route53 change-resource-record-sets コマンドで acm-dns-validation.json を入力とする Route 53 レコード設定を実施します。
hosted-zone-id オプションにはホストゾーンを aws-cli 経由で作成したときにレスポンスとして返ってきたものをセットします。

CloudShell で Route 53 レコード設定（失敗）

$ aws route53 change-resource-record-sets \
  --hosted-zone-id "/hostedzone/Z***************KXJ2S" \
  --change-batch file://acm-dns-validation.json

An error occurred (InvalidChangeBatch) when calling the ChangeResourceRecordSets operation: [The request contains an invalid set of changes for a resource record set 'CNAME _11111111111111111111111111111111.imo-tikuwa.com.']

エラーになってしまいました。。
ワイルドカード証明書としての * サブドメイン と ルートドメイン の名称、値が同一なのでレコード設定として登録すべき内容は1つで良いのかも？

ということで以下のように書き換えました。

acm-dns-validation.json （DNSレコードとしての重複について削除）

{
  "Changes": [
-    {
-      "Action": "UPSERT",
-      "ResourceRecordSet": {
-        "Name": "_11111111111111111111111111111111.imo-tikuwa.com.",
-        "Type": "CNAME",
-        "TTL": 300,
-        "ResourceRecords": [
-          {
-            "Value": "_22222222222222222222222222222222.3333333333.acm-validations.aws."
-          }
-        ]
-      }
-    },
    {
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "_11111111111111111111111111111111.imo-tikuwa.com.",
        "Type": "CNAME",
        "TTL": 300,
        "ResourceRecords": [
          {
            "Value": "_22222222222222222222222222222222.3333333333.acm-validations.aws."
          }
        ]
      }
    }
  ]
}

改めて route53 change-resource-record-sets コマンドを実行したところ今度は正常に実行できたと思われるレスポンスを得られました
2025/04/21 16:11:47 頃実施

CloudShell で Route 53 レコード設定（成功）

$ aws route53 change-resource-record-sets \
  --hosted-zone-id "/hostedzone/Z***************KXJ2S" \
  --change-batch file://acm-dns-validation.json

{
    "ChangeInfo": {
        "Id": "/change/C***************RP19",
        "Status": "PENDING",
        "SubmittedAt": "2025-04-21T07:11:47.674000+00:00"
    }
}

念のためマネジメントコンソール上でも Route 53 レコードを確認。コマンド操作によって Route 53 レコードの追加ができていることが確認できました。

少し待った後、ACM 証明書の DNS レコードを使用した検証結果について失敗になってしまっていることに気づきました...

↓

Certificate Authority Authentication (CAA) エラーにより、1 つ以上のドメイン名が検証に失敗しました。

とのこと。
上のエラーメッセージを元に調べたところ以下のページが見つかりました。

お名前.com → Route 53 に DNS レコードを移す作業を行った際、既存のものとして certbot 用の CAA レコードが設定されていたことが原因でこけてしまったみたいです。。
既存の letsencrypt.org の設定値を参考に amazon.com の設定を追記（この作業はマネジメントコンソール上で実施してしまいました。。）。

ドキュメントの記述的にDNS検証に失敗したACM証明書について自動的に再検証のようなことはできなさそうです。。

ということで失敗した証明書を削除し、改めて証明書のリクエストを行いました。
以下の手順で検証に失敗したACM証明書を削除します。

CloudShell でDNS検証に失敗したACM証明書を削除

$ aws acm delete-certificate \
  --certificate-arn "arn:aws:acm:us-east-1:************:certificate/********-****-****-****-************"

あらためて証明書のリクエスト → 証明書情報から json 組み立て → route53 レコード設定を行ったところ今度は検証に合格できました。。（手順は省略）

証明書一覧画面も確認

とりあえずACM証明書の発行までは行えたので今回はここまで。

参考サイト

今回使用した aws-cli に関するドキュメントは以下

その他、以下の記事も参考にさせていただきました