Using Route 53 Private Hosted Zones for Cross-account Multi-region Architectures
AWS Architecture BlogUsing Route 53 Private Hosted Zones for Cross-account Multi-region Architecturesby Anandprasanna Gaitonde and John Bickle | on20 JAN 2021| inAmazon CloudWatch,Amazon Route 53,Amazon VPC,Architecture,AWS Control Tower,AWS Direct Connect,Resource Access Manager (RAM)|Permalink|ShareThis post was co-written by Anandprasanna Gaitonde, AWS Solutions Architect and John Bickle, Senior Technical Account Manager, AWS Enterprise SupportIntroductionMany AWS customers have internal business applications spread over multiple AWS accounts and on-premises to support different business units. In such environments, you may find a consistent view of DNS records and domain names between on-premises and different AWS accounts useful.Route 53 Private Hosted Zones(PHZs) andResolver endpointson AWS create an architecture best practice for centralized DNS in hybrid cloud environment. Your business units can use flexibility and autonomy to manage the hosted zones for their applications and support multi-region application environments for disaster recovery (DR) purposes.This blog presents an architecture that provides a unified view of the DNS while allowing different AWS accounts to manage subdomains. It utilizes PHZs with overlapping namespaces and cross-account multi-region VPC association for PHZs to create an efficient, scalable, and highly available architecture for DNS.Architecture OverviewYou can set up a multi-account environment using services such asAWS Control Towerto host applications and workloads from different business units in separate AWS accounts. However, these applications have to conform to a naming scheme based on organization policies and simpler management of DNS hierarchy. As a best practice, the integration with on-premises DNS is done by configuringAmazon Route 53Resolver endpoints in a shared networking account. Following is an example of this architecture.Figure 1 – Architecture DiagramThe customer in this example has on-premises applications under the customer.local domain. Applications hosted in AWS use subdomain aws.customer.local. On-prem DNS server uses DNS forwarding to forward queries for that subdomain to AWS. The example here shows three applications that belong to three different teams, and those environments are located in their separate AWS accounts to allow for autonomy and flexibility. This architecture pattern follows the option of the “Multi-Account Decentralized” model as described in the whitepaperHybrid Cloud DNS options for Amazon VPC.This architecture involves three key components:1. PHZ configuration:PHZ for the subdomain aws.customer.local is created in the shared Networking account. This is to support centralized management of PHZ for ancillary applications where teams don’t want individual control (Item 1a in Figure). However, for the key business applications, each of the teams or business units creates its own PHZ. For example, app1.aws.customer.local – Application1 in Account A, app2.aws.customer.local – Application2 in Account B, app3.aws.customer.local – Application3 in Account C (Items 1b in Figure). Application1 is a critical business application and has stringent DR requirements. A DR environment of this application is also created in us-west-2.For a consistent view of DNS and efficient DNS query routing between the AWS accounts and on-premises, best practice is to associate all the PHZs to the Networking Account. PHZs created in Account A, B and C are associated with VPC in Networking Account by usingcross-account association of Private Hosted Zones with VPCs. This creates overlapping domains from multiple PHZs for the VPCs of the networking account. It also overlaps with the parent sub-domain PHZ (aws.customer.local) in the Networking account. In such cases where there is two or more PHZ with overlapping namespaces, Route 53 resolver routes traffic based on most specific match as described in theDeveloper Guide.2. Route 53 Resolver endpoints for on-premises integration (Item 2 in Figure):The networking account is used to set up the integration with on-premises DNS using Route 53 Resolver endpoints as shown inResolving DNS queries between VPC and your network. Inbound and Outbound Route 53 Resolver endpoints are created in the VPC in us-east-1 to serve as the integration between on-premises DNS and AWS. The DNS traffic between on-premises to AWS requires anAWS Site2Site VPN connectionorAWS Direct Connectconnection to carry DNS and application traffic. For each Resolver endpoint, two or more IP addresses can be specified to map to different Availability Zones (AZs). This helps create a highly available architecture.3. Route 53 Resolver rules (Item 3 in Figure):Forwarding rules are created only in the networking account to route DNS queries for on-premises domains (customer.local) to the on-premises DNS server.AWS Resource Access Manager(RAM) is used to share the rules to accounts A, B and C as mentioned in the section“Sharing forwarding rules with other AWS accounts and using shared rules”in the documentation. Account owners can now associate these shared rules with their VPCs the same way that they associate rules created in their own AWS accounts. If you share the rule with another AWS account, you also indirectly share the outbound endpoint that you specify in the rule as described in the section “Considerations when creating inbound and outbound endpoints” in the documentation. This implies that you use one outbound endpoint in a region to forward DNS queries to your on-premises network from multiple VPCs, even if the VPCs were created in different AWS accounts. Resolver starts to forward DNS queries for the domain name that’s specified in the rule to the outbound endpoint and forward to the on-premises DNS servers. The rules are created in both regions in this architecture.This architecture provides the following benefits:Resilient and scalableUses the VPC+2 endpoint, local caching andAvailability Zone(AZ) isolationMinimal forwarding hopsLower cost: optimal use of Resolver endpoints and forwarding rulesIn order to handle the DR, here are some other considerations:For app1.aws.customer.local, the same PHZ is associated with VPC in us-west-2 region. While VPCs are regional, the PHZ is a global construct. The same PHZ is accessible from VPCs in different regions.Failover routing policy is set up in the PHZ and failover records are created. However, Route 53 health checkers (being outside of the VPC) require a public IP for your applications. As these business applications are internal to the organization, a metric-based health check withAmazon CloudWatchcan be configured as mentioned inConfiguring failover in a private hosted zone.Resolver endpoints are created in VPC in another region (us-west-2) in the networking account. This allows on-premises servers to failover to these secondary Resolver inbound endpoints in case the region goes down.A second set of forwarding rules is created in the networking account, which uses the outbound endpoint in us-west-2. These are shared with Account A and then associated with VPC in us-west-2.In addition, to have DR across multiple on-premises locations, the on-premises servers should have a secondary backup DNS on-premises as well (not shown in the diagram).This ensures a simple DNS architecture for the DR setup, and seamless failover for applications in case of a region failure.ConsiderationsIf Application 1 needs to communicate to Application 2, then the PHZ from Account A must be shared with Account B. DNS queries can then be routed efficiently for those VPCs in different accounts.Create additional IP addresses in a single AZ/subnet for the resolver endpoints, to handle large volumes of DNS traffic.Look atConsiderations while using Private Hosted Zonesbefore implementing such architectures in your AWS environment.SummaryHybrid cloud environments can utilize the features of Route 53 Private Hosted Zones such as overlapping namespaces and the ability to perform cross-account and multi-region VPC association. This creates a unified DNS view for your application environments. The architecture allows for scalability and high availability for business applications.TAGS:Architecture,Disaster recovery,DR,PHZ,Private Hosted Zones,resolver endpoints,Route 53Anandprasanna GaitondeAs an AWS Solutions Architect, Anandprasanna Gaitonde is responsible for helping customers design and operate Well-Architected solutions to help them adopt AWS cloud successfully. He focuses on AWS Networking & 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 in Computer Science and post-graduation degree in Software Enterprise Management.John BickleJohn Bickle is a Senior Technical Account Manager and Enterprise Support Lead based in Montreal, Canada. John loves working closely with customers to achieve operational excellence, reduce complexity and eliminate downtime. In his spare time, John enjoys music, sailing and photography.
This post was co-written by Anandprasanna Gaitonde, AWS Solutions Architect and John Bickle, Senior Technical Account Manager, AWS Enterprise Support Introduction Many AWS customers have internal business applications spread over multiple AWS accounts and on-premises to support different business units. In such environments, you may find a consistent view of DNS records and domain names […]
Anandprasanna Gaitonde
Amazon CloudWatch Amazon Route 53 Amazon VPC Architecture AWS Control Tower AWS Direct Connect Resource Access Manager (RAM)