Establish cross-region and cross-account VPC connectivity between AWS accounts using AWS Private Link

With microservice architectures, multiple teams within an organization often build different parts of an application. Different teams may own functionality for a given business segment. By doing this, you might come across a situation where other teams might have used a different AWS region than what you are using. It is fine till the time both teams are using the same AWS account as you can establish the connection using VPC Peering. However, in case the teams are using different AWS accounts it might become a tedious challenge to resolve.

In this blog post, we will demonstrate how to expose a single public Amazon API Gateway endpoint managed from one AWS account. It integrates securely with different backend services using VPC endpoints powered by AWS PrivateLink.

Overview

The following architecture diagram provides an overview of the solution:

Architecture Diagram

In this architecture, there are two separate AWS accounts. Each owns a specific area of functionality and responsibility.

1. Account 1: This is a centrally managed consumer API that provides a single HTTPS endpoint to access the provider’s REST APIs hosted in Oregon (us-west-2) region. Using this architecture, you can apply authentication, authorization, rate limiting, and other API management tasks in one place.
2. Account 2: In this account, your current application is hosted. In this example, we have assumed that you are using AWS EKS to host your application in N. Virginia region (us-east-1)

Explanation

Once you start deploying microservices to your Kubernetes cluster, you may wish to expose them and provide a nicely decoupled API. Your first question would probably be, “How do I integrate my API Gateway with EKS cluster?”.

The integration is not straightforward as API Gateway runs its own VPC and is completely managed so you cannot see any details about its infrastructure. API Gateway provides us the Private Integrations to connect to HTTP endpoints running in your own VPC.

Private Integrations allow you to expose a Network Load Balancer (NLB) in your private VPC which can terminate traffic for your API Gateway to VPC integration. Now, we need to deploy some kind of Kubernetes Ingress controller that understands how to route traffic to Pods.

Architectural Diagram shared above displays the same mechanism. API Gateway will use VPC endpoint to communicate with Network Load Balancer (NLB) present in private subnet of your VPC which will route traffic to an ALB (ingress). ALB will then route traffic basis on the target groups setup basis on the kind of request we get. For example, if the request URL contains, /svc1 then it will route traffic to Svc1 service and if it contains /svc2, then it will route to Svc2 service, this concept is known as Path-based routing which is only supported in ALB.

Steps to implement the above architecture

We need to make sure, that if you are trying to connect to N. Virginia of the destination AWS account, i.e., Account 2, then we have to create a VPC in the same region in the source VPC account, i.e., Account 1. In this case, API Gateway is hosted in Oregon region of Account 1 which needs to be point to EKS cluster hosted in Account 2 in N. Virginia region.

1. Create a VPC in Account 1 in N. Virginia region.
2. Establish VPC Peering across 2 VPCs in Account 1 (N. Virginia and Oregon)
3. Add AWS account of Account 1 to Account 2 (N.Virginia) in allow-principle tab of endpoint service

4. Create Endpoint in Account 1 N. Virginia as the EKS application is hosted in N. Virginia region

5. Step #3 will create ENIs in the private subnets in the N. Virginia VPC. And these ENIs will have fixed IPs.

6. Create NLB in Oregon (Account 1) and configure target type as IPs and give IPs from Step #3.

7. Create VPC Link in Oregon (Account 1) by selecting NLB from step #5.

8. Use VPC Link in the existing API Gateway in the Oregon region.

Conclusion

This post demonstrates how to connect securely from API Gateway to private resources in different AWS accounts by using VPC endpoints powered by PrivateLink. PrivateLink traffic does not leave the AWS network, which reduces the attack surface and decreases network latency.

You can centrally apply features including throttling, authentication, and authorization via API Gateway, allowing application teams to focus on their business domains.

Okay !! So, that’s it from this post. Hope you liked it !!

Thanks 😇