Part 4

This is the fourth part of a multi-part series on Mastering Private Integrations in Amazon API Gateway.

• In the first part, “Private Integrations in Amazon API Gateway: A Guide”, we compared API Gateway with ALB and had an overview of AWS Hyperlink, AWS PrivateLink, and VPC link.
• In the second part, “HTTP API Private Integrations” we focused on the advantages of HTTP API and how to configure private integrations with its VPC Link resource.
• In the third part, “REST API Private Integrations”, we focused on REST API private integrations powered by AWS PrivateLink and explored how to set up its VPC link resource in the AWS Management Console.
• In this part, we will explore some common API Gateway private integration patterns and how to scale them for multiple microservices for both REST APIs and HTTP APIs.

Scaling HTTP API Private Integrations

In the previous parts, we saw that HTTP APIs were introduced a few years after REST APIs to improve the developer experience by simplifying or removing unnecessary or complex configurations and features.

One of the ways in which HTTPs offer flexibility and simplicity is in the possibility of using a single VPC link to connect to all resources such as ALBs, NLBs or AWS Cloud Map Service in a VPC.

‍When it comes to the HTTP API private integrations, you should keep the following in mind:

1. HTTP API VPC links can connect directly to NLB, ALB or Cloud Map and therefore have more integration options.
2. A single VPC link can be reused in a fanout scenario, connecting multiple resources at the same time.

Let’s examine a few scenarios from simple to complex.

Single VPC Link to Multiple NLBs and ALBs

In a fanned-out scenario with a single VPC link, scaling your microservices is as simple as adding more ALBs or NLBs or resources registered with AWS Cloud Map service. However, you should be wary of running multiple services in the same VPC as you may run out of IP addresses to allocate if your VPC CIDR isn’t large enough.

You can have a dedicated ALB per microservice in your VPC and use Amazon API Gateway’s path-based routing to forward requests to the appropriate ALB associated with the microservice.

But What if Your Microservices Reside in Different VPCs?

In this scenario, you will need a separate VPC link for every VPC that hosts the backend resources for your microservice application.

‍

But once again, each VPC link can be fanned out to connect to multiple NLBs, ALBs or CloudMap services in the respective VPCs.

Considerations

When scaling HTTP API Private Integrations, you should take note of the following.

• A single VPC link can connect to multiple load balancers.
• No need to introduce new components for load balancing. The system seamlessly integrates with existing microservices load balancers (NLB, ALB), reducing operational overhead.
• Direct communication between existing components minimizes delays, leading to faster response times for API requests.
• Dedicated load balancers for each microservice allow development teams to deploy updates independently, improving agility and reducing risk.
• The quota for HTTP VPC links per account per Region is 10.

Scaling with AWS Cloud Map

If you have resources not exposed by an ALB or an NLB, then you can use AWS Cloud Map with your HTTP API VPC link. When an application scales to hundreds or even thousands of services, a load balancer might not be ideal. AWS Cloud Map is a resource discovery service that provides a dynamic map of your cloud resources. It does this by registering application resources such as databases, queues, microservices, and other resources with custom names.

Traditional server-side discovery relies on load balancers, requiring applications to know the load balancer's endpoint. This adds an extra hop (proxy) and introduces latency.

You use HTTP API VPC links to privately connect to an AWS Cloud Map target option to discover services like ECS and EC2-based services.

AWS Cloud Map empowers applications with client-side service discovery. It eliminates the need for a load balancer as the proxy. Instead, applications directly connect to backend services registered in the service registry. By removing the proxy layer, potential points of failure are minimized, enhancing deployment safety and latency is caused by the proxy overhead is reduced.

Considerations

When scaling HTTP API Private Integrations, you should take note of the following.

• A single VPC link can connect to multiple load balancers.
• No need to introduce new components for load balancing. The system seamlessly integrates with existing microservices load balancers (NLB, ALB), reducing operational overhead.
• Direct communication between existing components minimizes delays, leading to faster response times for API requests.
• Dedicated load balancers for each microservice allow development teams to deploy updates independently, improving agility and reducing risk.
• The quota for HTTP VPC links per account per Region is 10.

Scaling REST API Private Integrations

Unlike HTTP APIs, REST APIs rely on AWS PrivateLink and consequently, have some constraints when it comes to scaling multiple microservices. The main considerations are:

• REST API private integrations can only be terminated on NLBs
• VPC links for REST APIs can only terminate on one NLB in a VPC

Let’s examine a few scenarios from simple to complex.

Scenario 1: Single NLB per microservice

In this scenario, each microservice is served by exactly one NLB. The microservices could be in the same VPC or different VPCs. You then use API Gateway path-based routing to send requests to the corresponding NLB for each microservice.

You can scale this pattern further by adding more VPC links to more NLBs in the same VPC or if more isolation is required per microservice, the VPC links could still connect to NLBs in different VPCs.

This scenario is simple as a single NLB in the request path reduces operational complexity and removes overhead latency associated with proxy ALBs. Also, a dedicated NLB for each microservice makes deployments easier.

However, due to the limit of 20 VPC links per account per Region, your scaling options are limited.

Scenario 2: Single NLB for Multiple Microservices

With the 20 VPC links to NLBs per account per Region quota, you might quickly run out of VPC links if you decide to go with a single NLB per microservice pattern. However, you can still use a single NLB to expose multiple microservices in a VPC by using multiple listeners. Each listener will be mapped to a unique port per microservice.

Your API Gateway can route each method to the appropriate integration point. You define the service as a combination of a VPC link integrated with an NLB and the specific port assigned for microservice at the NLB Listener.

With this pattern, you still benefit from low latency as a result of a single NLB in the request path. You only manage a few NLBs for multiple microservices which means you can scale by adding more listeners to the same NLB for additional microservices. However, you are still constrained by the quota for NLBs per Region. Sharing NLBs also eliminates the independent deployment flexibility advantage for microservices.

Scenario 3: Using NLBs and ALBs

Although REST API VPC links can only integrate directly with NLBs, you do not need to replace your existing microservices exposed by ALBs. You just simply need to make the ALBs a target from the NLB. The same connectivity pattern can be used if your microservices reside in multiple VPCs.

To scale this pattern, you can add more NLB listeners to support more ALB targets. The ALB can use path-based rules to route requests to multiple microservices.

This pattern is highly scalable as NLBs can handle millions of packets per second to multiple ALBs. You can still maintain a single ALB per microservice so deployments are independent.

But having both NLB and ALB in the request path is a penalty on latency.

Conclusion

In conclusion, scalable API Gateway integrations for microservices hinge on VPC links, load balancers, and API Gateway tooling for REST and HTTP APIs. HTTP APIs simplify scaling with a single VPC link connecting multiple resources like ALBs or NLBs, allowing independent microservice scaling and reduced overhead. For microservices across different VPCs, separate VPC links are needed, but AWS Cloud Map streamlines resource discovery, cutting latency and eliminating load balancers.

REST API private integrations, relying on AWS PrivateLink, face constraints like NLB termination and limited VPC links per Region. A single NLB per microservice reduces latency but is restricted by VPC link quotas. Using a single NLB with multiple listeners scales within a VPC but sacrifices deployment flexibility.

Combining NLBs and ALBs leverages existing infrastructure and supports independent deployments, despite added latency from dual load balancers. Choosing between HTTP and REST APIs and load-balancing strategies should align with your microservices' scaling needs.

By considering these strategies, you can optimize your API Gateway for robust, secure, and scalable microservice integrations, balancing performance, latency, and operational efficiency for a resilient application infrastructure.

References

Application Load Balancer-type Target Group for Network Load Balancer | Amazon Web Services

Quotas for your Network Load Balancers - Elastic Load Balancing

Architecting for scale with Amazon API Gateway private integrations | Amazon Web Services