Guidance for Amazon VPC Lattice Automated DNS Configuration on AWS

Summary: This implementation guide provides an overview of the Guidance for Amazon VPC Lattice Automated DNS Configuration on AWS, its reference architecture and components, considerations for planning the deployment, and configuration steps. This guide is intended for solution architects, business decision makers, DevOps engineers, data scientists, and cloud professionals who want to implement Guidance for Amazon VPC Lattice Automated DNS Configuration on AWS in their environment.

Overview

This guidance automates the creation of DNS resolution configuration in Amazon Route 53 when creating new Amazon VPC Lattice services with custom domain names.

Amazon VPC Lattice is an application networking service that simplifies connectivity, monitoring, and security between your services. Its main benefits are the configuration and management simplification, allowing developers to focus on building features while networking and security administrators can provide guardrails in the services’ communication. The service simplifies the onboarding experience for developers by removing the need to implement custom application code or run additional proxies next to every workload, while maintaining the tools and controls network admins require to audit and secure their environment. Amazon VPC Lattice leverages Domain Name Service (DNS) for service discovery, so each Amazon VPC Lattice service is easily identifiable through its service-managed or custom domain names (you can find more information in the section DNS configuration in VPC Lattice). However, for custom domain names, extra manual configuration is needed to allow DNS resolution for the consumer workloads.

This guidance automates configuration of DNS resolution any time a new Amazon VPC Lattice service (with a custom domain name configured) is created. You can find the deployment code in the following GitHub repository.

Features and benefits

This guidance provides the following features:

1. Seamless service discovery with VPC Lattice when using custom domain names.
   • All the DNS resolution is configured in the private hosted zone you desire.
   • Anytime an Amazon VPC Lattice service is created in any AWS account, its DNS configuration (custom and service-managed domain names) is sent to the AWS account managing the DNS configuration. These messages are processed by creating an Alias record.
2. Seamless AWS account onboarding.
   • When new accounts that create Amazon VPC Lattice services (spoke account) are needed to be onboarded (to the central account), this guidance provides an automation for the onboarding process.
   • Each Spoke account will use an Amazon SNS topic to send information to a central account Amazon SQS queue, so the onboarding automation will create the SNS subscription to the SQS queue.
3. Automation resources are built using Infrastructure-as-Code.
   • Hashicorp Terraform is used for the Guidance automated deployment.
   • Given this automation is built for multi-account environments, deployment steps are provided in the Deploy the Guidance section.

Use cases

While Amazon VPC Lattice can be used in a single Account, the most common use case is the use of the service in multi-account environments. With Amazon VPC Lattice, these are two main resources to be used: the VPC Lattice service network is the logical boundary that connects consumers and producers, and the Amazon VPC Lattice service is the independently deployable unit of software that delivers a task or function (the application). The multi-account model for Amazon VPC Lattice can vary depending your use case, and any model you use can work with the use of thiss guidance. You can find more information about the different multi-account architecture models in the following reference architecture.

This guidance supposes a centralized model in terms of the DNS resolution, as follows:

• A central Networking account owns all the DNS configuration, sharing it with the rest of the AWS accounts.
• The rest of the Spoke accounts consume this DNS configuration shared by the Networking account, so resources can resolve the services’ custom domain names to the Amazon VPC Lattice-generated domain name (the consumer services can know the service they want to consume needs to be done through Amazon VPC Lattice).

The Guidance is configured to create the DNS resolution using Route 53 Private Hosted Zones. The automation does not create any private hosted zone, nor its association to the virtual private clouds (VPCs) that need to consume the DNS configuration. For this association, we recommend the use of Route 53 Profiles.

Architecture overview

Below is the architecture diagram workflow of the Guidance for VPC Lattice automated DNS configuration on AWS.

Figure 1: Amazon VPC Lattice Automated DNS Configuration - Reference Architecture and Workflow.

The architecture workflow is divided into two parts:

• Spoke Account onboarding. This is executed only once, as the SNS topic created (sending the VPC Lattice service information to the Networking account) needs to be subscribed to the SQS queue in the Networking account.
  • (1) When a new Spoke account deploys automation resources, an Amazon EventBridge rule checks that a new Amazon Simple Notification Service (Amazon SNS) topic has been created with the proper tag.
• Creation of DNS Alias records when new VPC Lattice services are created. Anytime a new VPC Lattice service gets created in an onboarded Spoke account, its DNS information is sent to the Networking account so an Alias record can be created.
  • (2) The New SNS topic EventBridge rule in the Spoke account sends the event to the Networking account using a custom event bus to notify the creation of a new SNS topic.
  • (3)The SNS subscription AWS Lambda function is invoked to subscribe the Amazon Simple Queue Service (Amazon SQS) topic in the Networking account to the newly created SNS topic in the Spoke account.
  • (4) The New VPC Lattice service EventBridge rule checks for a proper tag in Amazon VPC Lattice.
  • (5) The VPC Lattice service info Lambda function is invoked to obtain the DNS information of Amazon VPC Lattice and publish that information to an SNS topic in the Spoke account.
  • (6) The SNS topic in the Spoke account sends the Amazon VPC Lattice DNS information to the Networking account through the Amazon SQS queue.
  • (7) Messages arriving to the Amazon SQS queue will invoke the Create/Update Alias record Lambda function.
  • (8) Unsuccessfully processed messages are stored in the Amazon SQS dead-letter queue (DLQ) for monitoring.
  • (9) The Create/Update Alias record Lambda function will create and update the corresponding alias record in the Amazon Route 53 private hosted zone.
  • (10) AWS Systems Manager and AWS Resource Access Manager (AWS RAM) are used for parameter storage and cross-account data sharing.

For an in-depth explanation on how the different resources are configured, review the guidance technical deep dive section.

AWS Services used in this Guidance

Cost

You are responsible for the cost of the AWS services used while running thiss guidance. As of August 2024, the cost of running the services in this guidance with default settings are available within AWS Free Tier, except for the use of AWS Systems Manager Advanced Paramater storage.

We recommend creating a budget through AWS Cost Explorer to help manage costs. Prices are subject to change. You can also estimate the cost for your architecture using AWS Pricing Calculator. For full details, refer to the pricing webpage for each AWS service used in this guidance or visit Pricing by AWS Service.

Estimated monthly cost breakdown - Networking account

This breakdown of the costs of the Networking account show that the highest cost of the automation implementation is the Advanced Parameter Storage resource from Systems Manager. The costs are estimated for US East 1 (Virginia) us-east-1 Region for one month.

Please review the price breakdown details in this AWS calculator.

Estimated monthly cost breakdown - Spoke accounts

The following table provides a sample cost breakdown for deploying this guidance in 1,000 different Spoke accounts which are likely to provide Amazon VPC Lattice in the future. The costs are estimated US East 1 (Virginia) us-east-1 region for one month.

Please review the price breakdown details in this AWS calculator.

Pricing by AWS Service

Below are the pricing references for each AWS service used in this guidance.

Prerequisites

Operating System

This guidance uses AWS Serverless managed services, so there’s no OS patching or management action required. The Lambda functions use Python, and all the code was tested using Python 3.12.

Third-party tools

This guidance uses HashiCorp Terraform as an infrastructure-as-code provider. You will need Terraform installed to deploy. These instructions were tested with Terraform version 1.9.3. You can install Terraform following Hashicorp documentation.

For each account deployment (under the deployment folder), you will find the following HCL config files:

• providers.tf file provides the Terraform and AWS provider version to use.
• main.tf and iam.tf provides the resources’ configuration. While main.tf holds the configuration of the different services, iam.tf holds the configuration of AWS Identity and Access Management (IAM) roles and policies.
• variables.tf defines the input each deployment requirements. The Deploy the Guidance section details the input variables required in each AWS account.

bash-3.2$ cd guidance-for-vpc-lattice-automated-dns-configuration-on-aws/deployment/networking_account
bash-3.2$ ls
README.md
main.tf
providers.tf
iam.tf
outputs.tf
variables.tf

Sample contents of variables/tf source file:

# Copyright Amazon.com, Inc. or its affiliates. All Rights Reserved.
# SPDX-License-Identifier: MIT-0

# ---------- automation/networking_account/variables.tf ----------

variable "aws_region" {
  description = "AWS Region to build the automation in the Networking AWS Account."
  type        = string
}

variable "phz_id" {
  description = "Amazon Route 53 Private Hosted Zone ID."
  type        = string
}

We use local backend configuration to store the state files. We recommend use of another backend configuration that provides you more consistent storage and versioning, for example the use of Amazon Simple Storage Service (Amazon S3) and Amazon DynamoDB.

AWS account requirements

These instructions require AWS credentials configured according to the Terraform AWS Provider documentation.

The credentials must have IAM permission to create and update resources in the account - these permissions will vary depending the account type (networking or spoke).

In addition, the Guidance assumes your accounts are part of the same AWS Organization - as IAM policies restrict cross-account actions between accounts within the same AWS Organization. For RAM share to work, you need to enable resource sharing with the Organization.

Service quotas

Make sure you have sufficient quota for each of the services implemented in this solution. For more information, see AWS service quotas.

To view the service quotas for all AWS services in the documentation without switching pages, view the information in the Service endpoints and quotas page in the PDF instead.

Deploy the Guidance

1. Networking AWS Account.
   • Variables needed: AWS Region to deploy the resources and Private Hosted ID to create the alias records.
   • Locate yourself in the network_account folder and configure the AWS credentials of your Networking account.

cd deployment/networking_account
(configure AWS credentials)
...
terraform init
terraform apply

1. Spoke AWS account. Follow this process for each Spoke account in which you are creating Amazon VPC Lattice services.
   • Variables needed: AWS Region to deploy the resources and Networking account ID.
   • Locate yourself in the spoke_account folder and configure the AWS credentials of your Spoke account.

cd deployment/spoke_account
(configure AWS credentials)
...
terraform init
terraform apply

In the sample code GitHub repository, you will find a test environment if you want to check and test an end-to-end implementation using the Guidance.

Uninstall the Guidance

1. In the Networking account, remove all the SNS subscriptions to the SQS queue and alias records created in the private hosted zone.
2. In each Spoke account that you want to offboard, delete the Guidance automation.

cd deployment/spoke_account
(configure AWS credentials)
terraform destroy

1. In the networking AWS account, delete the Guidance automation.

cd deployment/networking_account
(configure AWS credentials)
terraform destroy

Security

When you build systems on AWS infrastructure, security responsibilities are shared between you and AWS. This shared responsibility model reduces your operational burden because AWS operates, manages, and controls the components including the host operating system, the virtualization layer, and the physical security of the facilities in which the services operate. For more information about AWS security visit AWS Cloud Security.

This guidance relies on many reasonable default options and “principle of least privilege” access for all resources. Users that deploy it in production should go through all the deployed resources and ensure those defaults comply with their security requirements and policies, have adequate logging levels and alarms enabled, and protect access to publicly exposed APIs. In Amazon SQS and Amazon SNS, the resource policies are defined such that only the specified account, organization, or resource can access such resource. IAM roles are defined for Lambda to only access the corresponding resources such as EventBridge, Amazon SQS, and Amazon SNS. AWS RAM securely shares resource parameter such as SQS queue ARN and EventBridge custom event bus ARN. This limits the access to the Amazon VPC Lattice DNS resolution automation to the configuration resources and involved accounts only.

NOTE: Please note that by cloning and using third party open-source code, you assume responsibility for its patching, securing, and managing in the context of this project.

Encryption at rest

Encryption at rest is configured in the SNS topic and SQS queues, using AWS-managed keys. Systems Manager parameters are not configured as SecureString due to the fact that they must be encrypted with a customer managed key, and you must share the key separately through AWS Key Management Service (AWS KMS).

• Given its sensitivity, we are not creating any AWS KMS resource in this guidance.
• If you would like to use customer managed keys to encrypt at rest the data of all these services, you will need to change the code to configure this option in the corresponding resources:
  • SNS topic
  • SQS queue
  • Systems Manager parameter.

Technical Deep Dive

DNS configuration in VPC Lattice

When a new Amazon VPC Lattice service is created, a service-managed domain name is generated. This domain name is publicly resolvable and resolves either to an IPv4 link-local address or an IPv6 unique-local address. So, a consumer application using this service-managed domain name does not require any extra DNS configuration for the service-to-service communication (provided the VPC Lattice configuration allows connectivity). However, it’s more likely that you will use your own custom domain names.

When using custom domain names for Amazon VPC Lattice services, an alias (for Amazon Route 53 hosted zones) or CNAME (if you use another DNS solution) have to be created to map the custom domain name with the service-managed domain name. In multi-account environments, the creation of the DNS resolution configuration can create heavy operational overhead. Each Amazon VPC Lattice service created (by each developers’ team) will require a central networking team to be notified with the information about the new service created and the required DNS resolution to be configured.

Contributors

The following individuals contributed to this document:

• Maialen Loinaz Antón, Networking Solutions Architect Intern
• Pablo Sánchez Carmona, Sr Networking Specialist Solutions Architect
• Daniel Zilberman, Sr Tech Solutions Specialist Solutions Architect

Notices

Customers are responsible for making their own independent assessment of the information in this document. This document: (a) is for informational purposes only, (b) represents AWS current product offerings and practices, which are subject to change without notice, and (c) does not create any commitments or assurances from AWS and its affiliates, suppliers or licensors. AWS products or services are provided “as is” without warranties, representations, or conditions of any kind, whether express or implied. AWS responsibilities and liabilities to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers.