Using Amazon Route 53 Profiles for scalable multi-account AWS environments

Amazon Web Services (AWS) customers implement multi-account strategies so that multiple teams can deploy workloads in separate organizational units (OUs) and AWS accounts. Cloud administrators are using this practice through offerings such as AWS Control Tower and AWS Organizations. These services help them get things done using individual accounts while maintaining centralized control for governance and security. This post presents a way to build a flexible DNS configuration in a multi-account environment using Amazon Route 53 Profiles. It presents an architectural view of how Profiles are used to group DNS configurations together and apply them selectively. The solution we present here can also help address many network security and configuration challenges.

To facilitate seamless connectivity across their AWS environment, many customers build a network that spans multiple accounts and Amazon Virtual Private Clouds (VPCs). While applications and workloads may use a shared network topology for internal communications and to communicate with the public internet, DNS requirements may vary. Network administrators face the challenge of centrally managing varying DNS configurations. But at the same time, they must be able to apply them to individual accounts and VPCs to maintain centralized control over network configuration.

Using Amazon Route 53 Profiles: Example

In this example scenario, you are running your applications in a multi-account environment using AWS Control Tower. Following multi-account best practices, a dedicated account is set up for networking resources within the infrastructure OU. Your application teams are developing consumer apps hosted in AWS accounts under the consumer apps OU. There are dedicated accounts and VPC for development and production workloads. Your data science team is hosting workloads for data analytics in a data and machine learning (ML) OU. Finally, there is a dedicated account within the Legacy Apps OU for a few legacy workloads that must connect to an on-premises data center. We show this environment in Figure 1.

Figure 1: Route 53 DNS configurations in a multi-account AWS environment used in this example.

In this environment, you have different applications running across accounts, and DNS requirements vary between OUs. Some workloads have common sets of DNS configurations, while other configurations vary depending on whether they are for a consumer app, data analytics, or a legacy application. And, configurations can vary between production and development environments. This adds overhead for your cloud network administrators who must create a large number of different DNS configurations and apply them correctly and consistently to many environments, and manage them centrally.

In this example scenario, you have the following DNS requirements:

• You must create different private hosted zone configurations, which apply to consumer apps in the production environment, consumer apps in the development environment, and to data platform workloads.
• You must configure Route 53 Resolver rules and only use them with the legacy workload account and VPC, along with the centralized networking account and hub DNS VPC. Other VPCs do not require on-premises connectivity and must be excluded from this configuration.
• You must apply different Route 53 DNS Firewall rule groups depending on whether the VPC is hosting a consumer application or a data platform workload.

Route 53 Profiles: Centralized DNS Configuration and Governance

AWS has created Amazon Route 53 Profiles to give network admins a way to unify management of DNS across all of their accounts and VPCs. Route 53 Profiles can group DNS configurations, such as Route 53 private hosted zone associations, Resolver forwarding rules, and DNS Firewall rules into a single container. Admins can then apply this configuration container to multiple VPCs in the same AWS Region. You can share Route 53 Profiles across accounts using AWS Resource Access Manager (AWS RAM). Once the profile is associated with a VPC, it responds to the VPC’s DNS queries based on the profile’s settings.

Using Amazon Route 53 Profiles to apply configurations

In this scenario, you use Route 53 Profiles to apply configurations based on the workload type in the account and environment. Creating these Route 53 profiles helps you apply the same settings consistently as additional workloads and VPCs are created in different AWS accounts. Based on the requirements of different teams, several DNS configurations have been created. There are configurations for consumer apps development and production environments, data platform, and legacy workloads that require connectivity to the on-premises environment. The following Route 53 profiles are created for this scenario, as shown in Figure 2.

Figure 2: Route 53 Profiles for varying workloads used in this example.

• ConsumerApps-Dev – Contains the PHZ for consumer apps in the development environment (PHZ-ConsumerAppsDev) and DNS Firewall rule groups applicable for consumer apps (DNS Firewall Rule Group-ConsumerApps).
• ConsumerApps-Prod – Contains the PHZ for consumer apps in the production environment (PHZ-ConsumerAppsProd) and DNS Firewall rule groups applicable for consumer apps (DNS Firewall Rule Group-ConsumerApps).
• Data platform – Contains the PHZ for data platform components and the DNS Firewall rule groups required for the data platform.
• Legacy OnPrem – This profile is for legacy workloads that have connectivity requirements with the on-premises environment and hence includes Route 53 Resolver rules to forward DNS traffic to the on-premises DNS server.

The following steps show how these configurations are grouped into the profiles needed by their environment and are applied selectively. You will create configurations for private hosted zones, DNS Firewall rule groups, and Resolver rules as shown in Figure 2. These steps assume that the DNS configurations already exist.

Step 1: Creating Route 53 profiles for varying workload requirements

1. To create a Route 53 Profile, navigate to the Route 53 console within the AWS Management Console.
2. From the navigation menu, select Profiles and choose Create a profile, as shown in Figure 3.
   

   Figure 3: The Route 53 Profiles page in the AWS Management Console.

3. For Profile name, enter ConsumerAppsDevProfile and choose Create profile, as shown in Figure 4. This profile caters to the development environment for the consumer apps workload and refers to the one highlighted in Figure 2.
   

   Figure 4: Amazon Route 53 profile creation screen.

4. Once ConsumerAppsDevProfile is created, associate your DNS Firewall rule groups under the DNS Firewall rule groups tab. Choose Associate, as shown in Figure 5.
   

   Figure 5: Create an association with Route 53 Profiles rule group.

5. Select the DNS Firewall rule group ConsumerAppsFirewallRG as shown in Figure 6, and choose Next.
   

   
   Figure 6: Route 53 Profiles with the selected rule group.

   On the next screen, specify the Priority and click Submit. Since this is the first DNS Firewall rule group in your profile, keep the default value of 101 as shown in Figure 7.

   

   Figure 7: Route 53 Profiles with default priority.

   Figure 8 shows the profile after the DNS Firewall rule group association is complete.

   

   Figure 8: Route 53 Profiles with the rule group associated.

6. Now you can associate ConsumerAppsDev PHZ by visiting the Private hosted zones tab in the Profiles console, as shown in Figure 9. Choose Associate.
   

   Figure 9: Route 53 Profiles showing how to associate private hosted zones.

7. Select the ConsumerAppsDev private hosted zone (consumerappsdev.example.com) as shown in Figure 10. Choose Associate.
   

   Figure 10: Route 53 Profiles showing how to select private hosted zones

   The Private hosted zones tab of ConsumerAppsDevProfile displays the PHZ associated, as shown in Figure 11.

   

   Figure 11: Route 53 Profiles showing associated private hosted zones

   Using the instructions shown in Step 1, you can create Route 53 profiles (Figure 2) for DataPlatformProfile, ConsumerAppsProdProfile, and LegacyOnPremProfile. Each profile will have its own DNS-related resources (DNS Firewall rule groups, private hosted zone, and Resolver rules) as required. All the Route 53 profiles are shown in Figure 12.

   

   Figure 12: All Route 53 profiles.

Step 2: Sharing a Route 53 profile with accounts and OUs

1. As mentioned earlier, you can share Route 53 Resolver profiles across accounts using AWS RAM. For sharing profiles, choose Share profile as shown in Figure 13, which will take you to the AWS RAM Create resource share page.
   

   Figure 13: Share profile from the Route 53 Profiles console.

2. Specify a name for your resource share, for example, ConsumerAppsDevProfileShare, and select the ConsumerAppsDevProfile ARN, as shown in Figure 14. If you have multiple profiles created, you can use the search box to search for them and select all that you want to share.
   

   Figure 14: AWS Resource Access Manager showing how to share Route 53 profiles.

3. Choose Next to go to the next screen, where you can specify the permissions allowing specific actions on this shared resource. Keep the default and select Next, as shown in Figure 15.
   

   Figure 15: AWS Resource Access Manager showing how to share Route 53 Profiles managed permissions.

4. On the next screen, under Grant access to principals, select Allow sharing with anyone. If you restrict sharing only within your own organization, then select the other option. In this scenario, you do not specify these restrictions. Select the principal type as AWS account and specify the AWS account ID of the ConsumerAppsDev account, then choose Add, as shown in Figure 16. Then choose Next, and on the Review screen, choose Create resource share.
   

   Figure 16: Resource Access Manager showing how to share Route 53 Profiles and select the principal type.

Step 3: Associating Route 53 profiles to existing VPCs

1. Route 53 profiles can be associated with VPCs in the same account as the profile or in other accounts to which the profiles are shared. In Step 2, you shared ConsumerAppsDevProfile with the ConsumerAppsDev account. As shown in Figure 17, its status is Shared with me.
   

   Figure 17: Route 53 Profiles showing the list view of the shared account.

2. To associate VPCs from the ConsumerAppsDev account to this shared profile, sign in to that account and go to the Route 53 Profiles console. Select ConsumerAppsDevProfile, select the VPCs tab, and choose Associate, as shown in Figure 18.
   

   Figure 18: Route 53 Profiles showing how to associate with VPCs.

3. Select the VPC from the list and choose Associate, as shown in Figure 19.
   

   Figure 19: Route 53 Profiles showing how to associate with the selected VPC.

4. Once you choose Associate, go back to the profile and wait for it to be associated, as shown in Figure 20.
   

   Figure 20: Route 53 showing the profile associated with the VPC.

5. To associate the VPC with the owner account, sign back in to the owner account and follow similar steps to associate the VPC. The VPC appears once it is associated and is shown in Figure 21.
   

   Figure 21: Route 53 Profiles showing associated VPCs in the owner account

Step 4: Central view of Route 53 Profiles and associations

Once you have created and associated the Route 53 profiles, you can centrally manage the DNS Firewall rules groups, private hosted zones, and Resolver rules from one place.

Figure 22: Centralized view of Route 53 Profiles configurations

Considerations

Amazon Route 53 Profiles groups DNS configurations for multi-account environments and is used for scaling DNS management across multiple accounts and VPCs. It is used when you have centralized DNS in a shared services VPC in a networking account, or in a decentralized manner when DNS ownership and management is delegated to each account.

The Route 53 profile acts as a logical container for a DNS configuration. Adding or removing configuration resources (PHZ, DNS Firewall rule groups, Resolver rules) from the profile does not affect their functionality.

When PHZs are added to the Route 53 profile and the profiles associated with VPCs, the PHZ does not need to be explicitly associated with those VPCs. However, each PHZ must have a single VPC association by design, so make sure it is associated with the VPC with the corresponding workloads.

While grouping your resources into Route 53 profiles, keep in mind that a VPC can only be associated with one Route 53 profile. If a VPC contains multiple workloads that need different profile configurations, it is best to either:

• Regroup your profile configurations to align with your VPC architecture.
• Restructure your workloads into different VPCs for segregation and alignment with your Profiles configuration, if possible.

If customers are migrating their existing DNS configuration into Route 53 Profiles, then the following points must be considered.

• Removing VPC associations with DNS configuration resources and switching to associating with the Route 53 profile will cause a loss of functionality for a few seconds.
• A Route 53 profile from a central account can be associated with configuration resources in another account. For a decentralized setup, this is useful since it does not require moving configuration resources from other accounts to a centralized account.
• When migrating to Route 53 Profiles, if you plan to create new configuration resources and retire old ones, then you may experience downtime based on your migration plans.

Conclusion

In this post, we have shown how you can simplify your DNS configurations across VPCs and accounts using Route 53 Resolver profiles. Resolver profiles create a centralized and simple configuration and apply it consistently, while giving you the flexibility to address different workload requirements.

For more information, refer to the Amazon Route 53 documentation.

About the author