Issue when using "route53.HostedZone.fromHostedZoneId" Method

[Cloudrage]

Reproduction Steps

When trying to import an HostedZone with :
route53.HostedZone.fromHostedZoneId(this, 'MyHostedZone', 'ID123456789')

Error Log

I've that error when launching the Stack :
HostedZone.fromHostedZoneId doesn't support "zoneName"

Environment

• CLI Version : CDK 1.42.1 (build a4797b4)
• Framework Version: 6.14.5
• Node.js Version: v12.15.0
• OS : Linux
• Language (Version): TypeScript

Other

So, I've imported that way :
route53.HostedZone.fromHostedZoneAttributes(this, 'R53Domain', {hostedZoneId: 'MyID123456789', zoneName: 'Toto'})

What's wrong with fromHostedZoneId Method ?

---

This is 🐛 Bug Report

[shivlaks]

What you're currently doing is fine. I do believe we can better document this as it has come up before as a point of confusion for users.

fromHostedZoneId(...) and fromHostedZoneName(...) will create a mock object with just the ZoneId or the ZoneName field present. These are useful if you need to supply a HostedZone object but you know that the resource that is accepting the HostedZone only needs access to one of those variables. This is done without having make an API call so it can be done entirely locally.

fromHostedZoneAttributes will actually make a call to AWS to retrieve information and populate cdk.context.json.

It takes the attributes and performs an API call to determine which exact HostedZone is deployed and updates its behavior accordingly.

[Cloudrage]

Understood, thank you for the explanations !
Indeed, it can be detailed in the README and the error log maybe.

Definitely, I've gotten used to use fromXxXAttributes that gives better (real/exact) results.

About cdk.context.json, do you know any reasons why the file can't be populated anymore ?

[shivlaks]

About cdk.context.json, do you know any reasons why the file can't be populated anymore ?

can you expand on that? I need a little more information to dig into that. some questions that pop into my mind:

• was it being populated before but is not now?
• context lookups won't happen if the information it would look up already exists in cdk.context.json. are you observing behaviour different from that?

[Cloudrage]

Sorry, it's not our purpose but yes, it was polpulated before and not now.
I can say that the last time was the first time, when creating VPC resources ;D
I only have that on it :

{
  "@aws-cdk/core:enableStackNameDuplicates": "true",
  "aws-cdk:enableDiffNoFail": "true",
  "availability-zones:account=123456789:region=eu-west-1": [
    "eu-west-1a",
    "eu-west-1b",
    "eu-west-1c"
  ],
  "availability-zones:account=123456789:region=eu-west-1": [
    "eu-west-1a",
    "eu-west-1b",
    "eu-west-1c"
  ],
  "availability-zones:account=123456789:region=eu-west-1": [
    "eu-west-1a",
    "eu-west-1b",
    "eu-west-1c"
  ],
  "vpc-provider:account=123456789:filter.tag:Name=vpc-dev:region=eu-west-1:returnAsymmetricSubnets=true": {
    "vpcId": "vpc-123456789",
    "vpcCidrBlock": "1.2.3.4/23",
[...]

vpc-provider:account 3 times (for my 3 accounts); that's all.
Maybe I've to make a clear on it.

But, don't really nead that file, what is his main use ?

[shivlaks]

@Cloudrage sorry for the late reply i missed your question here. The primary purpose of the runtime context is to cache information from your AWS account (such as availability zones). This avoids unexpected changes to your deployments.

In your case, the context is populated so that the availability zones that are available and valid for the regions you are deploying are cached. If the cdk.context.json already exists, that lookup to populate the context will not be performed. We recommend that the project's context files be placed under version control along with the rest of your application for consistency when synthesizing and deploying templates.

you can learn more about runtime context here.

[shivlaks]

I'm resolving this issue as I don't believe further action is required.

Feel free to re-open / ask questions if anything has been left unanswered!

[Cloudrage]

Thanks @shivlaks for your time & explanations !

[kgunny]

What if you want to create an ARecord on an existing HostedZone on another account because its the DNS so the hosted zone is not created in any of your stacks?
from_hosted_zone_attributes Error is "Template error: Mapping named 'AWSCloudFrontPartitionHostedZoneIdMap' is not present in the 'Mappings' section of template."
This is required before I can create a custom domain for my Cognito User Pool, and although it can be done before hand, much neater to have the CDK create this ARecord for any changes to the sub domain name used for login.

[Cloudrage]

@kgunny , I've the same use case and I've to import the HostedZone from the other account :
fromHostedZoneAttributes with hostedZoneId & ZoneName props.

These one are stored in a JSON var file to be retrieved by the Stack with a tryGetContext.
These 2 values are imutable from an HostedZone.

It's not a perfect way, I don't like that too (globally because CDK can't rertieve natively resources between accounts); but it's the most simpliest way I've found.
See : aws/aws-cdk-rfcs#226

[kgunny]

Thanks @Cloudrage will experiment and see how I go.

[jgoux]

@kgunny Hello, I just hit your error :

Error [ValidationError]: Template error: Mapping named 'AWSCloudFrontPartitionHostedZoneIdMap' is not present in the 'Mappings' section of template.

I'm trying to create a record for a cloudfront distribution. Everything is in the same region except the certificate (it's required to be in us-east-1 by cloudfront).

Also I created the certificate and the hosted zone outside of CDK. I retrieve there infos using ssm.

Did you solve your issue? I tried to solve it the last 2 hours with nice people on cdk's Slack without finding a solution.

Here is my stacks involved and the error log : https://gist.github.com/jgoux/9f26a27137a511e278f8fe01e01f5e3f#file-cloudfront-ts

** EDIT ** :

Problem solved! 🎊
The issue was that I can't create a record alias for a Cloudfront distribution from another stack, they have to be in the same stack. The missing "Mappings" section was actually created in the CloudfrontStack template, so the Route53Stack template couldn't find it in its own template. ✅

[kgunny]

Sorry no we are still not able to use certificates across accounts/regions, even with latest CDK and bootstrapping. And the certificate still needs to be hosted in us-east-1.
So as a result certificate management, custom domains for API GW, and route 53 targets have to be set up manually.
Perhaps someone from AWS could shed some light on possible future plans to help resolve this issue so CDK can be used to roll out this very important component of our infrastructures.

[danny-xx]

@jgoux Hi, I'm facing the same issue as yours during CDK version migration (from 1.45.0 to 1.110.0)

Error [ValidationError]: Template error: Mapping named 'AWSCloudFrontPartitionHostedZoneIdMap' is not present in the 'Mappings' section of template.

I also resolved it by moving the alias record from route53 stack to cloudfront stack (thanks!)
However, it will cause some downtime for my web app because the A record is destroyed & re-created in another stack.
Do you happen to know any way around the downtime issue?
Thanks in advance!

[jgoux]

@danny-xx Why is your record destroyed and re-created? If it's the exact same I guess CDK should diff it. 🤔
In my case I have two stacks, a "stable" and a "dynamic" one. My stable contains everything that will never change between deployments (VPC, RDS, domain), and the dynamic one is for everything else that could change based on our application code (Fargate, Cloudfront, subdomain, lambdas...).

[danny-xx]

@jgoux Thanks for the quick reply!
In my case, I have the current Alias Record in Route53Stack and I'll have to move it to AssetsStack, where the CloudFront Distribution belongs to.
To move it across different stacks, the record would be destroyed in the current route53 stack and then created in the assets stack. It causes a downtime for around 10 minutes
The Alias Record also doesn't support TTL time, which would help me shorten/eliminate the downtime 😕

[justin-ad]

I'm resolving this issue as I don't believe further action is required.

Feel free to re-open / ask questions if anything has been left unanswered!

I've encountered this issue just now and I believe this should be reopened @shivlaks

Why would the following call (I'm using Python CDK v1.114.0):
route53.HostedZone.from_hosted_zone_id(self, "MyHostedZone", hosted_zone_id="MyHostedZoneId")

Result in:
Error: HostedZone.fromHostedZoneId doesn't support "zoneName"

This doesn't make sense... I didn't pass the function a zone name and in fact the function doesn't even accept a zone name... This is either poor API design, or a bug - calling this expected behavior seems like a stretch to me.

[NapalmCodes]

I agree this is an issue. If I pass the zoneId (which I did) I should not be getting an error for the name?

[ilons]

I agree with other here, this is a bug, either in the documentation or implementation..
Reading the documentation for from_hosted_zone_id it clearly states:

Use when hosted zone ID is known. Hosted zone name becomes unavailable through this query.

As such, I would expect it to work, instead of complaining about an argument which I did not pass, and which it does not accept.

[peterwoodworth]

You will get an error for zoneName when using fromHostedZoneId because you have tried to pass your imported hosted zone to somewhere which will try to reference your hosted zone's zoneName property. This will lead to error, because the hosted zone that has been created has no zoneName property. This is why this is considered expected behavior.

Seeing as this is causing lots of confusion, we can improve the error message.

I'm also working on improving the documentation related to how importing resources in CDK works in general, which should also help to reduce confusion surrounding these types of errors.

Sidenote - I've seen this in both related threads

fromHostedZoneAttributes will actually make a call to AWS to retrieve information and populate cdk.context.json

This is incorrect. only fromLookup will actually make a call to AWS to retrieve information.

[garyd203]

Thanks for taking some action on this @peterwoodworth , it's really appreciated. Are you also aware of the conversation on #3558 ? There's further discussion there from a number of community members around the expectation that fromHostedZoneId will do a genuine lookup (tl;dr: it's a valid use-case, and we shouldn't intentionally have a broken implementation of an interface)

[peterwoodworth]

The only methods we have which actually perform lookups to your AWS account are usually denoted with fromLookup() or something similar. All other import methods aren't meant to actually perform lookups.

This is one of the most frequent sources of confusion for CDK users - lots of users expect methods like fromHostedZoneId() to be actually fetching information from your AWS accounts when that's not their design or intent. Clearing this up, and when you would want to use one import method vs another is mostly what I was referring to by this:

I'm also working on improving the documentation related to how importing resources in CDK works in general, which should also help to reduce confusion surrounding these types of errors.

I agree that dynamically retrieving the zoneName of a HostedZone by just supplying the id should be natively supported - however that's just not supported now, nor do we claim to support it (though i understand this is unclear atm). I would suggest to open a new feature request which asks for a new method with this functionality (or modifying the existing fromLookup method) if this functionality is desired. Would probably need a new method which takes advantage of this api call

[ilons]

I agree that dynamically retrieving the zoneName of a HostedZone by just supplying the id should be natively supported - however that's just not supported now, nor do we claim to support it (though i understand this is unclear atm). I would suggest to open a new feature request which asks for a new method with this functionality (or modifying the existing fromLookup method) if this functionality is desired. Would probably need a new method which takes advantage of this api call

As a quite new user of CDK (that are not aware about its internals), it would make sense to me to have fromLookup actually retrieve the hosted zone by ID only, as that is a valid use-case.

After reading through this and related issues, I can finally understand the error I'm getting, but as has been pointed out, you should not have to google the error and read through a bunch of github threads in order to understand why you get a strange error.
So if the documentation and error message could be improved that would greatly help new users I think.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.