AWS Amplify カスタムドメイン設定で「別の CloudFront を向いてる」エラーにハマった話

TL;DR

Amplify のカスタムドメイン設定で One or more aliases specified for the distribution includes an incorrectly configured DNS record that points to another CloudFront distribution エラーが出続けたら、以下の両方を試す：

1. サブドメインではなく、直接ドメインとして追加する
   • ❌ epicquest.ninja を追加 → サブドメイン sample を指定
   • ✅ sample.epicquest.ninja を直接ドメインとして追加
2. 証明書は Amplify に自動作成させる
   • ❌ 自前の ACM 証明書を指定
   • ✅ Amplify に証明書作成を任せる

両方の条件が揃わないとダメだった。

何が起きたか

やりたかったこと

sample.epicquest.ninja を Amplify でホストしてるアプリに HTTPS で公開したい。

最初にやったこと

1. Amplify コンソールでカスタムドメインを追加
2. epicquest.ninja をドメインとして入力
3. サブドメイン sample を指定
4. 自前で作成済みの ACM 証明書を指定

発生したエラー

One or more aliases specified for the distribution includes an incorrectly configured DNS record that points to another CloudFront distribution.

試したこと（全部ダメ）

原因の推測

CloudFront の alias 検証の仕組み

CloudFront が alias（カスタムドメイン）を設定するとき、以下のチェックが走る：

1. 同じ CNAME alias は複数の distribution で使えない
2. alias を追加するには有効な TLS 証明書が必要（ドメイン所有権の証明として）
3. 自分以外の *.cloudfront.net を向いてたら拒否

You can’t use the same CNAME alias for more than one CloudFront distribution. — AWS re:Post – Resolve the “CNAMEAlreadyExists” error

To add an alternate domain name (CNAME) to a CloudFront distribution, you must attach to your distribution a trusted, valid TLS certificate that covers the alternate domain name. This ensures that only people with access to your domain’s certificate can associate with CloudFront a CNAME related to your domain. — AWS CloudFront Developer Guide – CNAMEs

また、2019年以降、CloudFront は証明書なしでの CNAME 追加を許可しなくなった：

Starting today, when you add an alternate domain name by using the AWS Management Console or the CloudFront API, you must also attach a SSL/TLS certificate to that specific distribution in order to validate that you have authorized rights to use that alternate domain name. — AWS Blog – Continually Enhancing Domain Security on Amazon CloudFront

Amplify 内部で何が起きてたか（推測）

Amplify のカスタムドメイン設定は内部で以下を行う：

1. CloudFront distribution を作成
2. ACM 証明書を紐付け
3. alias を設定
4. ユーザーに DNS 設定を指示

問題は、alias 設定が完了する前に DNS 設定を指示してくること。

つまり：

1. Amplify が distribution 作成
2. Amplify が「DNS に dxxxx.cloudfront.net を設定して」と指示
3. ユーザーが DNS 設定
4. Amplify が alias を設定しようとする
5. CloudFront「この CNAME は *.cloudfront.net を向いてるけど、この distribution には alias がまだ設定されてないから別物扱い」→ 拒否

「再試行」ボタンの罠

「再試行」を押すと Amplify は新しい distribution を作り直す。

1. Distribution A 作成 → alias 設定失敗
2. ユーザーが DNS を A に向ける
3. 「再試行」押す
4. Distribution B 作成 → 「DNS が A を向いてる」→ 失敗
5. ユーザーが DNS を B に向ける
6. 「再試行」押す
7. Distribution C 作成 → …

永遠に追いつかない。

Amplify が作る CloudFront は内部管理

重要な点として、Amplify が作成する CloudFront distribution は AWS 内部アカウントで管理される：

When you set up a custom domain for Amplify, it creates an internal CloudFront distribution, in an internal AWS account. This distribution will be owned by the Amplify team, hence the reason you are unable to see the distribution in your account. — AWS re:Post

これにより、aws cloudfront list-distributions コマンドでは Amplify の distribution を確認できない。トラブルシューティングが難しくなる原因の一つ。

自前証明書を使うと何が起きるか（推測）

自前の ACM 証明書を指定した場合、Amplify 内部で以下の問題が起きてる可能性：

1. Amplify が distribution を作成
2. 自前証明書を紐付けようとする
3. 証明書と distribution の紐付けで何らかの競合が発生
4. alias 設定まで到達しない
5. エラーメッセージは「alias 競合」だが、実際の原因は証明書周り

証明書を Amplify 自動作成にすると、全てが Amplify 管理下になるため、この競合が発生しない。

サブドメインとして追加 vs 直接ドメインとして追加

Amplify の内部処理が異なる可能性：

サブドメインとして追加（epicquest.ninja → sample）:

• 親ドメイン全体の何らかの検証が走る？
• 既存の CloudFront 設定との競合チェックが厳しい？

直接ドメインとして追加（sample.epicquest.ninja）:

• そのドメインだけを対象にシンプルな処理
• 余計な検証がスキップされる？

解決した設定

この組み合わせで、DNS 設定後すぐに SSL 設定が完了した。

まとめ

Amplify カスタムドメイン設定のベストプラクティス

1. サブドメインは「直接ドメインとして追加」する
   • example.com を追加して app サブドメインを指定、ではなく
   • app.example.com を直接入力
2. 証明書は Amplify に任せる
   • 自前の ACM 証明書があっても使わない
   • Amplify に自動作成させる
3. 「再試行」ボタンは押さない
   • 押すたびに新しい distribution が作られて状況が悪化する
   • ダメなら設定を削除して最初からやり直す
4. DNS 設定は Amplify の指示を待ってから
   • Amplify が「DNS 設定してください」と言うまで設定しない
   • 先に設定すると競合エラーになる

エラーメッセージの罠

One or more aliases specified for the distribution includes an incorrectly configured DNS record that points to another CloudFront distribution

このエラーメッセージは嘘をついてる（可能性がある）。実際の原因は：

• 証明書の紐付け失敗
• Amplify 内部の distribution 作り直し
• alias 設定のタイミング問題

など、「別の CloudFront を向いてる」以外の可能性がある。

検証に使ったコマンド

# DNS 確認
dig sample.epicquest.ninja CNAME +short

# CloudFront distribution 確認（Amplify 管理のものは出てこない）
aws cloudfront list-distributions --query "DistributionList.Items[?contains(Aliases.Items, 'sample.epicquest.ninja')].{Id:Id,DomainName:DomainName}" --output table

# ACM 証明書確認
aws acm list-certificates --region us-east-1 --query "CertificateSummaryList[?contains(DomainName, 'epicquest.ninja')]" --output table

# 特定の distribution 確認
aws cloudfront get-distribution --id XXXXXX

環境

• AWS Amplify Gen 2
• Route 53（ドメインは別の AWS アカウントで管理）
• ACM 証明書（us-east-1）

※ ドメインが別アカウント管理でも、パブリック DNS 解決は通常通り行われるため、Amplify 側の挙動に影響はないはず。今回の問題はアカウント分離とは無関係だった。