Aws-cdk: How to create Route 53 Alias record for cross-account Load Balancer Target

Created on 14 Apr 2020  路  8Comments  路  Source: aws/aws-cdk

:question: General Issue

The Question

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?

Environment

  • CDK CLI Version: 1.32.2
  • Module Version: 1.32.2
  • OS: OSX
  • Language: TypeScript

Other information

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.

@aws-cdaws-route53 guidance needs-triage

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.

All 8 comments

@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?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cybergoof picture cybergoof  路  3Comments

EduardTheThird picture EduardTheThird  路  3Comments

abelmokadem picture abelmokadem  路  3Comments

eladb picture eladb  路  3Comments

kawamoto picture kawamoto  路  3Comments