CDK Route 53 zone lookup brings back wrong zone ID

0

We are attempt to update our IaC code base to CDK v2. Prior to that we're deploy entire stacks of our system in another test environment. One part of a stack creates a TLS certificate for use with our load balancer.

var hostedZone = HostedZone.FromLookup(this, $"{config.ProductName}-dns-zone", new HostedZoneProviderProps
{
	DomainName = config.RootDomainName
});

DnsValidatedCertificate certificate = new DnsValidatedCertificate(this, $"{config.ProductName}-webELBCertificate-{config.Environment}", new DnsValidatedCertificateProps
{
	HostedZone = hostedZone,
	DomainName = config.AppDomainName,
	// Used to implement ValidationMethod = ValidationMethod.DNS
	Validation = CertificateValidation.FromDns(hostedZone)
});

For some reason, the synthesised template defines the hosted zone ID for that AWS::CloudFormation::CustomResource has something else other than the actual zone ID in that account. That causes the certificate request validation process to fail - thus the whole cdk deploy - since it cannot find the real zone to place the validation records in.

If looking at the individual pending certificate requests in Certificate Manager page, they can be approved by manually pressing the [[Create records in Route 53]] button, which finds the correct zone to do so.

Not sure where exactly CDK is finding this mysterious zone ID that does not belong to us?

    "AppwebELBCertificatetestCertificateRequestorResource68D095F7": {
      "Type": "AWS::CloudFormation::CustomResource",
      "Properties": {
        "ServiceToken": {
          "Fn::GetAtt": [
            "AppwebELBCertificatetestCertificateRequestorFunctionCFE32764",
            "Arn"
          ]
        },
        "DomainName": "root.domain",
        "HostedZoneId": "NON-EXISTENT ZONE ID"
      },
      "UpdateReplacePolicy": "Delete",
      "DeletionPolicy": "Delete",
      "Metadata": {
        "aws:cdk:path": "App-webELBStack-test/App-webELBCertificate-test/CertificateRequestorResource/Default"
      }
    }
1개 답변
0
수락된 답변

So apparently CDK has a file cdk.context.json that cached the (non-existent) zone ID of the old zone of the same name that was deleted a long time ago. Deleting the file allowed CDK to refresh to the new zone ID.

icelava
답변함 2년 전

로그인하지 않았습니다. 로그인해야 답변을 게시할 수 있습니다.

좋은 답변은 질문에 명확하게 답하고 건설적인 피드백을 제공하며 질문자의 전문적인 성장을 장려합니다.

질문 답변하기에 대한 가이드라인

관련 콘텐츠