Privately access a central AWS service endpoint from multiple VPCs

Created by Martin Guenthner (AWS) and Samuel Gordon (AWS)

Code repository: VPC Endpoint Sharing	Environment: Production	Technologies: Networking; Infrastructure
AWS services: AWS RAM; Amazon Route 53; Amazon SNS; AWS Transit Gateway; Amazon VPC

Summary

Security and compliance requirements for your environment might specify that traffic to Amazon Web Services (AWS) services or endpoints must not traverse the public internet. This pattern is a solution that is designed for a hub-and-spoke topology, where a central hub VPC is connected to multiple, distributed spoke VPCs. In this solution, you use AWS PrivateLink to create an interface VPC endpoint for the AWS service in the hub account. Then, you use transit gateways and a distributed Domain Name System (DNS) rule to resolve requests to the private IP address of the endpoint, across the connected VPCs.

This pattern describes how to use AWS Transit Gateway, an inbound Amazon Route 53 Resolver endpoint, and a shared Route 53 forwarding rule in order to resolve the DNS queries from the resources in connected VPCs. You create the endpoint, transit gateway, Resolver, and forwarding rule in the hub account. Then, you use AWS Resource Access Manager (AWS RAM) to share the transit gateway and the forwarding rule with the spoke VPCs. The AWS CloudFormation templates provided help you deploy and configure the resources in the hub VPC and spoke VPCs.

Prerequisites and limitations

Prerequisites

• A hub account and one or more spoke accounts, managed in the same organization in AWS Organizations. For more information, see Creating and managing an organization.

• AWS Resource Access Manager (AWS RAM) is configured as a trusted service in AWS Organizations. For more information, see Using AWS Organizations with other AWS services.

• DNS resolution must be enabled in the hub and spoke VPCs. For more information, see DNS attributes for your VPC (Amazon Virtual Private Cloud documentation).

Limitations

• This pattern connects hub and spoke accounts in the same AWS Region. For multi-Region deployments, you must repeat this pattern for each Region.

• The AWS service must integrate with PrivateLink as an interface VPC endpoint. For a complete list, see AWS services that integrate with AWS PrivateLink (PrivateLink documentation).

• Availability Zone affinity is not guaranteed. For example, queries from Availability Zone A might respond with an IP address from Availability Zone B.

• The elastic network interface associated to the VPC endpoint has a limit of 10,000 queries per second.

Architecture

Target technology stack

• A hub VPC in the hub AWS account

• One or more spoke VPCs in a spoke AWS account

• One or more interface VPC endpoints in the hub account

• Inbound and outbound Route 53 Resolvers in the hub account

• A Route 53 Resolver forwarding rule deployed in the hub account and shared with the spoke account

• A transit gateway deployed in the hub account and shared with the spoke account

• AWS Transit Gateway connecting the hub and spoke VPCs

Target architecture

The following image shows a sample architecture for this solution. In this architecture, the Route 53 Resolver forwarding rule in the hub account has the following relationship with the other architecture components:

1. The forwarding rule is shared with the spoke VPC by using AWS RAM.

2. The forwarding rule is associated with the outbound Resolver in the hub VPC.

3. The forwarding rule targets the inbound Resolver in the hub VPC.

The following image shows the flow of traffic through the sample architecture:

1. A resource, such as an Amazon Elastic Compute Cloud (Amazon EC2) instance, in the spoke VPC makes a DNS request to <service>.<region>.amazonaws.com. The request is received by the spoke Amazon DNS Resolver.

2. The Route 53 forwarding rule, which is shared from the hub account and associated to the spoke VPC, intercepts the request.

3. In the hub VPC, the outbound Resolver uses the forwarding rule to forward the request to the inbound Resolver.

4. The inbound Resolver uses the hub VPC Amazon DNS Resolver to resolve the IP address for <service>.<region>.amazonaws.com to the private IP address of a VPC endpoint. If no VPC endpoint is present, it resolves to the public IP address.

Tools

AWS tools and services

• AWS CloudFormation helps you set up AWS resources, provision them quickly and consistently, and manage them throughout their lifecycle across AWS accounts and Regions.

• Amazon Elastic Compute Cloud (Amazon EC2) provides scalable computing capacity in the AWS Cloud. You can launch as many virtual servers as you need, and quickly scale them up or down.

• AWS Identity and Access Management (IAM) helps you securely manage access to your AWS resources by controlling who is authenticated and authorized to use them.

• AWS Resource Access Manager (AWS RAM) helps you securely share your resources across AWS accounts to reduce operational overhead and provide visibility and auditability.

• Amazon Route 53 is a highly available and scalable Domain Name System (DNS) web service.

• AWS Systems Manager helps you manage your applications and infrastructure running in the AWS Cloud. It simplifies application and resource management, shortens the time to detect and resolve operational problems, and helps you manage your AWS resources securely at scale.

• AWS Transit Gateway is a central hub that connects VPCs and on-premises networks.

• Amazon Virtual Private Cloud (Amazon VPC) helps you launch AWS resources into a virtual network that you’ve defined. This virtual network resembles a traditional network that you’d operate in your own data center, with the benefits of using the scalable infrastructure of AWS.

Other tools and services

• nslookup is a command-line tool used to query DNS records. In this pattern, you use this tool to test the solution.

Code repository

The code for this pattern is available on GitHub, in the vpc-endpoint-sharing repository. This pattern provides two AWS CloudFormation templates:

• A template for deploying the following resources in the hub account:

  • rSecurityGroupEndpoints – The security group that controls access to the VPC endpoint.

  • rSecurityGroupResolvers – The security group that controls access to the Route 53 Resolver.

  • rKMSEndpoint, rSSMMessagesEndpoint, rSSMEndpoint, and rEC2MessagesEndpoint – Example interface VPC endpoints in the hub account. Customize these endpoints for your use case.

  • rInboundResolver – A Route 53 Resolver that resolves DNS queries against the hub Amazon DNS Resolver.

  • rOutboundResolver – An outbound Route 53 Resolver that forwards queries to the inbound Resolver.

  • rAWSApiResolverRule – The Route 53 Resolver forwarding rule that is shared with all spoke VPCs.

  • rRamShareAWSResolverRule – The AWS RAM share that allows the spoke VPCs to use the rAWSApiResolverRule forwarding rule.

  • *rVPC – The hub VPC, used to model the shared services.

  • *rSubnet1 – A private subnet used to house the hub resources.

  • *rRouteTable1 – The route table for the hub VPC.

  • *rRouteTableAssociation1 – For the rRouteTable1 route table in the hub VPC, the association for the private subnet.

  • *rRouteSpoke – The route from the hub VPC to the spoke VPC.

  • *rTgw – The transit gateway that is shared with all spoke VPCs.

  • *rTgwAttach – The attachment that allows the hub VPC to route traffic to the rTgw transit gateway.

  • *rTgwShare – The AWS RAM share that allows the spoke accounts to use the rTgw transit gateway.

• A template for deploying the following resources in the spoke accounts:

  • rAWSApiResolverRuleAssociation – An association that allows the spoke VPC to use the shared forwarding rule in the hub account.

  • *rVPC – The spoke VPC.

  • *rSubnet1, rSubnet2, rSubnet3 – A subnet for each Availability Zone, used to house the spoke private resources.

  • *rTgwAttach – The attachment that allows the spoke VPC to route traffic to the rTgw transit gateway.

  • *rRouteTable1 – The route table for the spoke VPC.

  • *rRouteEndpoints – The route from the resources in the spoke VPC to the transit gateway.

  • *rRouteTableAssociation1/2/3 – For the rRouteTable1 route table in the spoke VPC, the associations for the private subnets.

  • *rInstanceRole – The IAM role used to test the solution.

  • *rInstancePolicy – The IAM policy used to test the solution.

  • *rInstanceSg – The security group used to test the solution.

  • *rInstanceProfile – The IAM instance profile used to test the solution.

  • *rInstance – An EC2 instance preconfigured for access through AWS Systems Manager. Use this instance to test the solution.

* These resources support the sample architecture and might not be required when implementing this pattern in an existing landing zone.

Epics

Prepare the CloudFormation templates

Task	Description	Skills required
Clone the code repository.	In a command-line interface, change your working directory to the location where you want to store the sample files. Enter the following command: git clone https://github.com/aws-samples/vpc-endpoint-sharing.git	Network administrator, Cloud architect
Modify the templates.	In the cloned repository, open the hub.yml and spoke.yml files. Review the resources created by these templates and adjust the templates as needed for your environment. For a complete list, see the Code repository section in Tools. If your accounts already have some of these resources, remove them from the CloudFormation template. For more information, see Working with templates (CloudFormation documentation). Save and close the hub.yml and spoke.yml files.	Network administrator, Cloud architect

Deploy the resources in the target accounts

Task	Description	Skills required
Deploy the hub resources.	Using the hub.yml template, create a CloudFormation stack. When prompted, provide values for the parameters in the template. For more information, see Creating a stack (CloudFormation documentation).	Cloud architect, Network administrator
Deploy the spoke resources.	Using the spoke.yml template, create a CloudFormation stack. When prompted, provide values for the parameters in the template. For more information, see Creating a stack (CloudFormation documentation).	Cloud architect, Network administrator

Test the solution

Task	Description	Skills required
Test private DNS queries to the AWS service.	Connect to the rInstance EC2 instance by using Session Manager, a capability of AWS Systems Manager. For more information, see Connect to your Linux instance using Session Manager (Amazon EC2 documentation). For an AWS service that has a VPC endpoint in the hub account, use nslookup to confirm that the private IP addresses for the inbound Route 53 Resolver are returned. The following is an example of using nslookup to reach an Amazon Systems Manager endpoint. nslookup ssm.<region>.amazonaws.com In the AWS Command Line Interface (AWS CLI), enter a command that can help you confirm that the changes did not affect the service functionality. For a list of commands, see AWS CLI Command Reference. For example, the following command should return a list of Amazon Systems Manager documents. aws ssm list-documents	Network administrator
Test public DNS queries to an AWS service.	For an AWS service that does not have a VPC endpoint in the hub account, use nslookup to confirm that the public IP addresses are returned. The following is an example of using nslookup to reach an Amazon Simple Notification Service (Amazon SNS) endpoint. nslookup sns.<region>.amazonaws.com In the AWS CLI, enter a command that can help you confirm that the changes did not affect the service functionality. For a list of commands, see AWS CLI Command Reference. For example, if any Amazon SNS topics are present in the hub account, the following command should return a list of topics. aws sns list-topics	Network administrator

Related resources

• Building a scalable and secure multi VPC AWS Network Infrastructure (AWS whitepaper)

• Working with shared resources (AWS RAM documentation)

• Working with transit gateways (AWS Transit Gateway documentation)