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

Introduction

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.

Customer environment with 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.

• App1 Dev Account has a development application running with PHZ dev.app1.example.private
• App2 Dev Account has a development application running with PHZ dev.app2.example.private
• App1 Prod Account has a production application running with PHZ prod.app1.example.private

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.

PHZs in the Networking Account

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”.

PHZs in the Member Accounts

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”.

Scaling Considerations for the preceding setups

As the environment grows with the addition of new accounts and VPCs, the admin needs to take into account the following:

1. Integrating new accounts and VPCs into the DNS setup requires multiple steps involving coordination with individual account owners and application teams. These steps include associating relevant PHZs with the new VPCs, sharing Route 53 Resolver rules through AWS RAM, and selectively applying PHZs based on the environment (such as production or non-production). The process can be cumbersome and error-prone for large environments.
2. In the case of the scenario “PHZ in member accounts”, the reliance on outbound and inbound Route 53 Resolver endpoints to transport DNS queries from VPC resources to other resources within AWS can lead to scalability issues and increased costs as the number of DNS queries grows.

Moving to Route 53 Profiles

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.

Migration Scenario 1: PHZs in the Networking Account

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.

Steps for migration

To start, follow these steps to create the base setup without impacting existing DNS resolutions workflow:

1. Create Route 53 Profiles in the Networking Account. In our example we have created two Route 53 Profiles, DevApp and ProdApp, one for each environment.
2. Associate PHZ-1 and PHZ-2 with Route 53 Profiles: DevApp and PHZ-3 with Route 53 Profiles: ProdApp.
3. Share Route 53 Profiles: DevApp with App1 Dev and App2 Dev Account, and Route 53 Profiles: ProdApp with App1 Prod Account using AWS RAM.
4. Associate the VPCs from the application accounts with the shared Route 53 Profiles in each account.
5. Associate the Route 53 Resolver Rule in the Networking Account with both Route 53 Profiles.

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.

• Remove the association of PHZs with the VPC in the App1 Dev Account for the AWS-hosted application to the application DNS resolution.
• Remove the association of the Route 53 Resolver rule with the App1 Dev Account VPC for DNS resolution for on-premises hosted applications from AWS through Outbound endpoints. Once satisfied you may want to delete the sharing of the Route 53 Resolver rule-1.

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

Migration Scenario 2: PHZs in Member Accounts

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.

Steps for migration

To start, follow these steps to create the base setup without impacting existing DNS resolutions workflow:

1. Create Route 53 Profiles in the Networking Account. In our example we have created three Route 53 Profiles, DevApp and ProdApp one for each app environment and Networking Profile for onprem connectivity.
2. Associate the Networking Account VPC with the Networking Profile.
3. Associate both Route 53 Resolver rules, which are set up to forward DNS queries to the on-premises DNS server and to the inbound endpoint, with DevApp and ProdApp Profiles.
4. Share Route 53 Profiles with other application accounts using AWS RAM.
5. Associate the VPCs from the application accounts with the shared Route 53 Profiles, DevApp profile will be associated with VPC of App1 and App2 Dev account and ProdApp Profile will be associated with VPC of App1 Prod account.
6. Associate the PHZs from the application accounts with the shared Route 53 Profiles.

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.

• Remove the association of Route 53 Resolver rule-2 with the VPC in the App1 Dev Account for AWS-hosted application to application DNS resolution. Once satisfied you may want to delete the sharing of Route 53 Resolver rule-2.
• Remove the association of PHZ-1 with the networking account VPC for DNS resolution for AWS-hosted applications from on-premises through inbound endpoints.
• Remove the association of Route 53 Resolver rule-1 with the App1 Dev Account VPC for DNS resolution for on-premises hosted applications from AWS through Outbound endpoints. Once satisfied you may want to delete the sharing of Route 53 Resolver rule-1.

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

Post migration benefits

Once the migration to Route 53 Profiles is completed, the ongoing management of the DNS configuration is simplified.

• Admins can perform the work of creating Route 53 Profiles as per the required structure, the ProdApp Profile and DevApp Profile in the Networking Account, and share it with the appropriate accounts. Individual account owners/application teams can create their PHZ and associate it with the correct profile to make sure of cross-account and cross-VPC DNS resolution. This separation of concerns reduces the coordination overhead and improves agility for the teams.
• Eliminating the DNS traffic for internal AWS resources from the path of Route 53 Resolver endpoints eliminates the unnecessary costs incurred by the Route 53 Resolver endpoints.

Considerations

1. Although the migration to Route 53 profiles is seamless and does not need downtime, it is advised to test this migration setup in a test environment first before making changes to the production environment.
2. While applying this migration path and creating multiple Route 53 Profiles for your needs, note that a VPC can be associated with a single Route 53 Profile at a time. Therefore, if you have multiple workload components in a single VPC, then you want to consider their DNS needs being encapsulated into a single Route 53 Profile.
3. As described on the Route 53 pricing page, VPC Profiles are charged with an hourly rate for each Profile-VPC association. Therefore, while choosing the number of profiles needed for your environment, make sure you don’t go too granular, which can lead to a large number of Profile-VPC associations.
4. At any point in time if a VPC is associated with the PHZ as well as a Route 53 Profile, Route 53 Resolver uses the direct PHZ association first as documented in, How Route 53 Profile settings are prioritized.

Summary

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.

About the author