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. 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. Two types of endpoints can currently be provisioned: Interface Endpoints (powered by AWS PrivateLink) and Gateway Endpoints. Gateway endpoints are free to provision, and there is not a strong use case for centralization.

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. By default, you create an interface endpoint in every VPC from which you want to access the AWS service. This can be expensive and difficult 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 one centralized VPC. All the spoke VPCs will use these centralized endpoints.

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. Alternatively, you can manually create a Route 53 PHZ and add Alias record with the full AWS service endpoint name pointing to the interface endpoint as shown in Figure 18.

Figure 18 – Manually created PHZ

We 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.

Note

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 Figure 19, 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.

Note: 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).

Figure 19 – Centralizing interface VPC endpoints