Securing connections with AWS PrivateLink
By Sandeep Saran
Introduction to AWS PrivateLink
In the current architectural landscape, we often find ourselves either consuming some services or providing services to our clients. Traditionally, the data that is exchanged between service provider and service consumer would traverse over the internet even if the provider and consumer are hosted within the same cloud provider. However, the data exchanged can be sensitive data like Personal Identifiable Information (PII), credit card information or sensitive health data. Many organisations would want to prevent sensitive data to traverse over the internet and it may well be part of compliance and subject to auditing.
In 2017, AWS introduced a new service called AWS PrivateLink that allowed services to be consumed without the data going to internet. Since then, many AWS services as well as third party SaaS providers services are exposed through PrivateLink.
In this article, we will try to understand how AWS PrivateLink works, what are common architecture patterns, use cases and best practices for implementing AWS PrivateLink.
Communication patterns for Service Provider and Consumer
Let’s start with the basics. When we deploy our workloads in AWS, very few AWS services actually reside in our VPC. Most of them are outside our VPC on the AWS network. Let say that you have application in your VPC that is consuming Amazon Kinesis. Below diagram shows how the communication happens over the internet
Here, when the application needs to call Amazon Kinesis, we need to have an Internet Gateway with Public IP address and the data between our application and Kinesis would then be communicated over the internet. However, as discussed before, this may not be always desirable. So, let’s look at the same use case without having to send data over internet.
AWS provides VPC endpoints that can be used to consume services without going through the hassles of configuring internet gateway and using public IP address. There are two types of VPC endpoints:
- Gateway endpoints
- Interface endpoints
Gateway endpoints can be used only with AWS S3 and DynamoDB whereas Interface endpoints can be used with most of the AWS Services. Below diagram shows how we can use interface endpoint for consuming Amazon Kinesis
In the diagram above, the request from application goes via interface endpoint to AWS Kinesis, however, note that there is no Internet Gateway in our setup. When the interface endpoint is created, AWS will setup Elastic Network Interface (ENI) in each availability zone where our application is deployed and these ENIs will be assigned a Private IP address from the subnet CIDR range. When the application wants to communicate with Kinesis, the data goes from Interface Endpoint to Kinesis without leaving the AWS network backbone. This means that you are now consuming AWS services like they are deployed inside your VPC, although they are not. No data goes to internet and hence you don’t have to setup Internet Gateway or NAT devices.
The interface endpoint that we are referring to actually communicates with AWS services like Kinesis via AWS PrivateLink. So, PrivateLink is powering the Interface Endpoint, but the real flexibility comes from the fact that PrivateLink is not only restricted to communication with AWS Services, but you can also use it for communication with any third-party service provider hosted on AWS.
Using PrivateLink for SaaS Services
In Epsilon, we ensure that all our services that are consumed by our clients are highly secured. Although you can secure services traversing via internet, but some client would not want data to traverse internet due to compliance and audit requirements. In such cases, we do provide option of exposing our service via AWS PrivateLink. Below is a simplified version of how communication between service provider and service consumer works via AWS PrivateLink
Let's talk about some basic requirements for exposing services and consuming services via PrivateLink
- Service Provider needs to have Network Load Balancer that should frontend the endpoint services.
- Service Consumer should create the VPC endpoint in their VPC that communicates with the network load balancer on provider side.
- Service Provider should whitelist the consumer AWS account so that the services from provider are discoverable to the consumer account.
- Both Consumer VPC and Provider VPC should be in the same AWS region since AWS PrivateLink is a regional service, although we will discuss architectural pattern for cross region communication later in the article.
AWS PrivateLink at scale
Now that we have understood the basic setup of how provider and consumer interact over PrivateLink, let’s look at some complexities that may arise when we are implementing AWS PrivateLink at scale.
Decentralised endpoint architecture
Consider that you have Lambda function that is going to utilise two AWS services — API Gateway and AWS App Config via PrivateLink. You follow AWS Best Practice and deploy for Lambda function to three availability zones. Your AWS infrastructure at this time will look like below:
Note that you will have to deploy two interface endpoints on each availability zone. This is because interface endpoint is specific to AWS service. You cannot have one interface endpoint interact with two different AWS services. So, at this point you have six interface endpoints. Now as with any organisation, you will not have only one VPC that needs AWS services. Probably you will have many VPCs and many AWS accounts. So, for example, if you have 100 VPCs in your organisation, each consuming only two AWS Services, you are potentially looking at managing 600 interface endpoints. Also, you would be definitely consuming more than two AWS services and your catalog of AWS services would grow further over time. This can be quite challenging as you would need to manage security groups, endpoint policies, chargeback etc. for all of these endpoints.
Above diagram shows decentralized architecture where we have 4 AWS accounts. “AWS Account 3” has deployed microservice which is consumed by “AWS Account 4”. Also, all AWS accounts except “AWS Account 4” are using AWS services. In this simple architecture, we can see seven endpoints and if we deploy all our workloads to three availability zones (instead of single Availability Zone as shown above), we will have 21 endpoints. This can grow very quickly as you add more endpoints services and more AWS accounts.
Centralised Architecture
If you want to implement AWS PrivateLink at scale, you may want to evaluate centralised endpoint strategy. In centralised architecture, you will have a shared service account that will host all the endpoints as shown below:
Since you have a shared service account which will host all the endpoints for PrivateLink, you would need other accounts to communicate with this shared service account. Hence in centralised architecture, you would have transit gateway that will facilitate such communication. Note that we are talking about implementation at scale, so in an enterprise cloud architecture, you would anyways be utilising AWS transit gateway to simplify your communication patterns.
Another important note while considering centralised architecture is to ensure that you disable Private Hosted Zone (PHZ) DNS at the endpoint level. As shown in the below example, if you have an API gateway that is exposing a service to Lambda, you will create a Private Hosted Zone using Route 53 which will resolve call to the API Gateway to your VPC endpoint in the shared service account.
Centralised vs Decentralised Architecture
We must carefully evaluate our strategy for centralised endpoint architecture versus decentralised architecture. Both the approaches have their benefits and drawbacks. Let’s look at these architecture patterns in terms of cost, security and ease of management to understand this better.
In decentralised architecture, you pay for per endpoint per hour for each VPC as well as data processing charges per GB. In centralised architecture, you have shared service account which will host all the endpoints. Hence, you will still pay for per endpoint but only once per service consumed since you have centralised shared account. However, in centralised architecture you will have to take into consideration Transit Gateway charges and data processing charges at Transit Gateway as well as at the endpoints. So to summarise the complex topic of pricing, if you have more data to process, decentralised would be more cost effective since in centralised architecture, you pay for data processing fee at transit gateway as well. However, if you have high number of VPCs and many endpoints with less amount of data processing requirements, centralised architecture would be more cost effective. It is recommended that you do the pricing calculations for your use case to compare between centralised vs decentralised architecture.
When it comes to security and management both architectures have their own benefits as shown below:
Below are some of the guidelines on centralised vs decentralised architecture.
Inter-Region endpoint services
Lastly, let’s address inter region connectivity through AWS PrivateLink. AWS PrivateLink is a regional service which means that as a service provider, if you have setup in US East Region and you want to extend the same services to Singapore region, you would need to deploy your services to Singapore region. However, deploying complex workloads in another region can be time consuming and also organisations would need to work out operational and cost considerations. The alternate option for extending services to different region is to use Inter-Region VPC peering as shown below:
In the above diagram, service provider is providing services via us-east-1 and consumers in us-east-1 are connecting to the service via AWS PrivateLink. Consider that service provider has a new client in Singapore who wants to consume the service. For this, the provider can deploy a Load Balancer in Singapore region (ap-southeast-1) and establish an Inter-Region VPC peering between VPCs in us-east-1 and ap-southeast-1. The consumers in Singapore region can then connect to provider VPC in the same region which will resolve the calls to endpoint services in us-east-1.
Note that this setup would introduce additional latency and data transfer cost for Inter-Region VPC peering.
Conclusion
AWS PrivateLink is highly scalable service from AWS that can be used to securely consume services from AWS or from service providers without the need for data to traverse the internet. It is easy to setup as you don’t need to manage internet gateway, NAT devices, public IP addresses or VPN connection. AWS PrivateLink also enables SaaS service providers in AWS Marketplace to setup services via PrivateLink.
When using AWS PrivateLink, organisations must plan their strategy of how they will manage endpoints at scale. Many considerations such as security, scalability, maintainability and cost should be evaluated when deciding on the architecture patterns.
