HTTP API Private Integrations

Part 2

This is Part 2 of the series, here is Part 1: Mastering Private Integrations in Amazon API Gateway: A Comprehensive Guide ??

Introduction

A VPC link is a resource within Amazon API Gateway that leverages AWS Hyperplane to provide private integrations to your VPC’s HTTP/HTTPS endpoints. This is the second part of a multi-part series where we go deep into private integrations for Amazon API Gateway. In other words, how API Gateway integrates with HTTP and HTTPS resources within an Amazon Virtual Private Gateway (VPC).

In the first part, “Mastering Private Integrations in Amazon API Gateway: A Comprehensive Guide ”, we discussed scenarios in which an API Gateway API is more suitable than an Application Load Balancer(ALB). We also discussed how VPC links enable private integrations from API Gateway public APIs leveraging AWS Hyperplane to connect to VPC resources privately. We also saw that API Gateway provides tooling for REST and HTTP APIs but only REST APIs leverage AWS PrivateLink while HTTP APIs don’t.

In this part, we are going to dive further into why API Gateway’s tooling for HTTP APIs is different from the tooling for REST APIs and how this difference makes it possible for HTTP APIs to be privately connected to VPC resources using VPC links in a way that doesn’t depend on AWS PrivateLink.

API Gateway HTTP APIs: A single-course meal

Amazon API Gateway was introduced in 2015 to enable developers to build secure scalable APIs quickly in front of a variety of architectures and has slowly grown in terms of features and services offered to customers. But in 2019, HTTP APIs were introduced which still have the essential core features of API Gateway but are:

Faster: Each service involved between a request from a client to a server adds latency and consequently affects the end-user experience. HTTP APIs offer up to a 60% reduction in latency in the most common use cases.
Cheaper: AWS has a reputation for reducing prices and the HTTP API is another example that lives up to Werner Vogels’ frugality principles with an advertised reduction of up to 71%.
Simpler: They support mostly relevant features when it comes to API Management and make integrations with other AWS services simpler. For example, when building storage-first serverless applications with Amazon SQS, you do not need to write any VTL code. Lesser features mean fewer buttons and form fields if you are a “ClickOps” guru.
Offer new features: They support JWT authorizers from non-Cognito OpenID providers and offer private integrations with Application Load Balancers and AWS Cloud Map.

Private Integrations for HTTP APIs

We previously mentioned that HTTP API’s VPC links don’t rely on AWS PrivateLink for private integrations. This isn’t a drawback but another proof that HTTP APIs are designed to be simpler but a lot more flexible. REST API VPC links rely on AWS PrivateLink which due to its design, can only be terminated on a Network Load Balancer (NLB). If your HTTP/HTTPS endpoints in your VPC are fronted by an ALB, then you will need a combination of NLB + ALB. We will go into REST API VPC links in the next post but for now, let's focus on HTTP API VPC links.

VPC links for HTTP APIs use VPC-to-VPC NAT which is a higher level of abstraction. It is essentially a tunnel between the API Gateway service’s VPC and the client’s VPC terminating on Elastic Network interfaces (ENI) at both ends. This enables the API Gateway to reuse the same tunnel connection to directly access multiple backend resources such as NLBs, ALBs, or resources registered with AWS Cloud Map.

This makes the implementation and scaling of HTTP API VPC links simpler but more flexible compared to REST API VPC links.

Private integration options

For private integrations, HTTP APIs offer more direct integration endpoints: ALBs, NLBs and AWS Cloud Map. Integrating directly into an ALB is probably the most interesting option because you do not need to redesign your architecture if you already have existing microservices on ALBs. The same advantage applies to existing microservices on AWS Cloud Map.

You must therefore consider which integration target is appropriate for your use case. The table below summarizes some key points to consider.

Integration target Listener Use cases NLB TCP or TLS listener TLS passthrough is possible High throughput ALB HTTP or HTTPS listener Layer 7 routing Content-based routing AWS Cloud Map Namespace/service AWS Cloud Map parameters (optional) Service discovery

In the Scaling Private Integration part, we will go over various patterns you can adopt from simple to multiple microservices across multiple VPCs.

How to set up private integrations for HTTP APIs

Setting up VPC links for HTTP API private integrations can be accomplished in a few steps. We will start with creating an HTTP API before creating the VPC link resource.

Note that the steps below only show how the VPC link resource is created and connected to an existing ALB in a VPC.

AWS Management Console setup

You can set up private integrations for your HTTP APIs in the AWS Management Console with the following steps:

Step 1: Create an HTTP API

Open the API Gateway console and click on “Create API”.

Under HTTP API, click on “Build”.

Provide a name for the HTTP API: “my-http-api” and click on “Next”.

Click on “Review and Create”

Click on “Create”.

Step 2: Create a VPC link.

Select “VPC links” on the left menu bar then click on the “Create” button.

Select “VPC link for HTTP APIs”
Provide a name for the VPC link resource: “vpclink-to-alb”
Select the VPC that the VPC link will connect to.

Select the subnets in which the VPC link will setup ENIs

Choose a security group for the VPC link then click on “Create”

Take note of the VPC link ID.

Step 3: Set up the private integration

Go back to the HTTP API and click on the “Create” button under Routes.
Chose the “ANY” route and create a resource “saas-resource”
Click “Create” to create the route for the resource.

Click on "Attach Integration"

Select the “ANY” route and click on “Create and attach an integration”

Select “Private resource” from the integration target drop-down menu

In the integration details, select “Select manually”
Select “ALB/NLB” and choose the ALB from the load balancer drop-down menu
Select “HTTP 80” listener

Select the VPC link which we created in the previous step and click on “Create”.

Click on “Deploy” to deploy the changes to the API

Create a new stage called “dev” and click on “Deploy”

After deploying, we can see that the “ANY” route is integrated to the ALB.

Summary

Though API Gateway HTTP APIs are cheaper and simpler in a way that greatly streamlines the API developer experience, it is really for scenarios where you want to proxy requests to the backend like Lambda functions so functionality is limited. For example, HTTP APIs do not have support for Caching, AWS WAF, API Keys, per-client rate limiting and usage throttling just to name a few. Here is a complete list of supported features to guide you in choosing between REST APIs and HTTP APIs. But because HTTP APIs were designed to be simpler and more flexible, they offer integrations to ALBs, NLBs and CloudMap. Setting up the VPC link resource in HTTP APIs can be accomplished in just a few steps. This makes it easier to connect to services already exposed by an ALB without requiring you to rearchitect the backend.

In the next post, we will dive deep into Amazon API Gateway REST API Private Integrations.