–
SaaS platforms typically expose their API endpoints over the Public internet. We recently encountered a challenge with one of our clients, a company that offers a SaaS product. They had a specific customer requirement: their API should not be accessible via the public internet. This request was driven by the need to comply with certain regulations and to address concerns about latency. Both the SaaS platform and the Customer were running in the AWS cloud.
VPC peering is often used when two different Virtual Private Clouds (VPCs) in different AWS accounts need to communicate over AWS’s private backbone network. There is extensive documentation out there explaining how peering works.
However, one of the downsides of the VPC peering is that the CIDR range for both the VPCs has to be nonoverlapping to avoid IP clashing. Since the Customer infrastructure team chooses the VPC CIDR for their VPC, the SaaS provider has no control over it. It means there can be issues if a Customer has chosen the overlapping CIDR with the SaaS Provider or even with a different Customer. So, VPC peering doesn’t solve the problem.
For such a situation, AWS provides PrivateLink service.
From the AWS documentation
AWS PrivateLink provides private connectivity between virtual private clouds (VPCs), supported AWS services,
and your on-premises networks without exposing your traffic to the public internet.
AWS PrivateLink consists of a service endpoint created on the Provider side. It is a regional service, so any service exposed by the Service Endpoint only needs to be provisioned once per region. This endpoint can be added on the consumer side in the same region.
This is explained in the below diagram.
When the consumer is in a different region, the provider can create another VPC in the new region and peer it with its own VPC, which has the PrivateLink service endpoint. This is explained in the diagram below.
The PrivateLink pricing is also simple to understand. It has a fixed $0.01 per hour pricing for an endpoint and usage based $0.01 per TB of data transfer which gets reduced for higher data volumes.
In our case, once we provisioned the Service endpoint, we shared the endpoint that the Customer added into their VPC in the same region. It was working seamlessly. The Customer could access the API, and we ran the latency checks. The results were really impressive, as shown in the screenshots below.
PrivateLink Producer and Consumer in the same region
The latency for endpoint over the internet in the within the same region: 0.21 sec
The latency for endpoint using PrivateLink in the within the same region: 0.08 sec
PrivateLink Producer and Consumer in two different regions
We also tested the Private Link with setup in a different region. There we also saw great results.
The latency for endpoint over the internet in the across two different regions region: 0.81 sec
The latency for endpoint using PrivateLink in the across two different regions region: 0.18 sec
The summary of the results is as below:
| Both VPC in same Region | VPCs in separate regions | |
|---|---|---|
| Latency over Public Internet | 0.21 sec | 0.81 sec |
| Latency using PrivateLink | 0.08 sec | 0.18 sec |
| % Latency Improvement | 61% | 77% |
PrivateLink really shines when it comes to sharing a particular resource outside our AWS account and VPC without worrying about the consumer-side VPC knowledge. As PrivateLink is a regional service, it only needs to be set once per region, and multiple Consumers can consume it without changing anything on the provider side. PrivateLink also offers to add a DNS record at the consumer side which helps to seamlessly manage the underlying service on the provider side. So the VPCs that are attached with the PrivateLink automatically resolve to a private IP and other VPCs continue to work on public IP. So customers who don’t need PrivateLink don’t have to do anything on their side.
This has also given it popularity among various Managed databases, Message Queues, and Data Warehouse providers.
We have been happily running PrivateLink in production for around two years, processing a scale of 6.5k req/min and 1.11 terabytes of data daily!
If you’re looking for help with your AWS setup and managing your external API endpoints securely, reach out to us here.
