Amazon API Gateway Types, Use Cases and Performance

API Gateway use cases

API an API that functions as a gateway to upstream services. Its primary use cases are:

• Allowing Http access to services without a native interface, Lambda, Kinesis, Rekognition and many more
• Versioning different APIs, allowing for backward compatibility
• Monitoring and managing traffic coming into multiple services
• Presenting an API frontend for services
• Throttling; in general or for specific users
• Authentication; through Cognito or your own identification provider

General Architecture

AWS API Gateway resides in an AWS-managed environment. The Serverless services, manages its hosting, redundancy, scaling, patching. The technology is completely invisible - all you get is a management interface. You choose to configure API, it is hosted by AWS. If you want to learn more about Serverless, check out my blog post on Building a stack bot with serverless.

Because a picture speaks a thousand words, here is a visualization:

The Original API Gateway: Edge Optimized

At its release in July 2015, API Gateway allowed access to Lambda and publicly available HTTP endpoints. At that Lambda Functions could not be placed in a VPC - this feature was released in February 2016. In its initial Gateway came paired with a CloudFront distribution. The combined API Gateway and CloudFront would later be called Edge Optimized API Gateway, preferring to the Edge locations available in CloudFront.

Important details to remember regarding the Edge Optimized :

• It uses CloudFront distributions, but you can’t edit the distribution. Adding an Amazon Web Application Firewall (WAF), for example, is not possible.
• Other sources, but those sources have to be publicly accessible.

Regional API Gateways

Benefits to this variant are:

• Your own CloudFront distribution in front of your gateway. This distribution can have a WAF.
• Gateway is going to be accessed from the same AWS, the Regional Gateway will have less latency.

Integration with Private VPCs

Gateway has always been that any Http backend behind the Gateway needed to be publicly accessible. And because the public IP address of the Gateway is unknown, IP whitelisting at the backend was not a viable option. Also in November 2017, Amazon integration with private VPCs to solve this issue.

The connection needs your private resources needs two parts:

• A private Network Load Balancer (NLB) in your VPC in front of the resources you want to access
• An API Gateway VPC Link that points to that NLB

Private API Gateways

When To Use Which API Gateway

Performance

Thanks

ANUJ KUMAR SHARMA