DEV Community

Piero Bozzolo
Piero Bozzolo

Posted on • Originally published at Medium

The Secrets of AWS API Gateway

The Secrets of AWS API Gateway

How can an API be secured and exposed to the internet? How the underlying API resource access can be controlled? Is it possible to make an AWS service accessible to external users? Let’s see how API Gateway helps us answer those questions.

Generally speaking, an API Gateway is a management service that lies between an API client and a bunch of backend services. That service can be a container running NGINX, a Lambda function, a general HTTPS server running on EC2, or a group of legacy APIs.

Although the service can centralize and manage many APIs under a unique endpoint, somehow like Application Load Balancer, API Gateway can solve many other contour problems. Let’s see some examples.

Authentication

API Gateway can be configured to filter out unauthorized requests. API Gateway-managed API can be connected to AWS Cognito to handle authentication. This method involves the use of a bearer token included in every HTTP request.

Cognito is not the only option for authentication. A lambda function that checks the token and allows or denies every request can be set as a custom authenticator.

Throttling

How the number of API invocations can be limited per user or per region? Throttling is the right feature and put a limit on invocations preventing overwhelming the application. Also, different thresholds can be set for every consumer using usage plans and API keys.

Data Transformations

Sometimes, when a legacy or a 3rd-party service is used, the request body must be remapped in another format before processing. The same can happen backward: the answer sent from the service to the customer should be changed for compatibility purposes. Using the Velocity Template Language engine, mapping templates are responsible to reconstruct and transform request/response data. Request parameters can be transformed too.

Expose HTTP APIs.

Exposing HTTP API is the core feature of API Gateway. In the microservice era, this is the fundamental feature of a modern cloud-native application, where the architecture consists of lowly coupled and highly specialized services. Every application service can be written in different languages, by different teams or vendors, with custom development and release cycle. API Gateway exposes a unique endpoint for all of them. Moreover, every AWS service can be consumed as an HTTP request, so many of them can be served from API Gateway to your customer, even Lambda Function!

Body validations

One rule exists from ancient times: never trust inputs. When APIs are implemented an input validation technology must be chosen. In the previous paragraph, we highlighted that a modern application can be written in many languages with its validations library. API Gateway can validate inputs on your behalf, keeping the validations in one single point, using one only syntax.

Other features

API Gateway can work also as a cache for HTTP APIs and can mock API for development purposes.

AWS API Gateway types

There are three variants of API Gateway available, what is the right choice for your application?

HTTP API
If a gateway is needed without special features the HTTP API is the right choice. It doesn't support i.e. body transformation, throttling, and many other features BUT is the lowest latency and cheapest solution.

WebSocket API
If a full-duplex communication between the application and clients is needed, WebSocket is the cutting-edge technology that permits that.

REST API
This is the most used variant. Has all the features listed and more. When the developer wants to test API Gateway functionality this can be a good choice due to the advanced testing capability and the ability to import OpenAPI specifications.
REST API can be deployed in three modes:

  • Edge endpoint. Every request to the gateway will be routed to CloudFront Point of Presence making the application available with low latency all around the world.

  • Regional endpoint (you can start with this option). The endpoint will be deployed in your application region

  • Private regional endpoint. Same as Regional Endpoint, but the application will be available only in your Virtual Private Cloud (your network inside AWS)

For more information on what kind of API Gateway should be chosen this documentation page contains a sum of all differences.

In the following post, we will see how to integrate API Gateway with an AWS Service like S3.

Top comments (0)