[Route53] cdk-route53 Cross account records.

[mrpackethead]

Extend Cross Acount Records to be more than Just Zone Delegations. It would be great if out of the box, we could do any kind of record in a zone that was not in the account that the stack is in.

Use Case

many times, we want to be able to add records for external things... eg

customerportal.domain.com www.domain.com

Proposed Solution

Other

• [ ] :wave: I may be able to implement this feature request
• [ ] :warning: This feature might incur a breaking change

---

This is a :rocket: Feature Request

[njlynch]

Thanks for the feature request!

Creating general-purpose cross-account constructs is typically a good bit more work than a specific use case. However, in this case, we're talking about effectively proxying Route53's ChangeResourceRecordSets API. That's plausible, certainly.

I am marking this issue as p2, which means that we are unable to work on this immediately.

We use +1s to help prioritize our work, and are happy to revaluate this issue based on community feedback. You can reach out to the cdk.dev community on Slack to solicit support for reprioritization.

[jnawk]

+1

[pcolmer]

This also potentially affects ACM when using DNS validation. ACM can now create DNS validation records for you automatically - but that only works if the DNS zone is under the same account as ACM.

We're currently working on Custom Resources to creating cross-account Route53 records and, from that, extending ACM to work cross-account.

But it would be oh so much better if supported directly by AWS.

[jamiepeloquin]

+1

[jweilhammer]

+1 on this

Noting that cross account validation of ACM certifications works easily with a CNAME record

Was also able to get a cross account A record to an ALB using the IP address instead of the DNS name, but using the IP address is unreliable as it can change. Creating manually for now then

[IainCole]

The DnsValidatedCertificate CustomResource is separate to whatever the cross account record resource would be. I've built a cross account record resource and my own version of DnsValidatedCertificate that accepts a role to assume when creating the DNS records, I'm happy to contribute this back if we think it's worth having.

[carolkelly25]

+1

We need to be able to create route 53 alias records cross account and a bit disappointed that having done everything else in cdk that we can't do this, and the it's documentation to find in the documentation that this isn't supported. Seems like a very standard setup that people have with regard to route 53 in a separate account so a very reasonable request to get wider aws-cdk adoption.

[scottbisker]

+1

[johnf]

I've created a construct library to help solve this issue. I'd love any feedback https://github.com/johnf/cdk-cross-account-route53

[liamor]

+1

[mfittko]

+1

[fjelliott]

+1

Mainly interested in the ability to validate ACM certificates cross-account.

[brcourt]

+1

[angeldima]

+1

[gperego-pirelli]

+1

[EdwardEdy]

+1

[KurtMar]

@johnf I found that you had done excellent work to implement this for ACM DNS validation, but that the construct was deprecated and the merge request closed (https://github.com/aws/aws-cdk/pull/23526#issuecomment-1423784041). :(

Do you have any plans to recreate your work in the newer CertificateValidation construct?

This is a sorely missed feature when working with top level domains in a separate AWS account and I am assuming that there is no real workaround for this.

[dguisinger]

+1 Similarly, I would like to create NS records pointing to subdomains which are hosted in separate accounts automatically from CDK

[brcourt]

+1 Also would like to add cross-partition capabilities, specifically Govcloud, since Route53 records need to be deployed to the commercial partition when working in Govcloud. Being able to deploy records across partitions easily would certainly improve dev experience.

[github-actions[bot]]

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

[KevinFaro]

+1

[Finaktiva]

+1

[jsun1590]

+1

[jtobin321]

+1

[cwensel]

+1

[torgejensen]

+1

[meskander-ss]

+1