Leveraging VPC Endpoints
AWS offers a highly available and scalable technology called AWS PrivateLink. AWS PrivateLink enables you to privately connect any of your VPCs either to the supported AWS services or to VPC endpoint services (that is, services powered by AWS PrivateLink that are hosted in other AWS accounts, whether by you or by a third party). For example, many of the services that AWS partners offer on AWS Marketplace support AWS PrivateLink nowadays.
Using AWS PrivateLink, you can then avoid exposing the traffic between your VPC and the target service on AWS to the internet; the E2E communication does not leave the AWS network.
Now, how does this work?
To use AWS PrivateLink, you simply create a VPC endpoint that will serve as an entry point to reach the destination service. This is illustrated in Figure 2.12:
Figure 2.12: VPC endpoint
As illustrated in the preceding diagram, a VPC endpoint does not require a public IP address, an internet gateway, a peering link, a VPN, or a DX connection to be able to reach the destination service using AWS PrivateLink. The traffic always stays within the boundaries of the AWS network.
VPC endpoints are highly available and scalable virtual devices that you create in your AWS environment. There are currently three types of endpoints, as outlined here:
- Interface endpoints
- Gateway Load Balancer (GWLB) endpoints
- Gateway endpoints
The following sections discuss each of these in detail.
Interface Endpoints
Interface endpoints, powered by AWS PrivateLink, are entry points for the traffic targeting a supported AWS service or a VPC endpoint service.
Concretely, an interface endpoint consists of an Elastic Network Interface (ENI) with a private IP address taken from the address range associated with the subnet in which it is created.
It is recommended to enable the private Domain Name System (DNS) (which is the default option) when you create an interface endpoint as this will make it easier to reach out to the supported service. Specifically, it will allow you to make use of the default DNS name of the service and still go through the interface endpoint leveraging private connectivity. Doing so avoids your applications from becoming aware of and having to use the endpoint-specific DNS name; instead, they can keep using the default (public) DNS name of the supported service. The following diagram illustrates this:
Figure 2.13: VPC interface endpoints and DNS names
You can enforce security best practices with interface endpoints in several ways.
First, you can associate security groups with interface endpoints and control which resources can use your endpoints. Secondly, you can associate IAM resource-based policies—called endpoint policies—with your interface endpoints to control which principals (users or roles) under certain conditions are allowed to use the endpoint.
Furthermore, interface endpoints can also be used in a hybrid cloud scenario where they can be accessed from your on-premises environment. The following current limitations are worth noting:
- An interface endpoint can only be created in one subnet per Availability Zone (AZ).
- Not all AWS services support interface endpoints: the list keeps growing on a regular basis, but it is recommended to check the AWS documentation for the latest update.
An interface endpoint is the principal type of VPC endpoint you will come across but, as previously mentioned, it is not the only one. The following sections present the other two types, starting with the latest and newest sort—GWLB endpoints.
GWLB Endpoints
GWLB endpoints are a new type of endpoint, recently added following the introduction of the GWLB service. GWLB provides inline traffic analysis for when you want to use specific virtual appliances for security inspection on AWS.
GWLB endpoints, powered by AWS PrivateLink, provide private connectivity to your gateway load balancers. A GWLB endpoint effectively consists of an ENI with a private IP address taken from the address range associated with the subnet in which it is created. To make use of this type of endpoint, you need to make sure to add the necessary routes in your subnet and gateway route tables to direct the traffic through the GWLB endpoint.
See an example of this in Figure 2.14:
Figure 2.14: GWLB endpoint
The current limitation worth noting is that, at the time of this writing, this type of endpoint does not support endpoint policies and security groups.
Gateway Endpoints
A gateway endpoint is the first type of endpoint that launched on AWS, and it has been supporting connectivity to only two AWS services ever since: Amazon S3 and Amazon DynamoDB.
A gateway endpoint is a routable object that you must add to your VPC or subnet route table to be able to leverage it, like an internet or NAT gateway on AWS. On top of that, you can specify custom access permissions for your gateway endpoint by attaching endpoint policies to it.
See an example of this Figure 2.15:
Figure 2.15: VPC gateway endpoint
You can attach several AWS gateway endpoints to any VPC. You will separate gateway endpoints, one for each service (S3 or DynamoDB) that you want to access, and then if you require different access permissions for different groups of resources, you may even have different gateway endpoints for the same service within the same VPC. If you use multiple endpoints for the same service in the one VPC, you will need to set different routes to use each of these endpoints in different route tables (for each service, you can only have a single route in every route table).
The following current limitations are worth noting:
- Cross-region is not supported. Gateway endpoints can only be used to reach out to AWS services in the same region as the VPC where they are set.
- Endpoint connections do not extend beyond the boundaries of a VPC. You cannot leverage the gateway endpoint defined in your VPC to access a service behind
- that endpoint from another VPC or from your on-premises environment, whichever network topology you may have (VPC peering, Transit Gateway, VPN, DX, and so on).
Before moving on to the next section, consider the two key aspects: resiliency and cost.
Additional Considerations
There are a few attention points when using private endpoints. You want to be mindful of resiliency and cost aspects.
AZs
Services offered by third-party providers, whether in your own organization or beyond, may not always be available in each AZ within a given AWS region.
An interface endpoint is mapped to an AZ upon creation. Therefore, it is important, especially for third-party services, to validate in which AZs they are available and to use AZ identifiers (IDs) to identify AZs uniquely and consistently across accounts. Remember the difference between the following:
- An AZ name (for example, eu-west-1a) that does not necessarily map to the same AZ in two different AWS accounts
- An AZ ID (for example, euw1-az1) that always refers to the same AZ across all AWS accounts
So first, you must use AZ IDs to make sure that you deploy endpoints in the right AZs where the service is also available. Secondly, it is recommended as a best practice to always deploy endpoints in at least two AZs for HA purposes.
Pricing
Gateway endpoints are provided at no charge, other than the cost generated for using the service and transferring data.
Endpoints powered by AWS PrivateLink—that is, interface endpoints and GWLB endpoints—are priced against two dimensions: the time the endpoint exists (per hour, for each AZ where the endpoint is deployed) and the amount of data that goes through it (per GB).
For enterprises, it becomes cost-efficient to centralize interface endpoints—for example, in a VPC within a central shared services or network services account—and to share them within the rest of the organization. This allows not just better control over connectivity aspects, but by avoiding duplicated interface endpoints (times the number of VPCs in use), you are able to save on costs as well, especially if the number of accounts in your organization grows significantly over time.
You are now ready to investigate yet another service that can help you optimize your organization’s network infrastructure, AWS Transit Gateway.
