Deploy consistent DNS with AWS Service Catalog and AWS Control Tower customizations
AWS Architecture BlogDeploy consistent DNS with AWS Service Catalog and AWS Control Tower customizationsby Shiva Vaidyanathan and Pratik Jain | on03 MAR 2022| inAmazon Route 53,Amazon Simple Notification Service (SNS),Amazon VPC,Architecture,AWS Control Tower,AWS Service Catalog,Resource Access Manager (RAM)|Permalink|ShareMany organizations need to connect their on-premises data centers, remote sites, and cloud resources. A hybrid connectivity approach connects these different environments. Customers with a hybrid connectivity network need additional infrastructure and configuration for private DNS resolution to work consistently across the network. It is a challenge to build this type of DNS infrastructure for a multi-account environment. However, there are several options available to address this problem with AWS.Automating DNS infrastructure using Route 53 Resolver endpointscovers how to useResolver endpointsorprivate hosted zonesto manage your DNS infrastructure.This blog provides another perspective on how to manage DNS infrastructure withCustomizations for Control TowerandAWS Service Catalog.Service Catalog PortfoliosandproductsuseAWS CloudFormationto abstract the complexity and provide standardized deployments. The solution enables you to quickly deploy DNS infrastructure compliant with standard practices and baseline configuration.Control Tower Customizations with Service Catalog solution overviewThe solution uses theCustomizations for Control Towerframework and AWS Service Catalog to provision the DNS resources across a multi-account setup. The Service Catalog Portfolio created by the solution consists of threeAmazon Route 53products: Outbound DNS product, Inbound DNS product, and Private DNS. Sharing this portfolio with the organization makes the products available to both existing and future accounts in your organization. Users who are given access to AWS Service Catalog can choose to provision these three Route 53 products in a self-service or a programmatic manner.Outbound DNS product.This solution creates inbound and outbound Route 53 resolver endpoints in a Networking Hub account. Deploying the solution creates a set of Route 53 resolver rules in the same account. These resolver rules are then shared with the organization viaAWS Resource Access Manager (RAM).Amazon VPCs in spoke accounts are then associated with the shared resolver rules by the Service Catalog Outbound DNS product.Inbound DNS product.A private hosted zone is created in the Networking Hub account to provide on-premises resolution of Amazon VPC IP addresses. A DNS forwarder for the cloud namespace is required to be configured by the customer for the on-premises DNS servers. This must point to the IP addresses of the Route 53 Inbound Resolver endpoints. Appropriate resource records (such as a CNAME record to a spoke account resource like anElastic Load Balanceror a private hosted zone) are added. Once this has been done, the spoke accounts can launch the Inbound DNS Service Catalog product. This activates anAWS Lambdafunction in the hub account to authorize the spoke VPC to be associated to the Hub account private hosted zone. This should permit a client from on-premises to resolve the IP address of resources in your VPCs in AWS.Private DNS product.For private hosted zones in the spoke accounts, the corresponding Service Catalog product enables each spoke account to deploy a private hosted zone. The DNS name is a subdomain of the parent domain for your organization. For example, if the parent domain iscloud.example.com, one of the spoke account domains could be calledspoke3.cloud.example.com. The product uses the local VPC ID (spoke account) and the Network Hub VPC ID. It also uses the Region for the Network Hub VPC that is associated to this private hosted zone. You provide the ARN of theAmazon SNStopic from the Networking Hub account. This creates an association of the Hub VPC to the newly created private hosted zone, which allows the spoke account to notify the Networking Hub account.The notification from the spoke account is performed via a custom resource that is a part of the private hosted zone product. Processing of the notification in the Networking Hub account to create the VPC association is performed by a Lambda function in the Networking Hub account. We also record each authorization-association withinAmazon DynamoDBtables in the Networking Hub account. One table is mapping the account ID with private hosted zone IDs and domain name, and the second table is mapping hosted zone IDs with VPC IDs.The following diagram (Figure 1) shows the solution architecture:Figure 1. A Service Catalog based DNS architecture setup with Route 53 Outbound DNS product, Inbound DNS product, and Route 53 Private DNS productPrerequisitesNetwork connectivity between the Network Hub VPC and the on-premises DNS servers is in place. Connectivity can be eitherVPNorAWS Direct Connect.The VPC attributeenableDNShostnamesis set to true.TheCustomizations for Control Tower solutionis deployed in the management account.Resource sharingwith AWS Organizations is turned on.AWS Service Catalog delegated administratoris configured.Deployment stepsThe deployment of this solution has two phases:Deploy the Route 53 package to the existing Customizations for Control Tower (CfCT) solution in the management account.Setup user access, and provision Route 53 products using AWS Service Catalog in spoke accounts.All the code used in this solution can be found in theGitHubrepository.Phase 1: Deploy the Route 53 package to the existing Customizations for Control Tower solution in the management accountLog in to theAWS Management Consoleof the management account. Select the Region where you want to deploy the landing zone. Deploy theCustomizations for Control Tower (CfCT) Solution.1. Clone your CfCTAWS CodeCommitrepository:UsingHTTPS connectionvia GitUsingAWS Cloud92. Create a directory in the root of your CfCT CodeCommit repo calledroute53. Create a subdirectory calledtemplatesand copy theRoute53-DNS-Service-Catalog-Hub-Account.ymltemplate and theRoute53-DNS-Service-Catalog-Spoke-Account.ymlunder thetemplatesfolder.3. Edit the parameters present in fileRoute53-DNS-Service-Catalog-Hub-Account.jsonwith value appropriate to your environment.4. Create a S3 bucket leveragings3Bucket.ymltemplate and customizations.5. Upload the three product template files (OutboundDNSProduct.yml,InboundDNSProduct.yml,PrivateDNSProduct.yml) to the s3 bucket created in step 4.6. Under the sameroute53directory, create another sub-directory calledparameters. Place the updated parameter json file from previous step under this folder.7. Edit the manifest.yaml file in the root of your CfCT CodeCommit repository to include the Route 53 resource,manifest.ymlis provided as a reference. Update the Region values in this example to the Region of your Control Tower. Also update the deployment target account name to the equivalent Networking Hub account within your AWS Organization.8. Create andpush a commitfor the changes made to the CfCT solution to your CodeCommit repository.9. Finally, navigate toAWS CodePipelinein the AWS Management Console to monitor the progress. Validate the deployment of resources via CloudFormation StackSets is complete to the target Networking Hub account.Phase 2: Setup user access, and provision Route 53 products using AWS Service Catalog in spoke accountsIn this section, we walk through how users can vend products from the shared AWS Service Catalog Portfolio using a self-service model. The following steps will walk you through setting up user access and provision products:1. Sign in to AWS Management Console of the spoke account in which you want to deploy the Route 53 product.2. Navigate to the AWS Service Catalog service, and choose Portfolios.3. On the Imported tab, choose your portfolio as shown in Figure 2.Figure 2. Imported DNS portfolio (spoke account)4. Choose the Groups, roles, and users pane and add the IAM role, user, or group that you want to use to launch the product.5. In the left navigation pane, choose Products as shown in Figure 3.6. On the Products page, choose either of the three products, and then choose Launch Product.Figure 3. DNS portfolio products (Inbound DNS, Outbound DNS, and Private DNS products)7. On the Launch Product page, enter a name for your provisioned product, and provide the product parameters:Outbound DNS product:ChildDomainNameResolverRuleId: Rule ID for the Shared Route 53 Resolver rule for child domains.OnPremDomainResolverRuleID: Rule ID for the Shared Route 53 Resolver rule for on-premises DNS domain.LocalVPCID: Enter the VPC ID, which the Route 53 Resolver rules are to be associated with (for example:vpc-12345).Inbound DNS product:NetworkingHubPrivateHostedZoneDomain: Domain of the private hosted zone in the hub account.LocalVPCID: Enter the ID of the VPC from the account and Region where you are provisioning this product (for example:vpc-12345).SNSAuthorizationTopicArn: Enter ARN of the SNS topic belonging to the Networking Hub account.Private DNS product:DomainName: the FQDN for the private hosted zone (for example:account1.parent.internal.com).LocalVPCId: Enter the ID of the VPC from the account and Region where you are provisioning this product.AdditionalVPCIds: Enter the ID of the VPC from the Network Hub account that you want to associate to your private hosted zone.AdditionalAccountIds: Provide the account IDs of the VPCs mentioned in AdditionalVPCIds.NetworkingHubAccountId: Account ID of the Networking Hub accountSNSAssociationTopicArn: Enter ARN of the SNS topic belonging to the Networking Hub account.8. Select Next and Launch Product.Validation of Control Tower Customizations with Service Catalog solutionFor the Outbound DNS product:Validate the successful DNS infrastructure provisioning. To do this, navigate to Route 53 service in the AWS Management Console. Under the Rules section, select the rule you provided when provisioning the product.Under that Rule, confirm that spoke VPC is associated to this rule.For further validation, launch anAmazon EC2instance in one of the spoke accounts.  Resolve the DNS name of a record present in the on-premises DNS domain using thedig utility.For the Inbound DNS product:In the Networking Hub account, navigate to the Route 53 service in the AWS Management Console. Select the private hosted zone created here for inbound access from on-premises. Verify the presence of resource records and the VPCs to ensure spoke account VPCs are associated.For further validation, from a client on-premises, resolve the DNS name of one of your AWS specific domains, using thedig utility, for example.For the Route 53 private hosted zone (Private DNS) product:Navigate to the hosted zone in the Route 53 AWS Management Console.Expand the details of this hosted zone. You should see the VPCs (VPC IDs that were provided as inputs) associated during product provisioning.For further validation, create a DNS A record in the Route 53 private hosted zone of one of the spoke accounts.Spin up an EC2 instance in the VPC of another spoke account.Resolve the DNS name of the record created in the previous step using thedig utility.Additionally, the details of each VPC and private hosted zone association is maintained within DynamoDB tables in the Networking Hub accountCleanup stepsAll the resources deployed through CloudFormation templates should be deleted after successful testing and validation to avoid any unwanted costs.Remove the changes made to the CfCT repo to remove the references to the Route 53 folder in the manifest.yaml and the route53 folder. Then commit and push the changes to prevent future re-deployment.Go to the CloudFormation console, identify the stacks appropriately, and delete them.In spoke accounts, you can shut down the provisioned AWS Service Catalog product(s), which would terminate the corresponding CloudFormation stacks on your behalf.Note:In a multi account setup, you must navigate through account boundaries and follow the previous steps where products were deployed.ConclusionIn this post, we showed you how to create a portfolio using AWS Service Catalog. It contains a Route 53 Outbound DNS product, an Inbound DNS product, and a Private DNS product. We described how you can share this portfolio with your AWS Organization. Using this solution, you can provision Route 53 infrastructure in a programmatic, repeatable manner to standardize your DNS infrastructure.We hope that you’ve found this post informative and we look forward to hearing how you use this feature!Shiva VaidyanathanShiva Vaidyanathan is a Senior Cloud Infrastructure Architect at AWS. He provides technical guidance, design, and leads customer implementation projects. He works to make cloud networking simpler for everyone. Prior to joining AWS, he worked on several NSF funded research initiatives on how to secure computing in public cloud infrastructures. He holds a MS in Computer Science from Rutgers University, and a MS in Electrical Engineering from New York University.Pratik JainPratik is a Senior Cloud Infrastructure Architect at AWS. He has expertise in Serverless and Automation, and is passionate about making the cloud journey seamless for AWS customers. Outside of work, he enjoys traveling and exploring cafes in various cities.
Many organizations need to connect their on-premises data centers, remote sites, and cloud resources. A hybrid connectivity approach connects these different environments. Customers with a hybrid connectivity network need additional infrastructure and configuration for private DNS resolution to work consistently across the network. It is a challenge to build this type of DNS infrastructure for […]
Shiva Vaidyanathan
Amazon Route 53 Amazon Simple Notification Service (SNS) Amazon VPC Architecture AWS Control Tower AWS Service Catalog Resource Access Manager (RAM)