Migrating your multi-account DNS environment to Amazon Route 53 Profiles

Large enterprises have a centralized networking team for configuring and managing baseline DNS settings across a multi-account, multi-VPC environment. Amazon Route 53 Profiles provides an ability to simplify management of DNS configuration across multiple VPCs and AWS accounts. Before this feature, users needed to perform the association of Private Hosted Zones (PHZ) and Route 53 Resolver rules to VPCs, especially across accounts. Customers built complicated automations with API based orchestration and create a disparate sharing experience to perform the automatic association of PHZs and Route 53 Resolver rules to newly-created accounts and VPCs within their organizations. With Route 53 Profiles, customers can manage one object to group their DNS configurations that can be shared across accounts and associated to VPCs.
This blogpost presents an approach for migration to Route 53 Profiles for various customer scenarios of the DNS setup.
Customers with multi-account and multi-VPC environments typically setup their environments using two approaches. In the first approach, the customers keep all PHZs in a central networking account, and in the second approach each application owner manages their own PHZ in their respective account. Both of these architectures allow for DNS resolution within an AWS environment as well as between AWS and on-premises resources. In the following section, we describe both approaches and how customers can migrate to Route 53 Profiles.
We start with three application accounts (App1 Dev Account, App2 Dev Account, and App1 Prod Account) and one Networking Account, as shown in the following figure.
Both development applications need to interact with each other for delivering functionality to the users. In both scenarios, on-premises is connected with AWS through AWS Direct Connect or AWS Site-to-Site VPN. An application with the domain dc1.onprem.private is running on-premises. The on-premises DNS server is updated to forward any DNS query for *.example.private to the Route 53 Resolver inbound endpoint.

Figure 1: Multi-account AWS setup with PHZ in the Networking Account
In this setup, the network admin has created PHZs for different applications such as dev.app1.example.private (PHZ-1) and dev.app2.example.private (PHZ-2) for the development applications, and prod.app1.example.private (PHZ-3) for the production application in the Networking Account. PHZ-1 and PHZ-2 are associated with App1 and App2 Dev Account VPCs, and PHZ-3 is associated with App1 Prod Account VPC. The Route 53 Resolver inbound and outbound endpoints are setup in the VPC in the Networking Account. The Route 53 Resolver rules are also setup in the Networking Account and shared with other accounts through AWS Resource Access Manager (AWS RAM). The member account’s Route 53 Resolver rules are associated with the application VPCs so that they can send the queries for on-premises through the outbound endpoint. This approach is described in the post “Using Route 53 Private Hosted Zones for Cross-account Multi-region Architectures”.

Figure 2: Multi-account AWS setup with PHZ in the Member Account
In this setup, the network admin manages the Forwarding Rules in the Networking Account and creates the Route 53 Resolver endpoints in the VPC in the Networking Account. However, each application team creates their own PHZ in their account and associates them with their own VPCs as well as VPCs in the Central account. PHZ dev.app1.example.private (PHZ-1) is created in App1 Dev Account, dev.app2.example.private (PHZ-2) is created in App2 Dev Account, and prod.app1.example.private (PHZ-3) is created in App1 Prod Account. To make sure applications running in the AWS accounts can resolve on-premises application DNS, Route 53 Resolver rules are set up to forward DNS queries related to *.dc1.onprem.private to the on-premises DNS server. These rules are shared with the Member Accounts using AWS RAM.
This approach is explained in the post “Simplify DNS management in a multi-account environment with Route 53 Resolver”.
As the environment grows with the addition of new accounts and VPCs, the admin needs to take into account the following:
Route 53 Profiles aims to simplify the complexity in the architectures discussed earlier. This feature gives network admins a way to unify management of DNS across all of their accounts and VPCs, as described in the post “Using Amazon Route 53 Profiles for scalable multi-account AWS environments”. Route 53 Profiles can group DNS configurations, such as Route 53 PHZ associations, Route 53 Resolver forwarding rules, and DNS firewall rules into a single container. Admins can apply this configuration container to multiple VPCs in the same AWS Region. You can share Route 53 Profiles across accounts using AWS RAM. Once the Profile is associated with a VPC, it responds to the VPC’s DNS queries based on the profile’s settings. If a PHZ is associated with a VPC and a Profile containing the PHZ is associated with the same VPC then DNS query is resolved using the direct association of the PHZ. Same holds true for Resolver rules as well. When DNS query is made for a conflicting domain name, the most specific one wins. This is described in Profile Prioritization. In the following section, we examine the two architecture scenarios previously discussed and demonstrate the benefits of using Route 53 Profiles, as well as the process for migrate.
Let’s discuss the scenario where the PHZ is managed by the Networking Account instead of the Member Accounts. The PHZ is created in the Networking Account and associated with each application account VPC. We begin with the architecture depicted in Figure 1, and then proceed with the migration steps outlined in the following section. Refer to this Route 53 documentation to understand how Route 53 Profiles can be created and associated to the PHZ and VPCs in a multi-account setup.
To start, follow these steps to create the base setup without impacting existing DNS resolutions workflow:
Make sure that the VPC associations, PHZ, and rule associations with the profile show the completed status before moving to the next section.

Figure 3: Migration to Route 53 Profiles from PHZ in the Networking Account
Now, let’s discuss how to migrate to Route 53 Profiles for DNS resolution. It is recommended to start with a single account and then repeat the process for other accounts.
Repeat these steps by removing the association of PHZs and Route 53 Resolver rules with the VPCs in the App2 Dev Account and App1 Prod Account.
Once you have completed the steps to create the base setup and implemented the described use cases, the architecture should resemble the following figure.

Figure 4: Multi-account DNS setup using Route 53 Profiles
Next let’s talk about the scenario where the PHZ is managed by each application account themselves instead of the central Networking Account. Here the PHZ is created in each application account and associated with the central Networking Account VPC. We begin with the architecture depicted in Figure 1 and then proceed with the migration steps outlined in the following section. Refer to this Route 53 documentation to understand how Route 53 Profiles can be created and associated to the PHZ and VPCs in a multi-account setup.
To start, follow these steps to create the base setup without impacting existing DNS resolutions workflow:
Make sure that the VPC associations, PHZ, and rule associations with the profile show the completed status before moving to the next section.

Figure 5: Migration to Route 53 Profiles from PHZ in the Member Account
Next, let’s discuss how to migrate to Route 53 profiles for DNS resolution. It is recommended to start with a single account and then repeat the process for other accounts.
Repeat these steps by removing the association of PHZs and Route 53 Resolver rules with the VPCs in the App2 Dev Account and App1 Prod Account.
Once you have completed the steps to create the base setup and implemented the described use cases, the architecture should resemble the following figure.

Figure 6: Multi-account DNS setup using Route 53 Profiles
Once the migration to Route 53 Profiles is completed, the ongoing management of the DNS configuration is simplified.
This post covered various scenarios of how customers can migrate to Route 53 Profiles depending on their DNS setup across a multi-account environment. Route 53 Profiles can help simplify complex DNS configurations in these environments and reduce the friction between application teams and network admins. Refer to the Route 53 Profiles documentation and watch a Video Tutorial to learn more.

As an AWS Principal Solutions Architect, Anandprasanna Gaitonde is responsible for helping customers design and operate Well-Architected solutions to help them adopt the AWS cloud successfully. He focuses on AWS Networking and Serverless technologies to design and develop solutions in the cloud across industry verticals. He has Solutions Architect Professional and Advanced Networking certifications and holds a Master of Engineering degree in Computer Science and a postgraduate degree in Software Enterprise Management.

As an Enterprise Support Lead in AWS Enterprise Support who helps enterprise support customers streamline their cloud operations on AWS. He is a results-driven IT professional with over 18 years of experience.

As an AWS Senior Solutions Architect, Amit Narang is responsible for helping customers design and operate Well-Architected solutions. Driven by his passion for technology, his role involves assisting customers in crafting and implementing solutions that fully embrace the potential of the AWS Cloud.