CDK部署卡在CertificateManager步骤的解决方法咨询

核心原因 #

你遇到的问题确实是因为新生成的Route53托管区NS记录未同步到域名服务商，导致ACM无法通过DNS验证域名所有权，部署因此卡住。

最优解决方案 #

复用已配置好NS记录的Route53托管区是最可靠的方案，避免频繁修改域名服务商NS记录带来的延迟和风险，具体步骤如下：

1. 终止当前卡住的部署
   在终端执行cdk destroy，或者直接在AWS CloudFormation控制台删除卡住的堆栈，避免资源长期处于创建中状态。

2. 创建并配置稳定的Route53托管区

   • 要么在AWS控制台手动创建test.com的Route53托管区，要么用CDK创建一次后保留（不要随堆栈销毁）。
   • 复制该托管区的4条NS记录，登录你的域名服务商后台，将域名的NS记录全部替换为这4条，等待DNS生效（根据服务商TTL，可能需要1-24小时）。
   • 用nslookup -type=NS test.com验证NS记录是否生效，输出应和Route53托管区的NS一致。

3. 修改CDK代码引用现有托管区
   不再创建新的托管区，而是引用已配置好的托管区，代码示例：

   const domainName = 'test.com';
   
   // 方式1：通过域名查找托管区（需要CDK环境有足够权限读取Route53）
   const zone = cdk.aws_route53.HostedZone.fromLookup(this, 'ExistingTestApiHostedZone', {
     domainName: domainName,
   });
   
   // 方式2：直接通过托管区ID引用（更可靠，避免查找失败）
   // const zone = cdk.aws_route53.HostedZone.fromHostedZoneId(this, 'ExistingTestApiHostedZone', 'ZXXXXXXXXXXXXXX');
   
   // 定义ACM证书，复用已生效的托管区做DNS验证
   const certificate = new cdk.aws_certificatemanager.Certificate(this, 'TestApiCertificate', {
     domainName: domainName,
     validation: cdk.aws_certificatemanager.CertificateValidation.fromDns(zone),
   });
   

4. 重新部署CDK堆栈
   NS记录生效后，ACM会自动添加验证所需的CNAME记录到Route53，验证过程通常在5-15分钟内完成，部署不会再卡住。

对比你提到的两个选项 #

• 修改NS为CDK新生成的托管区记录：可行但不推荐，因为每次重建堆栈都会生成新的托管区，需要重复修改NS记录，等待DNS生效，效率低且容易出错。
• 手动创建托管区后用fromLookup引用：这就是上面推荐的最优方案，托管区长期稳定存在，后续所有CDK部署都复用它，彻底解决NS同步问题。

内容的提问来源于stack exchange，提问作者Aviv Dolev