AWS PrivateLink, Explained

Customers implementing AWS connectivity are presented with a range of choices, including PrivateLink. So when is PrivateLink most suitable? We detail the uses and benefits of this private connectivity method.

When it comes to AWS connectivity, there is no shortage of options available to customers. Some of these are fairly common, like Virtual Gateway (VGW), Transit Gateway (TGW), VPC (virtual private cloud) Peering, and Direct Connect (DX).

Some are more recent additions and have more targeted use cases like Gateway Load Balancer (GWLB), VPC Lattice, and PrivateLink.

But what is PrivateLink, and under what circumstances is it the best choice? What are some examples of how it can be implemented, and what are the benefits?

This post will answer such AWS PrivateLink questions.

What is AWS PrivateLink, exactly?

PrivateLink is a networking construct that allows an application/service residing in one VPC (the “Service Provider VPC”) to be accessed by clients/consumers in (or through) other VPCs within the AWS Region (“Consumer VPCs”).

The consumer accesses the service privately via an interface (VPC Endpoint) deployed locally in the Consumer VPC, avoiding any requirement for internet connectivity and keeping all traffic inside AWS’s private network.

It’s also possible to access the VPC Endpoint via Direct Connect, allowing end-to-end private connectivity to applications/integrations from an enterprise LAN/WAN or data center.

Importantly, the Service Provider VPC and the consumer VPCs can be owned by different AWS accounts.

There are three main use cases for PrivateLink:

• Internal Services – you can leverage PrivateLink to easily, securely, and privately provide access to an application in one of your VPCs from clients in another VPC. PrivateLink can do this without worrying about routes, overlapping IP addresses, security groups, and firewalling.
• SaaS Services – some SaaS providers who host their workloads in AWS use PrivateLink to allow their customers to establish private secure connectivity to the application. In this case, the Service Provider VPC is owned by the SaaS provider, and the Consumer VPC belongs to the customer.
• Amazon Services – many Amazon services are available directly via PrivateLink. This allows those services to be used from a VPC without sending traffic over the internet. This can be used to establish a high-performance path for high volume services (like S3), and even to allow the use of specific AWS services from VPCs that have no internet access at all.

Benefits of AWS PrivateLink

There are several benefits to the automated, managed, private connectivity provided by PrivateLink:

• Secure traffic – network traffic using PrivateLink never traverses the public internet, reducing exposure to a range of cybersecurity threats. The ability to use private IP connectivity also means you can provide services to and from secured environments that have no internet connectivity at all. Plus, you can associate security groups and attach an endpoint policy to interface endpoints to give you precise control over who can access specified services.
• Simplified network management – you can connect services across different AWS accounts and VPCs with no need for firewall rules, route tables, the configuration of internet/NAT/private gateways, Transit Gateway, VPC peering, or VPC CIDR management/overlapping IP addresses – making for an easier user experience.
• Improved scalability – PrivateLink allows you to quickly, efficiently, and securely establish unidirectional access from many consumer VPCs to an application/service.
• Improved performance – AWS PrivateLink VPC Endpoints support 10 Gbps of throughput by default, and automatically scale up to 100 Gbps. This can allow the creation of a high-performance dedicated path to specific services.

AWS PrivateLink pricing

AWS explains on their PrivateLink pricing page that:

• Customers will be billed for each hour that their VPC endpoint remains provisioned in each Availability Zone, irrespective of the state of its association with the service.
• Such hourly billing for the VPC endpoint will stop when the customer deletes it.
• Hourly billing will also stop if the endpoint service owner rejects the customer’s VPC endpoint’s attachment to their service, and that service is subsequently deleted. Such VPC endpoints cannot be reused, and customers should delete them.
• Data processing charges apply for each gigabyte processed through the VPC endpoint, regardless of the traffic’s source or destination.
• Each partial VPC endpoint-hour consumed is billed as a full hour.

The rates you are charged will depend on the type of endpoint you use. Refer to the pricing page for more specific and current pricing details.

AWS PrivateLink vs VPC endpoints

Something that isn’t immediately obvious is the distinction between PrivateLink and VPC endpoints. In fact, part of the VPC endpoint functionality forms part of PrivateLink. VPC endpoints are resources that can be deployed into a VPC to serve as a path through which to access various services.

There are three types:

• Interface endpoint - this is the type used by PrivateLink. It is a network interface with an IP address that sits inside the VPC subnet, and requests are made either directly to this IP or more commonly to a DNS name that resolves to this IP. PrivateLink then transparently sends these requests to the backend (the service provider) and returns the response.
• Gateway endpoint - this type of endpoint attaches to the VPC in a similar fashion to an Internet Gateway (IGW) or Virtual Gateway (VGW). It doesn’t appear as an IP within your VPC, but rather as a destination/target for routes in the VPC Route Table. Traffic to the IP addresses of the destination service is routed through the gateway endpoint. This type of endpoint is only available for S3 and DynamoDB (although you can also use an Interface Endpoint for those services), and can only be used by resources in the local VPC.
• Gateway Load Balancer endpoint - this type of VPC Endpoint is used to direct network traffic to a set of network virtual appliances (eg. firewalls) which are deployed using the Gateway Load Balancer service/architecture.

AWS PrivateLink vs VPC Peering

PrivateLink and VPC Peerings both provide a way to access resources in one VPC from another VPC, however, the method and use cases are quite different.

While PrivateLink creates a local interface with a local IP which allows unidirectional access to a specific application/port, VPC Peering creates a bidirectional layer 3 connection between two VPCs.

What this means is that PrivateLink allows consumers in one VPC to access a specific app in another VPC (with no traffic in the reverse direction), whereas VPC Peering allows all resources in two VPCs to talk to each other.

VPC Peering can also connect VPCs that are in different regions, where PrivateLink cannot. However, VPC Peering can be used in combination with PrivateLink to extend PrivateLink across regions.

Key Differences:

Connectivity

• AWS PrivateLink: Provides unidirectional access from consumers in one VPC to a specific application or service in another VPC through a local interface with a local IP.
• VPC Peering: Establishes a bidirectional layer 3 connection between two VPCs, allowing all resources in both VPCs to communicate with each other.

Use Case

• AWS PrivateLink: Ideal for exposing a specific service or application to consumers in another VPC while maintaining high security and isolation.
• VPC Peering: Suitable for creating a fully-meshed network where multiple VPCs need to communicate directly with each other.

Architecture

• AWS PrivateLink: Uses interface endpoints to create a private connection to the service, simplifying the access control and security.
• VPC Peering: Requires the establishment of peering connections between each pair of VPCs, which can become complex as the number of VPCs increases.

Transitive Routing

• AWS PrivateLink: Does not support transitive routing. Traffic is confined to the endpoint connection.
• VPC Peering: Does not support transitive routing. Each VPC must be directly peered with every other VPC it needs to communicate with.

Network Connectivity

• AWS PrivateLink: Limited to the AWS region where the VPCs reside, but can be extended across regions using VPC Peering.
• VPC Peering: Supports both intra-region and inter-region connections, allowing VPCs in different regions to communicate directly.

Security

• AWS PrivateLink: Provides enhanced security by isolating traffic within the AWS network and limiting exposure to a specific application or service.
• VPC Peering: Ensures secure communication between VPCs without traversing the public internet, but exposes all resources in the peered VPCs to each other.

Complexity

• AWS PrivateLink: Easier to set up for specific service access, with simplified access control.
• VPC Peering: More complex to manage with an increasing number of VPCs due to the need for multiple peering connections.

Use Cases

Choose AWS PrivateLink if:

• You need to provide access to a specific application or service in another VPC.
• You require unidirectional access to ensure tighter security controls.
• You want to simplify the setup and management of network connections to a specific service.

Choose VPC Peering if:

• You need full bidirectional communication between two or more VPCs.
• Your architecture requires direct connectivity between all resources in the connected VPCs.
• You are connecting VPCs across different regions and need direct communication paths.

Transit Gateway vs PrivateLink

Transit Gateway (TGW) is an increasingly popular service used to create routed connections between multiple VPCs. As with VPC Peering, Transit Gateway provides full bidirectional layer 3 connectivity between VPCs – allowing full access to/from all resources in the connected VPCs.

In contrast, PrivateLink provides unidirectional access from a consumer VPC to a single service in a provider VPC.

PrivateLink can be combined with Transit Gateway to provide centralized access to a PrivateLink Endpoint from multiple VPCs.

Key Differences:

Connectivity

• Transit Gateway: Provides full bidirectional layer 3 connectivity between multiple VPCs and on-premises networks, enabling full access to and from all resources in the connected VPCs.
• AWS PrivateLink: Offers unidirectional access from a consumer VPC to a specific service or application hosted in a provider VPC.

Use Case

• Transit Gateway: Ideal for complex, large-scale network architectures requiring centralized routing and management of multiple VPCs and on-premises networks.
• AWS PrivateLink: Best suited for securely exposing specific services or applications to other VPCs without allowing full network access.

Architecture

• Transit Gateway: Acts as a hub-and-spoke model, where each VPC and on-premises network connects to the Transit Gateway, simplifying the overall network architecture.
• AWS PrivateLink: Uses interface endpoints to create private connections to services within the AWS network, focusing on service-level connectivity rather than full network access.

Transitive Routing

• Transit Gateway: Supports transitive routing, allowing VPCs connected to the Transit Gateway to route traffic between each other seamlessly.
• AWS PrivateLink: Does not support transitive routing; traffic is restricted to the endpoint connection between the consumer and provider VPCs.

Network Connectivity

• Transit Gateway: Supports both intra-region and inter-region connectivity, providing flexibility for connecting VPCs across different regions.
• AWS PrivateLink: Limited to the AWS region where the VPCs reside but can be combined with Transit Gateway for centralized access to a PrivateLink endpoint from multiple VPCs.

Security

• Transit Gateway: Provides secure routing and centralized control over network traffic between VPCs and on-premises environments.
• AWS PrivateLink: Enhances security by keeping traffic within the AWS network and restricting access to specific services or applications.

Complexity

• Transit Gateway: More complex initial setup due to the need for centralized routing configuration but simplifies ongoing management for large networks.
• AWS PrivateLink: Simpler to set up for service-specific access, with straightforward endpoint creation and management.

Use Cases

Choose Transit Gateway if:

• You need to manage and route traffic across a large number of VPCs and on-premises networks.
• Your network architecture requires transitive routing between multiple VPCs.
• You are looking for a scalable solution that simplifies network management and supports complex routing requirements.

Choose AWS PrivateLink if:

• You need to provide secure, private access to specific services or applications from another VPC.
• You require unidirectional access to maintain tighter security controls.
• You want an easy-to-set-up solution for service-specific connectivity within the AWS network.

Transit Gateway vs VPC Peering

Key Differences:

Connectivity Options

• VPC Peering: Enables direct connectivity between two VPCs. This connection is non-transitive, meaning VPC A can connect to VPC B, but VPC B cannot connect to VPC C through VPC A.
• Transit Gateway: Acts as a hub for multiple VPCs and on-premises networks, allowing transitive routing between them. It simplifies network management by connecting VPCs and on-premises networks through a single gateway.

Architecture

• VPC Peering: Establishes a mesh network where each VPC requires a peering connection with every other VPC it needs to communicate with. This can become complex with a large number of VPCs.
• Transit Gateway: Utilizes a hub-and-spoke model, where each VPC connects to the Transit Gateway, reducing the complexity of having multiple peering connections.

Transitive Routing

• VPC Peering: Does not support transitive routing, requiring direct connections between all VPCs.
• Transit Gateway: Supports transitive routing, enabling VPCs to communicate with each other through the Transit Gateway.

Network Connectivity

• VPC Peering: Limited to VPCs within the same AWS region, though inter-region peering is available with some additional considerations.
• Transit Gateway: Supports both intra-region and inter-region connectivity, providing a more flexible and scalable solution.

Complexity

• VPC Peering: Simpler to set up for small-scale networks but becomes complex with an increasing number of VPCs due to the need for multiple peering connections.
• Transit Gateway: More complex initial setup but simplifies ongoing management and scaling for large networks.

Scale

• VPC Peering: Suitable for smaller networks with fewer VPCs.
• Transit Gateway: Designed for large-scale networks, supporting thousands of VPCs and on-premises connections.

Bandwidth Limit

• VPC Peering: Bandwidth is limited by the instance type and its networking capabilities.
• Transit Gateway: Offers higher bandwidth capacity, suitable for large-scale data transfers between VPCs.

Latency

• VPC Peering: Generally lower latency since it’s a direct connection between VPCs.
• Transit Gateway: Slightly higher latency due to the additional hop through the Transit Gateway, but typically negligible for most applications.

Use Cases

Choose VPC Peering if:

• You need low-latency, direct connections between a few VPCs.
• Your network architecture is simple with a limited number of VPCs.
• Cost is a major concern, and you want to avoid the additional expense of a Transit Gateway.

Choose Transit Gateway if:

• You require transitive routing between multiple VPCs and on-premises networks.
• You are managing a large, complex network with many VPCs.
• You need a scalable solution that simplifies network management and supports high bandwidth requirements.

AWS Direct Connect vs PrivateLink

Key Differences:

Connectivity

• AWS Direct Connect: Provides a dedicated, private network connection between your on-premises data center and AWS. It bypasses the public internet, offering a secure and reliable link.
• AWS PrivateLink: Facilitates private connectivity between VPCs and AWS services or your own applications hosted on AWS, using private IP addresses within your VPC.

Use Case

• AWS Direct Connect: Ideal for hybrid cloud setups where secure, low-latency, and high-bandwidth connectivity between on-premises infrastructure and AWS is required.
• AWS PrivateLink: Best suited for accessing AWS services or third-party SaaS applications privately and securely within your VPC, without exposing your traffic to the public internet.

Architecture

• AWS Direct Connect: Establishes a physical connection via a cross-connect at an AWS Direct Connect location. This connection can be partitioned into multiple virtual interfaces to separate different workloads.
• AWS PrivateLink: Uses Elastic Network Interfaces (ENIs) to create VPC endpoints, allowing private communication between your VPC and the services you’re connecting to.

Performance

• AWS Direct Connect: Offers consistent, high-performance connectivity with speeds ranging from 50 Mbps to 100 Gbps. It’s suitable for workloads requiring high throughput and low latency.
• AWS PrivateLink: Typically provides lower latency within the AWS network, but its performance depends on the VPC configuration and the specific service endpoints used.

Security

• AWS Direct Connect: Ensures security by isolating your traffic from the public internet, reducing exposure to external threats. Additional encryption can be applied using VPN.
• AWS PrivateLink: Keeps traffic within the AWS network, reducing the attack surface by not traversing the public internet. All traffic stays private and secure within AWS.

Cost

• AWS Direct Connect: Involves costs for the physical connection, data transfer, and additional charges based on the port speed and location.
• AWS PrivateLink: Charges based on data processing for the endpoint and data transfer within the AWS network. Generally more cost-effective for accessing AWS services and third-party applications.

Setup Complexity

• AWS Direct Connect: Requires physical setup and coordination with AWS and network providers, making the initial setup more complex and time-consuming.
• AWS PrivateLink: Easier to set up with VPC endpoints created through the AWS Management Console, APIs, or CloudFormation templates.

Use Cases

Choose AWS Direct Connect if:

• You need a secure, dedicated, and high-bandwidth connection between on-premises infrastructure and AWS.
• Your applications require consistent and low-latency network performance.
• You are dealing with large volumes of data transfer between on-premises and AWS.

Choose AWS PrivateLink if:

• You need to access AWS services or third-party SaaS applications privately from within your VPC.
• You want to simplify your network architecture by avoiding internet-exposed endpoints.
• You require a quick and straightforward setup for private connectivity within AWS.

Cross-region PrivateLink

Currently, PrivateLink is not available across regions: The consumer VPC Endpoint must be in the same region as the Service Provider Endpoint Service. However, it is still possible to leverage PrivateLink for services and consumers in different regions by combining it with VPC Peering or Transit Gateway Peering.

These services can be used on either the Consumer or Service Provider side to extend the connectivity to another region. This is achieved by deploying a VPC into the region where the PrivateLink service exists and deploying the PrivateLink VPC Endpoint into this new VPC, then configuring VPC Peering (or Transit Gateway) to connect this new VPC to the required VPC in your region.

How to get started with AWS PrivateLink

Connecting to a service that is provided via PrivateLink requires creating an Interface VPC endpoint inside one of your VPCs. This is a network interface connected to your VPC, with an IP address in the VPC’s subnet. Your clients can then access the service by connecting to the IP of that interface.

This interface can be reached locally by clients in the same VPC, by clients in other VPCs via VPC Peering or Transit Gateway, and by on-premises clients via DirectConnect.

Each Interface VPC endpoint is deployed into a single Availability Zone, so for high availability, multiple interfaces should be deployed in different zones. PrivateLink also has integration with the Route 53 Resolver for automatic resolution of service FQDNs to the local IP of the Interface VPC endpoint.

The image below shows how Interface VPC endpoints can be deployed and accessed from clients in other VPCs and on-premises.

To create an Interface VPC endpoint, head to the VPC section of the AWS console, select Endpoints (on the left), and click Create endpoint (on the right).

This page allows you to create an endpoint to access native AWS services, PrivateLink Ready partner services, AWS Marketplace services, or any other PrivateLink services.

AWS Services and Marketplace Services can be selected from a list, while PrivateLink Ready partner services or other endpoint services require the service name to be provided. The service provider should be able to supply the required service name.

At the time of this writing, there are 142 AWS services available via PrivateLink, which are also listed on the Create Endpoint page in the AWS console. Some popular use cases include providing private access to S3, SQS, and Systems Manager.

Have a look at some examples of SaaS services available via PrivateLink through the AWS Marketplace.

You can also view the list of offerings supported by AWS Technology partners to see the most up-to-date offerings available via this method: Look for the “AWS PrivateLink Ready Product” offering designation in each listing.

AWS PrivateLink with Megaport

As a trusted AWS Technology Partner, Megaport’s Software Defined Network (SDN) can extend your AWS PrivateLink connection over our private global backbone.

This allows streamlined, automated, and optimized connectivity to AWS services, SaaS, and internal applications from data centers, enterprise locations, WANs, branches, and even other cloud environments.

By using Megaport as your single interconnection point, you can connect your AWS resources to other cloud providers with our Megaport Cloud Router (MCR), and achieve branch-to-cloud AWS connectivity with one of our SD-WAN integration partners on Megaport Virtual Edge (MVE).