AWS PrivateLink, Explained

AWS PrivateLink, Explained

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 blog will answer such AWS PrivateLink questions.

Contents

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.

AWS PrivateLink

AWS PrivateLink protects your cloud data by operating inside the AWS system. Source: AWS

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 (we explain what SaaS is in a previous blog ) 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.

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

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.

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.

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.

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.

AWS PrivateLink

Securely access services over AWS PrivateLink. Source: AWS

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.

AWS PrivateLink

Integrating AWS Transit Gateway with AWS PrivateLink and Amazon Route 53 Resolver. Source: AWS

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

screenshot

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

To see some examples of SaaS services available via PrivateLink through the AWS Marketplace, click here .

Some popular examples include:

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.

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

Tags:

Related Posts

The Internet is a Series of Tubes: Peering and the MegaIX

The Internet is a Series of Tubes: Peering and the MegaIX

Share and source traffic with a global network of service providers via the MegaIX.

Read More
Enable a Split-stack Architecture Spanning Oracle Cloud and Other Providers Using Megaport

Enable a Split-stack Architecture Spanning Oracle Cloud and Other Providers Using Megaport

Implement a secure split-stack architecture and become platform agnostic. Leverage the cost and performance advantages of Oracle Cloud and Oracle Autonomous Database for your applications hosted by other cloud providers.

Read More
Podcast Transcript: Unlocking the True Potential of Multicloud

Podcast Transcript: Unlocking the True Potential of Multicloud

Paul McGuinness, EU Head of Solutions at Megaport, talks about the trends and challenges of multicloud solutions and what businesses should consider when putting together their multicloud connectivity strategy.

Read More