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

1. Log in to console and navigate to service Route 53.

2. Select the Private Hosted Zone and navigate to Create Record.

3. Populate the Record Name field, select Record Type as A, and enable Alias.

4. Under Route Traffic to section, select the service to which the traffic should be sent and select the region from the dropdown list.

5. Select the appropriate routing policy and ensure you enable the option to Evaluate target health.

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.

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

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

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.

In this example, the Amazon EC2 instance in the VPC us-west-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-west-1 to access the VPC service in us-west-2 without going over the internet.

Multi-Region VPC endpoints

Note

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.

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

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

AWS Verified Access

AWS Verified Access delivers secure access to applications in private network without a VPN. It evaluates requests in real time like identity, device, and location. This service grants access based on policy for applications and connecting the users by improving security of the organization. Verified Access provide access to private applications by acting as an identity aware reverse proxy. User identity and device health, if applicable, are performed before routing traffic to application.

The following diagram provides a high-level overview of Verified Access. Users send requests to access an application. Verified Access evaluates the request against the access policy for the group and any application-specific endpoint policies. If access is allowed, the request is sent to the application through the endpoint.

Verified Access overview

The main components in an AWS Verified Access architecture are:

• Verified Access instances – An instance evaluates application requests and grants access only when your security requirements are met.

• Verified Access endpoints – Each endpoint represents an application. An endpoint can be NLB, ALB or network interface.

• Verified Access group – A collection of Verified Access endpoints. We recommend that you group the endpoints for applications with similar security requirements to simplify policy administration.

• Access policies – A set of user-defined rules that determine whether to allow or deny access to an application.

• Trust providers – Verified Access is a service that facilitates the management of user identities and device security states. It is compatible with both AWS and third-party trust providers, requiring that at least one trust provider be attached to each Verified Access instance. Each of these instances can include a single identity trust provider as well as multiple device trust providers.

• Trust data – The security data that your trust provider sends to Verified Access, such as a user's email address or the group they belong to, is evaluated against your access policies each time an application request is received.

More details can be found in Verified Access blog posts.