I use separate accounts per environment (dev, test, prod...). Additionally, I have a "Tools" account for common things such as public DNS, Docker containers and CodePipelines. Normally I manually create Route 53 records and have created alias records for cross-account ALBs in the past. I'm trying to do the same using the CDK but am getting the following error:
Stack "Dns" cannot consume a cross reference from stack "Api-DevUsEast1". Cross stack references are only supported for stacks deployed to the same environment or between nested stacks and their parent stack
The "Dns" stack contains the Hosted Zone and is deployed in the Tools account. The Api-DevUsEast1 stack holds the ALB and is deployed in my Dev account.
I'm hesitant to create a Hosted Zone for a subdomain in my environment accounts e.g. dev.my.app
because I'd prefer that the Prod account didn't need to use a subdomain e.g. my.app
instead of prod.my.app
. I prefer this mostly because it is easier for the end user.
Additionally, I like the env prefix to be at the lowest level e.g. dev.www.my.app
not www.dev.my.app
. Mostly because it makes more sense to me that way.
Anyway, is it possible to create an alias record for dev.www.my.app
which points to an ALB in a different account using the CDK?
My motivation for managing the Route 53 records with the CDK is because it was a hassle to update the alias record every time I destroyed and re-created an ALB. I'd like if the CDK could automatically update the records when the ALB was created or destroyed.
This issue seems loosely related to #3470
They are using AWS Control Tower in that case and are trying to create a DnsValidatedCertificate but its similar.
@shivlaks Is it possible to do this kind of cross-account DNS management with the CDK? If not currently, are their plans to support this kind of thing in the future? AWS Control Tower encourages this pattern and there are several AWS blog posts detailing how to manage your environments with separate accounts so I would imagine that it is a pretty standard use case. If I'm wrong and there is a different approach that I should be taking to DNS, let me know.
I have the same issue. Domain names and hosted zones reside in a specific account, and then we have accounts for "Dev", "Staging" and "Prod" environments. I don't know how to manage DNS entries in the DNS account and associate the entries with ressources created in the environment accounts.
@tleef Even when managing certificates and domain names manually (without the CDK), how do you link a domain name with your load balancer ? For instance, I use ApplicationLoadBalancedFargateService
and for TLS, it requires me to provide a certificate, domainName and domainZone.
const service = new ecp.ApplicationLoadBalancedFargateService(this, MyService, {
cluster,
taskDefinition,
publicLoadBalancer: true,
serviceName: 'MyServiceName',
domainName: 'myservice.example.com', // <-- this domain name is registered in another account
domainZone: '', // <-- this domain zone lives in another account, throwing a route53:GetHostedZone User is not authorized to access this resource
certificate: someCert, // <-- certificate is created manually in the same account as where the CDK runs
})
@mmeylan Unfortunately you wont be able to use the ApplicationLoadBalancedFargateService
construct because it tries to create the A record for you. See here
The way I do it is I create the ALB and Fargate service with the cdk using ApplicationLoadBalancer
and FargateService
respectively. Since I'm not using the pattern, I also create the VPC
, Cluster
, ApplicationTargetGroup
, ApplicationListenerRule
, SecurityGroups
(one for the ALB and another for the Fargate service) and whatever else you need to wire them together using the CDK.
I've done this so many times that I've created my own "Pattern" constructs that do most of this for me.
I manually create a certificate in the same account as the ALB and Fargate service. In the DNS account I manually create an Alias A record named myservice.example.com
with its value set to the DNS name generated for the ALB e.g. dualstack.xxxxxxx.us-east-1.elb.amazonaws.com.
(the "dualstack" is prepended automatically)
Thanks you so much @tleef, it's exactly what I was looking for. Indeed looking at the source of the ApplicationLoadBalancedFargateService, I understand why I couldn't make it work.
I can confirm the same issue simply using different regions. In other words addVpc
method for an HostedZone
refuses to take in a vpc that has been deployed in a similar account but different region.
@tleef thanks for this description, its really helped clarify the flow for me as I was also looking into how to make this work smoothly.
One clarification, do you use DNS validation for the certificate on the service account and if so I assume you add the validation record in the DNS account manually as well as part of creating a certificate?
@ltamrazov Yup, that's exactly right.
@tleef Awesome, and lastly again just want to confirm, the certificate gets created and activated before CDK is run right? CDK then just pulls the existing certificate and attaches it I assume?
Most helpful comment
@shivlaks Is it possible to do this kind of cross-account DNS management with the CDK? If not currently, are their plans to support this kind of thing in the future? AWS Control Tower encourages this pattern and there are several AWS blog posts detailing how to manage your environments with separate accounts so I would imagine that it is a pretty standard use case. If I'm wrong and there is a different approach that I should be taking to DNS, let me know.