How Northwestern Mutual optimized and improved efficiency with Amazon Route 53 Profiles | Amazon Web Services

Managing DNS configurations across multiple Amazon Virtual Private Clouds (Amazon VPCs) and Amazon Web Services (AWS) accounts can be a daunting task for network administrators, especially in complex environments with numerous Private Hosted Zones (PHZs) and Amazon Route 53 Resolver rules. Traditionally, they relied on outbound and inbound Route 53 Resolver endpoints to transport DNS queries between VPC resources across accounts, which led to operational overhead and increased costs. Enter Route 53 Profiles, a feature that streamlines DNS management by providing a centralized method for configuring and managing DNS settings across multiple VPCs and accounts.
This post showcases how Northwestern Mutual, an AWS customer, transformed their environment by migrating to Route 53 Profiles, reducing costs and operational overhead in the process.
At Northwestern Mutual, we manage hundreds of AWS accounts and have adopted a distributed deployment strategy for Amazon Route 53 PHZs. This approach involves provisioning a dedicated PHZ within each AWS account. Implementing this pattern provides development teams with access to their own isolated PHZ, which they use to manage DNS record sets specific to their AWS workloads. This approach empowers teams with dedicated DNS management capabilities and mitigates the potential impact of DNS changes made by a single team on the broader DNS ecosystem across the organization. Figure 1 shows our current architecture for DNS resolution between AWS and the corporate data center.
As part of our established and architected account provisioning process and landing zone, we automatically provision a PHZ within each new AWS account. We associate this PHZ with a VPC local to the account where we provision it. To maintain consistency and ease of identification, we follow a standardized naming convention for these PHZs: <account-identifier>.aws.example.com
In this naming structure, ”account-identifier” represents a unique identifier for the specific AWS account, while ”example.com” is our internal corporate domain. For example, for an account with an identifier of “ABC”, the resulting PHZ name would be abc.aws.example.com. We follow this pattern for all accounts across our ecosystem.
As shown in the following figure, our organization has a dedicated central networking account named the “Network Services Account”. Within this central account, we have provisioned a dedicated VPC called the ”DNS Hub” VPC. This ”DNS Hub” VPC serves as the centralized focal point for DNS resolution across our entire AWS environment.

Figure 1. Northwest Mutual current environment showing DNS resolution between AWS and Corporate Data Center
To facilitate DNS resolution from our on-premises environment (desktops, servers, etc.) to the DNS record sets hosted in our Route 53 PHZs, we used the Route 53 Resolver Inbound Endpoint feature. As shown in Figure 1, we deployed this Inbound Endpoint in a dedicated ”DNS Hub” VPC to provide it with a comprehensive view of our entire private DNS ecosystem.
This ”DNS Hub” VPC serves as a centralized reference point for private DNS across our organization. As well as each PHZ associating with its account-local VPC, we established a cross-account association between all PHZs and this ”DNS Hub” VPC. Consequently, the ”DNS Hub” VPC provides a comprehensive view of all Route 53 PHZs across our AWS accounts.
The Resolver Inbound Endpoint deployed within the ”DNS Hub” VPC is associated with every PHZ in our organization. This association provides a comprehensive private DNS view, including all PHZs across our AWS ecosystem. To enable on-premises resolution, we configured our on-premises DNS server to forward all DNS queries for the *.aws.example.com domain to this centralized Resolver Inbound Endpoint.
Through this architecture we have established a seamless DNS resolution mechanism that allows our on-premises resources (desktops, servers, etc.) to resolve DNS record sets hosted in our Route 53 PHZs across multiple AWS accounts.
To enable the resolution of DNS records for applications hosted in our on-premises environment from resources within our VPCs, we used the following AWS services and components: a Route 53 Resolver Outbound Endpoint, a Route 53 Resolver Rule, and an AWS Resource Access Manager (AWS RAM) Resource Share. Refer to Figure 1 for a visual representation of this architecture.
Enabling DNS resolution between resources in a VPC in one AWS account and a DNS record hosted in a PHZ located in another account, posed a challenge that needed a unique solution. We used additional components and built upon the existing architecture, as shown in Figure 1, to address this.
The cross-account query resolution flow relies on the following key components and configurations:
With these additional components in place, the cross-account query resolution flow works as follows:
This configuration establishes a cross-account DNS resolution mechanism. It allows resources in one AWS account to resolve DNS records in PHZs of another account. This creates a unified DNS ecosystem across our entire AWS environment, spanning multiple accounts and private zones.
To fully use the resiliency of Route 53, AWS recommends directly associating each PHZ with the VPC that needs it, even in cross-account scenarios. This approach creates a full mesh of VPCs and hosted zones, which becomes challenging to manage when dealing with hundreds of VPCs.
As a result, we sought an alternative solution described earlier that avoids the need for a full mesh of VPCs to hosted zones. However, this design presents some challenges. DNS queries need to be forwarded through multiple Resolver endpoints to get a response, which adds complexity and introduces potential performance issues if an Availability Zone (AZ) experiences degradation. Furthermore, managing the cross-account association between VPCs and hosted zones is a multi-step process, involving actions in both the hosted zone’s account and the “Hub” VPC’s account. Although we have automated this process, it’s still a step we’d prefer to avoid.
Figure 2 represents our environment after completing the migration. To complete the migration, we followed these steps to create a base setup without affecting our existing DNS resolution workflow:
Next, we discuss the steps we took to migrate to Route 53 profiles for DNS resolution. We started the migration with a single account in our organization and repeated the process for other accounts.
We repeated these steps for other accounts in our organization by removing the associations of PHZs and Route 53 Resolver rules with their respective VPCs. Finally, we deleted the sharing of Resolver rules with our organization.

Figure 2. Northwest Mutual environment showing DNS resolution between AWS and Corporate Data Center after migrating to Route53 Profiles
Our organization is delighted to bring Route 53 Profiles into our growing mix of foundational AWS services. It reduces complexity by eliminating the need for a few other components. Furthermore, it enhances resiliency by effectively creating a full mesh of Route 53 private zones to VPCs in our environment. Adopting the service also streamlines our new account onboarding process, where we no longer need to perform a cross-account hosted zone to VPC associations.

Ankush Goyal.jpg
Ankush Goyal is a Senior Technical Account Manager at AWS Enterprise Support, specializing in helping customers in the travel and hospitality industries optimize their cloud infrastructure. With over 20 years of IT experience, he focuses on leveraging AWS networking services to drive operational efficiency and cloud adoption. Ankush is passionate about delivering impactful solutions and enabling clients to streamline their cloud operations.

Travis Diener is a Lead Software Engineer at Northwestern Mutual, based in Milwaukee, Wisconsin. He is a passionate Cloud advocate, and enjoys providing technical guidance, mentoring others, and leading cloud infrastructure design and implementation efforts within his organization, ensuring their success on AWS. He holds a BS in Computer Science and several AWS certifications. He has been building on AWS for nearly eight years.

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.