An interesting question came up in a conversation today:

“How should I manage the Route53 DNS records in a multi-account environment?”

Suppose you have configured an AWS Organization with different accounts for dev, staging and production environments. And you have registered the root domain for your application in the master AWS account.

When working with CloudFront or API Gateway, you often need to issue ACM (Amazon Certificate Manager) certificates in order to use custom domain names.

To verify the ACM certificate request, you can add a CNAME record to the Route53 hosted zone. *You can use email verification too, but it doesn’t play as nicely with infrastructure-as-code (IaC) as it introduces an external step that requires human (from the right person!) intervention.

Most IaC tool (CloudFormation/CDK/Terraform/etc.) cannot span across multiple accounts. So in a multi-account environment where the ACM certificate request originates from a different account to where the domain is hosted is problematic.

img 60929ca52996d

Instead, you want to arrange your domain names so that each account owns its subdomain and can verify any ACM requests it creates.

Here’s how.

Step 1. host the root domain in the master account.

img 60929cb9d2c5c

Step 2. host a subdomain in each environment-specific accounts for dev, test, staging, prod, etc.

img 60929ccc3bb29

Step 3. for each of the subdomains in the corresponding AWS account, note the NS record that Route53 has created automatically.

img 60929cddaddb1

Step 4. back in the Master account, create a NS record for each of the subdomains and use the NS record values from Step 3.

img 60929cf34b4d7

Essentially, this delegates the ownership of the subdomains to the corresponding AWS account’s Route53 hosted zone. So the dev account now owns the subdomain, and the prod account owns the subdomain and so on.

From here on, any CloudFront distributions or APIs should use subdomains to these account-level subdomains?—?e.g. or And since the dev account owns the subdomain, you can verify the ACM certificates for by creating a CNAME record inside the hosted zone. No more cross-account dependencies!

But, that still leaves you with the question of “How do I set up these hosted zones in the first place?”.

Infra-as-Code for the Route53 hosted zones

You can of course set them up by hand, which might be the quickest way to get it done and it’s probably gonna be fine if you only have a small number of environments. But it’s not gonna scale if you have a lot of environments, or maybe you need to have team-specific subdomains on top of environment-specific subdomains?—?e.g.

One option is to write custom scripts to stitch multiple CloudFormation templates together and execute them in sequence. For example:

  1. Deploy a template in the dev account to provision the hosted zone in Route53.
  2. Deploy a template in the master account to add the NS record to the hosted zone in Route53.
  3. Rinse and repeat for every other sub-account.

A much better way to do this in a true infrastructure-as-code way is via org-formation. org-formation is an awesome open-source tool that gives you a CloudFormation-like syntax to manage your entire AWS Organization. It lets you create new AWS accounts, assign them to Org Units (OUs), and configure Service Control Policies (SCP) and so on.

Additionally, it lets you create landing zones for these new accounts similar to AWS Control Tower’s account factory. But whereas Control Tower doesn’t let you update the landing zones for existing accounts, org-formation lets you manage and update your landing zone configurations as your environment matures.

org-formation makes cross-account references work like normal references inside a CloudFormation template. So it’s actually trivial to setup the subdomain in the dev account and then reference its NS values in the master account. There’s even an example template that you can use out-of-the-box!

org-formation has been one of the mainstays in my toolbelt and have allowed me to configure complex AWS environments from scratch in a matter of hours. If you’re responsible for managing the AWS environment in your organization then you should definitely check it out!

Liked this article? Support me on Patreon and get direct help from me via a private Slack channel or 1-2-1 mentoring.

Screenshot 2019 10 19 at 11.44.09

img 5dab0c477fc72

Hi, my name is Yan Cui. I’m an AWS Serverless Hero and the author of Production-Ready Serverless. I specialise in rapidly transitioning teams to serverless and building production-ready services on AWS.

Are you struggling with serverless or need guidance on best practices? Do you want someone to review your architecture and help you avoid costly mistakes down the line? Whatever the case, I’m here to help.

You can contact me via Email, Twitter and LinkedIn.

Hire me.

The post How to manage Route53 hosted zones in a multi-account environment appeared first on