Closed akefirad closed 3 years ago
Thanks for your feedback, we are looking into it and propose you to have a quick chat about it early next week if possible.
Hi @akefirad,
Thanks for your feedback. You're analysis is correct, but I think in that case you can as well directly have a dedicated CDK App, dedicated to DNS and use standard CDK construct to build your DNS structure. Having each dedicated domain resides in its own account won't extend especially your threat model and you won't need any specific cross-accounts complex delegation. I can provide an example of such implementation if you think it's something valuable to add as an alternative to the currently proposed DNS structure.
I think you're right. In this case, it doesn't make sense. An example would be highly appreciated. Thanks.
Here is an example https://github.com/aws-samples/aws-bootstrap-kit-examples/pull/27
I understand that "this is a strongly opinionated CDK set of constructs", however I just wanted to give it a shot.
It is fairly common (in my experience) that companies have different domains for different stages (accounts), for example we have foo.io for production, foo.qa for QA, and foo.dev for development accounts/environments. I'd like to suggest to support this use case.
I had a quick look at the code and had the feeling that the cost of the requested feature is not significant (disclaimer: I'm neither TS programmer nor CDK guru). My understanding is if we add
rootHostedZoneDNSName?: string
field toAccountSpec
, it should be possible to implement the feature in a backward compatible way (however I think it leads to two zone delegations).I'd be happy to help with this feature request (since this is a blocker for us to use this library).