Centralized access to VPC private endpoints - Building a Scalable and Secure Multi-VPC AWS Network Infrastructure

Centralized access to VPC private endpoints

A VPC endpoint allows you to privately connect your VPC to supported AWS services without requiring an internet gateway or a NAT device, VPN connection, or AWS Direct Connect connection. Therefore, your VPC is not exposed to the public internet. Instances in your VPC do not require public IP addresses to communicate with AWS service endpoints with this interface endpoint. Traffic between your VPC and other services does not leave the AWS network backbone. VPC endpoints are virtual devices. They are horizontally scaled, redundant, and highly available VPC components. Two types of endpoints can currently be provisioned: interface endpoints (powered by AWS PrivateLink) and gateway endpoints. Gateway endpoints can be utilized to access Amazon S3 and Amazon DynamoDB services privately. There is no additional charge for using gateway endpoints. Standard charges for data transfer and resource usage apply.

Interface VPC endpoints

An interface endpoint consists of one or more elastic network interfaces with a private IP address that serves as an entry point for traffic destined to a supported AWS service. When you provision an interface endpoint, a cost is incurred by users for every hour the endpoint is running along with data processing charges. By default, you create an interface endpoint in every VPC from which you want to access the AWS service. This can be cost prohibitive and challenging to manage in the Landing Zone setup where a customer wants to interact with a specific AWS service across multiple VPCs. To avoid this, you can host the interface endpoints in a centralized VPC. All the spoke VPCs will use these centralized endpoints via Transit Gateway.

When you create a VPC endpoint to an AWS service, you can enable private DNS. When enabled, the setting creates an AWS managed Route 53 private hosted zone (PHZ) which enables the resolution of public AWS service endpoint to the private IP of the interface endpoint. The managed PHZ only works within the VPC with the interface endpoint. In our setup, when we want spoke VPCs to be able to resolve VPC endpoint DNS hosted in a centralized VPC, the managed PHZ won’t work. To overcome this, disable the option that automatically creates the private DNS when an interface endpoint is created. Next, manually create a Route 53 PHZ and add an Alias record with the full AWS service endpoint name pointing to the interface endpoint, as shown in the following figure.

        A diagram depicting a manually created PHZ

Manually created PHZ

You associate this private hosted zone with other VPCs within the Landing Zone. This configuration allows the spoke VPCs to resolve the full-service endpoint names to interface endpoints in the centralized VPC.


To access the shared private hosted zone, the hosts in the spoke VPCs should use the Route 53 Resolver IP of their VPC. Interface endpoints are also accessible from on-premises networks over VPN and Direct Connect. Use conditional forwarding rules to send all DNS traffic for the full-service endpoint names to Route 53 Resolver inbound endpoints, which will resolve DNS requests according to the private hosted zone.

In the following figure, Transit Gateway enables traffic flow from the spoke VPCs to the centralized interface endpoints. Create VPC Endpoints and the private hosted zone for it in Network Services Account and share it with spoke VPCs in the spoke accounts. For more details on sharing endpoint information with other VPCs, refer to the Integrating AWS Transit Gateway with AWS PrivateLink and Amazon Route 53 Resolver blog post.


A distributed VPC endpoint approach that is, an endpoint per VPC allows you to apply least privilege policies on VPC endpoints. In a centralized approach, you will apply and manage policies for all spoke VPC access on a single endpoint. With growing number of VPCs, the complexity of maintaining least privilege with a single policy document might grow. Single policy document also results in larger blast radius. You are also restricted on the size of the policy document (20,480 characters).

        A diagram depicting centralizing interface VPC endpoints

Centralizing interface VPC endpoints

Cross region endpoint access

When you want multiple VPCs set up in different regions that share a common VPC endpoint, use a PHZ, as outlined earlier. Both VPCs in each region will be associated with the PHZ with the alias to the endpoint. In order to route traffic between VPCs in a multi-region architecture, the Transit Gateways in each region need to be peered together. For more information, refer to this blog: Using Route 53 Private Hosted Zones for Cross-account Multi-region Architectures.

VPCs from different regions can be routed to one another using either Transit Gateways or VPC Peering. Use the following documentation for peering Transit Gateways: Transit gateway peering attachments.

The EC2 instance in the VPC us-east-1 region will use the PHZ to get the private IP address of the endpoint in the us-west-2 region and route the traffic to the us-west-2 region VPC over the Transit Gateway peering or VPC peering. Using this architecture, the traffic remains within the AWS network, securely allowing the EC2 instance in us-east-1 to access the VPC service in us-west-2 without going over the internet.

        A diagram depicting multi-region VPC endpoints

Multi-region VPC Endpoints


Inter-region data transfer charges do apply when accessing endpoints across regions.

Referring to the previous figure, an endpoint service is created in a VPC in the us-west-2 region. This endpoint service provides access to an AWS service in that region. In order for your instances in another region (such as us-east-1) to access the endpoint in the us-west-2 region, you need to create an address record in the PHZ with an alias to the desired VPC endpoint.

First, make sure that the VPCs in each region are associated with the PHZ that you created.

        A screenshot depicting an edit record

When deploying an endpoint in multiple AZ, the IP address of the endpoint returned from DNS will be from any of the subnets in the AZ that is allocated.

When invoking the endpoint, use the fully qualified domain name (FQDN) that is in the PHZ.