Hi Reader 👋🏽,

I hope you are alright and you're enjoying the summer.

Tobi & I are currently thinking hard about what comes next. In the past few months, we focused on publishing more content on our blog & social media. We want to have as much high-quality content covering AWS as possible. But we do see a lack of hands-on projects that can be used in the real world. We're not only talking about a simple API with a Lambda function. But about projects that are required if you work for a company. Setting up a landing zone, configuring the identity center (SSO), and setting up a proper development workflow with sandbox accounts. We feel like this is missing a lot. We'll probably focus on that in the near future 👀

Enough about our thoughts, let's dive right into today's topic: API Gateway.

Infographic

Here is a one-pager about API Gateway.

Introduction

AWS API Gateway is a fully-managed API from AWS. It is a crucial part of your serverless applications because it acts as the front door to the internet.

AWS API Gateway has a lot of different options and configuration opportunities. For example:

• Access Control - Securely authenticate and authorize requests to your APIs.
• Data Transformations - Easily modify and transform request and response data to fit different backend services.
• Rate-Limiting - Control the number of requests from external sources to prevent abuse.
• Versatility - API Gateway works with AWS services and any backend that speaks HTTP.

API Gateway is beginner-friendly as it’s easy to deploy your first API and there are no upfront or idling costs you need to fear.

Finding the Right Gateway Type

AWS API Gateway comes in three different flavors, with very different feature sets and different pricing. A small wrap-up before going into details:

• REST - a collection of HTTP resources and methods that map down to other AWS services like Lambda. It’s the most common and flexible gateway type and does help you to do many otherwise tedious tasks like request validation or data transformations without writing any code.
• HTTP - comparable to REST, but comes with a reduced set of features. It’s drastically cheaper though and easier to set up in the first place — a preferable choice for most Serverless applications.
• WebSockets - for building real-time applications with the publish/subscribe pattern. It allows you to push messages via steadily open communication channels in both directions. AWS API Gateway does the heavy lifting of managing your connections so you can focus on building your application.

The Life of a Request in API Gateway

As said before, API Gateway is not just an HTTP mediator - it’s a feature-rich, high-value, and little error-prone front door to your applications ecosystem.

When working with REST or HTTP gateways, an API consists of programmable resources that can be mapped to specific HTTP methods and paths. These resources are connected to integration endpoints where requests are forwarded. Transformations can be applied to modify requests according to the backend's expectations, including validations. After receiving the response from the integration, response transformations can be applied before returning it to the client.

• Endpoint creation - Setting up an API and configuring HTTP routes and methods.
• Access Control - Authenticating and authorizing requests to protect APIs and enable secure multi-tenant usage.
• Integrations - Integrating API methods with backends, such as Lambda functions or other HTTP-speaking endpoints.
• Request Validation - Validating requests before forwarding them to the destination, reducing boilerplate code in backends.
• Data Transformations - Applying data mapping templates to automatically convert request data to expected inputs.
• Gateway Responses - Applying mappings to convert outputs to expected responses.
• CORS - Setting up cross-domain rules to allow integration of API endpoints in different web touchpoints.
• Deploying APIs - Deploying APIs to make them accessible on the internet.
• Caching - Caching requests to reduce latencies.
• Monitoring - Tracking requests made to API endpoints.

Authorization

API Gateway provides powerful authorizer capabilities for authentication and authorization. Let's explore two key options:

1. JWT Default Authorizer - This authorizer simplifies OAuth2 integration by leveraging JSON Web Tokens (JWTs) and OpenID Connect. When configured with the OpenID configuration URL, API Gateway automatically validates incoming JWTs. This is the go-to authentication on the modern web.
   It checks the token's signature and expiration, ensuring its authenticity and validity. Requests failing these checks are declined with an HTTP 401 response, while authenticated and authorized requests are enhanced with an authorization context and forwarded to the integration. This authorizer is available for AWS HTTP Gateway and doesn't require any custom code.
2. Lambda Authorizers: For REST gateway types or advanced customization, Lambda Authorizers provide limitless possibilities. You can create custom Lambda functions to handle authentication and authorization. Within the Lambda function, you have full control to authenticate the request and generate a policy that either allows or denies invocation.
   ​
   This can be especially useful when you're not building a completely new system but you need to rely on some legacy or third-party.
   The Lambda function can utilize external libraries like jsonwebtoken for token validation and can make API calls or access other AWS services based on the authentication context. Lambda Authorizers offer flexibility and enable complex authentication and authorization scenarios.

By leveraging these authorizers, you can secure your APIs, protect routes and methods, and customize the authentication and authorization process to suit your specific requirements.

Use Cases

We’ve learned about the different API Gateway types, which leads us to two prominent use cases.

Exposing your Serverless Applications to the Internet

The typical web application is a client-server combination: a frontend, e.g. a web page or a mobile app. A backend server to communicate with the frontend.

On the serverless side, your backend is a construct of one or multiple Lambda functions that include your business logic. Exposing those functions to the internet is done via a REST or HTTP API Gateway that allows you to actively enforce rate-limiting, request validation, transformation, routing, authentication, and authorization without writing much or any code at all.

Real-Time Communication Between Your Clients and Your Backends

Many applications require real-time communication between the clients and the backend. If you look at messaging apps, you don’t want all your clients to actively poll for new messages every few seconds as it causes unnecessary server load and also causes a high latency between a message that has been sent and the actual delivery at the receiver.

With WebSockets API Gateway a client can open a connection to the gateway that is fully managed by the gateway itself. The only thing that needs to be actively implemented is how connection events are handled and what you want to do with those connections. A common pattern is to save the connection identifiers that are provided by the gateway to DynamoDB. Via a connection identifier, you can actively push messages to the corresponding client.

Thats it ✌🏽

We hope you enjoyed this issue. Let us know what you think about this issue and our future plans with the AWS Fundamentals Community 👯