[Route53] cdk-route53 Cross account records. #15213
Comments
mrpackethead
added
feature-request
njlynch
added
effort/medium
|
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 I am marking this issue as 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. |
|
+1 |
|
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. |
|
+1 |
|
+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 |
|
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. |
|
+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. |
|
+1 |
|
I've created a construct library to help solve this issue. I'd love any feedback |
|
+1 |
1 similar comment
|
+1 |
|
+1 Mainly interested in the ability to validate ACM certificates cross-account. |
|
+1 |
3 similar comments
|
+1 |
|
+1 |
|
+1 |
|
@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 (#23526 (comment)). :( 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. |
|
+1 Similarly, I would like to create NS records pointing to subdomains which are hosted in separate accounts automatically from CDK |
|
+1 |
|
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. |
|
+1 |
6 similar comments
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
|
+1 |
1 similar comment
|
+1 |
\### Issue # (if applicable) Closes aws#15213 Addresses aws#26754 \### Reason for this change \### Description of changes \### Description of how you validated changes \### Checklist - [x] My code adheres to the [CONTRIBUTING GUIDE](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) and [DESIGN GUIDELINES](https://github.com/aws/aws-cdk/blob/main/docs/DESIGN_GUIDELINES.md) --- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
+1 |
|
+1 I see this was very close to being implemented here and subsequently abandoned: #31281 ? Any chance this can be reviewed and completed? |
and others
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
This is a 🚀 Feature Request
The text was updated successfully, but these errors were encountered: