profile

AWS for the Real World

Demystifying AWS API Gateway: The Front Door to Your Application πŸ›οΈ

Published about 1 year agoΒ β€’Β 4 min read

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 πŸ‘―

​

AWS for the Real World

by Tobi & Sandro

Join our community of over 8,800 readers delving into AWS. We highlight real-world best practices through easy-to-understand visualizations and one-pagers. Expect a fresh newsletter edition every two weeks.

Read more from AWS for the Real World

βŒ› Reading time: 11.5 minutes πŸŽ“ Main Learning: Host Web Applications on AWS with the CloudFront Hosting Toolkit πŸ‘¨πŸ½πŸ’» GitHub Code πŸ“ Blog Post Hey Reader πŸ‘‹πŸ½ Happy New Week! I (Sandro) will attend the Serverless Days in Milano next week where Jeremy Daley will hold the keynote. I look forward to meeting many of you and the overall AWS community. This week's newsletter is all about hosting your frontend on AWS. AWS launched a new way of deploying your frontend to it: The CloudFront Hosting Toolkit....

10 days agoΒ β€’Β 6 min read

βŒ› Reading time: 7 minutes πŸŽ“ Main Learning: Visual Regression Testing with AWS CloudWatch Synthetics πŸ‘¨πŸ½πŸ’» GitHub Code πŸ“ Blog Post Hey Reader Keeping your website running smoothly is important.It's also important to keep an eye on its visual appearance and that it doesn't change due to an unwanted change. AWS CloudWatch Synthetic Canaries is a tool that helps you check on your websites (and APIs!) to make sure it’s working well and look as expected. In this newsletter, we’re going to show you...

about 1 month agoΒ β€’Β 4 min read

Hi Reader and happy May the 4th ⭐. We want to start the spring by giving you an amazing discount on our book and other resources. For that, we have partnered with four different AWS Creators around the globe. You can use the code AWSFUND30 to get 30% off. The resources are: πŸ“™ AWS Fundamentals - Like this newsletter, it covers the basics of essential AWS Services for real-world applications. πŸ“˜ The DynamoDB Book - Level up your DynamoDB modeling and finally understand Single-Table Design. πŸ—οΈ...

about 2 months agoΒ β€’Β 1 min read
Share this post