Managing Route 53 in a Multi-Account Environment

Gavin Lewis
6 min readApr 28, 2020
Photo by chepté cormani from Pexels

DNS is one of the cornerstones of the internet, translating words we know as domain names into the combination of numbers we know as IP addresses. The process of registering a domain, pointing it to your chosen DNS providers’ nameservers and then setting up your DNS records has remained mostly the same since inception. Without DNS we’d be stuck remembering combinations of IP addresses to visit our favourite websites.

In 2010, AWS introduced their flavour on DNS by releasing a service called Route 53. Route 53 includes all the usual DNS functionality, along with more advanced features such as alias records, failover and geographical routing (just to name a few), and a 100% uptime SLA. I almost exclusively use and recommend Route 53 for DNS for its reliability, flexibility and ease of use.

For developers, DNS is one of those components which can be messy, difficult to track and generally a manual process. On AWS, when your app gets to the point where you start splitting environments or services across multiple AWS accounts (this helps place boundaries around environments/services and limits the blast radius of failures), things start to get even complicated with DNS. Questions get asked such as, Who owns DNS? Who can make changes? How do changes get made? When you have multiple teams who want to make changes to the DNS zone’s records, and everyone is granted access, it’s not uncommon for free for all of changes to occur, usually with little awareness across teams, no accountability or version control.

Two common AWS Account strategies I see used in organizations.

One solution which I often see utilized is a centralized DevOps or SRE team as gatekeepers of the DNS zone. The issues I have with this method are, changes can be delayed depending on the workload of the team, or introduce human error between the party requesting the change and the party making the change. What if these problems could be solved by automating the process as part of a deployment? How do we do this without granting access to the entire DNS zone in a single AWS account? We can use delegation.

In a similar way to delegating nameservers for an entire domain, it’s possible to delegate parts of…

Gavin Lewis

Passionate about building and delivering solutions in the Cloud! Principal Cloud Architect @ Rapid Circle. Views are my own.