Tobias Schmidt
Tobias Schmidt

@tpschmidt_

34 Tweets 1 reads Jan 15, 2023
๐Ÿ“š AWS 1x1 - ๐—”๐—ฃ๐—œ ๐—š๐—ฎ๐˜๐—ฒ๐˜„๐—ฎ๐˜†
Learn about its capabilities & why it's more than just a simple front door for your serverless application โ†“
๐—ง๐—ต๐—ฟ๐—ฒ๐—ฎ๐—ฑ ๐—ข๐˜ƒ๐—ฒ๐—ฟ๐˜ƒ๐—ถ๐—ฒ๐˜„ ๐Ÿงต
โ€ข Introduction
โ€ข The Basics
โ€ข Authorizers
โ€ข Usage Plans
โ€ข Validation
โ€ข Proxy Resources, Proxy Integrations & Service Proxies
โ€ข Error Handling
โ€ข Handling Responses
โ€ข API Types
โ€ข Monitoring
โ€ข Pricing
{ 1 | 32 }
๐—œ๐—ป๐˜๐—ฟ๐—ผ๐—ฑ๐˜‚๐—ฐ๐˜๐—ถ๐—ผ๐—ป
It's easy to think of API Gateway just as an HTTP mediator between a client and an internal AWS service like Lambda.
But there's more to explore as it offers a lot of valuable features.
{ 2 | 32 }
๐—ง๐—ต๐—ฒ ๐—•๐—ฎ๐˜€๐—ถ๐—ฐ๐˜€
API Gateway consists of three major parts:
โ€ข Request Flow
โ€ข Integration
โ€ข Response Flow
The integration is the most important element, as it contains what the client actually wants to do. It can be for example a Lambda function.
{ 3 | 32 }
The ๐—ฅ๐—ฒ๐—พ๐˜‚๐—ฒ๐˜€๐˜ ๐—™๐—น๐—ผ๐˜„ is everything that happens before the integration is triggered, like authentication and authorization processing or request validation.
The ๐—ฅ๐—ฒ๐˜€๐—ฝ๐—ผ๐—ป๐˜€๐—ฒ ๐—™๐—น๐—ผ๐˜„ is everything that comes after the integration, like transformations.
{ 4 | 32 }
๐—”๐˜‚๐˜๐—ต๐—ผ๐—ฟ๐—ถ๐˜‡๐—ฒ๐—ฟ๐˜€
If you want to protect some routes of your API you can make use of Authorizers.
This will protect your downstream services & also allow forwarding of a security context, like the details of the authenticated user.
{ 5 | 32 }
There are different Authorizer types for this step which all look at some aspects of the request to identify the caller & either allow or reject the request.
โ€ข default JWT
โ€ข Cognito User Pool
โ€ข IAM permission-based
โ€ข custom Lambda function
{ 6 | 32 }
๐——๐—ฒ๐—ณ๐—ฎ๐˜‚๐—น๐˜ ๐—๐—ช๐—ง ๐—”๐˜‚๐˜๐—ต๐—ผ๐—ฟ๐—ถ๐˜‡๐—ฒ๐—ฟ
If you're using an identity provider that supports OAuth2 & OpenID (for example Auth0), this is a great option to have a central access control that doesn't require any operations on your side.
{ 7 | 32 }
You basically only need to add the URL of the OpenID configuration endpoint which returns all needed details to AWS that are needed to validate signatures of ๐—son ๐—ชeb ๐—งokens
If the signature is valid & the token is not expired, a security context will be created
{ 8 | 32 }
This context will contain details from the token payload like the claims and scopes.
You can additionally define which route does accept which scopes - without needing to write any code.
Everything is solely about configuration.
{ 9 | 32 }
You can also define your own ๐—ฐ๐˜‚๐˜€๐˜๐—ผ๐—บ ๐—Ÿ๐—ฎ๐—บ๐—ฏ๐—ฑ๐—ฎ ๐—”๐˜‚๐˜๐—ต๐—ผ๐—ฟ๐—ถ๐˜‡๐—ฒ๐—ฟ ๐—ณ๐˜‚๐—ป๐—ฐ๐˜๐—ถ๐—ผ๐—ป.
This function will receive the authorization token. You can do your own validation & return your own authorization context which will be forwarded by API Gateway.
{ 10 | 32 }
๐—จ๐˜€๐—ฎ๐—ด๐—ฒ ๐—ฃ๐—น๐—ฎ๐—ป๐˜€
API keys can be used as a method for rate limiting and throttling certain clients at your API. Define rules about clients:
โ€ข max number of requests per second
โ€ข max number of requests over a certain time period (=> a quota)
{ 11 | 32 }
๐—ฉ๐—ฎ๐—น๐—ถ๐—ฑ๐—ฎ๐˜๐—ถ๐—ผ๐—ป
You can define validation rules directly at the Gateway level, which comes with two benefits:
โ€ข it reduces the number of invocations for your integrations
โ€ข saving boilerplate code at the integration
{ 12 | 32 }
Requests that fail the validation are not forwarded to the backend integration, which therefore saves invocation.
Also, your validation rules on the Gateway will save you code for validations at your backend integration.
{ 13 | 32 }
Validation of ๐—ฃ๐—ฎ๐—ฟ๐—ฎ๐—บ๐—ฒ๐˜๐—ฒ๐—ฟ๐˜€
Define requirements for your API like needed query parameters or headers. If they are not provided by the client, the API Gateway will return an HTTP 400 Bad Request response with a message listing the missing parameters.
{ 14 | 2 }
Validation of ๐—ฅ๐—ฒ๐—พ๐˜‚๐—ฒ๐˜€๐˜ ๐—•๐—ผ๐—ฑ๐—ถ๐—ฒ๐˜€
In addition to validating query strings and headers, you can also choose to have dedicated models for your incoming request payloads.
A model defines what content type is accepted and how the body has to contain.
{ 15 | 32 }
For the body, you define required fields and the types, like ๐˜€๐˜๐—ฟ๐—ถ๐—ป๐—ด or ๐—ถ๐—ป๐˜๐—ฒ๐—ด๐—ฒ๐—ฟ.
All of your validation rules need to be attached to the method request step in the request flow.
{ 16 | 32 }
Let's have a quick wrap up about the different types of '๐—ฝ๐—ฟ๐—ผ๐˜…๐˜†' you'll find in correlation with API Gateway:
โ€ข Proxy Resource/Method
โ€ข Proxy Integration
โ€ข Service Proxy
{ 17 | 32 }
A ๐—ฃ๐—ฟ๐—ผ๐˜…๐˜† ๐—ฅ๐—ฒ๐˜€๐—ผ๐˜‚๐—ฟ๐—ฐ๐—ฒ enables you to bind different HTTP requests to a single integration.
Example:
/api/customers/{๐—ถ๐—ฑ}
It will bind calls to
โ€ข /api/customers/05d02cea
โ€ข /api/customers/a8de
โ€ข /api/customers/8d32a88dd1
{ 18 | 32 }
You can extend the proxy indicator with a + to capture all values that come after.
For the example:
/api/{๐—ฝ๐—ฟ๐—ผ๐˜…๐˜†+}
Will match
โ€ข /api/customers
โ€ข /api/customers/05d02cea/addresses
... and everything else that's under /๐—ฎ๐—ฝ๐—ถ.
{ 19 | 32 }
๐—ฃ๐—ฟ๐—ผ๐˜…๐˜† ๐—œ๐—ป๐˜๐—ฒ๐—ด๐—ฟ๐—ฎ๐˜๐—ถ๐—ผ๐—ป๐˜€
The important part: the actual integration with a backend service.
There are two types:
โ€ข Lambda proxy: forwarding your request to a Lambda function
โ€ข HTTP proxy: forwarding the entire request to an HTTP endpoint.
{ 20 | 32 }
The benefit of using one of those proxy integrations is that you don't require any transformations with mapping templates using the ๐—ฉelocity ๐—งemplate ๐—Ÿanguage (VTL).
{ 21 | 32 }
๐—”๐—ช๐—ฆ ๐—ฆ๐—ฒ๐—ฟ๐˜ƒ๐—ถ๐—ฐ๐—ฒ ๐—ฃ๐—ฟ๐—ผ๐˜…๐˜† ๐—œ๐—ป๐˜๐—ฒ๐—ด๐—ฟ๐—ฎ๐˜๐—ถ๐—ผ๐—ป๐˜€
It's also possible to integrate your API Gateway to another AWS service like DynamoDB, e.g. to insert items.
This is useful for simple data ingestion services which then don't require any maintenance.
{ 22 | 32 }
๐—˜๐—ฟ๐—ฟ๐—ผ๐—ฟ ๐—›๐—ฎ๐—ป๐—ฑ๐—น๐—ถ๐—ป๐—ด
As your request can get rejected for various reasons (missing or invalid Authentication Token, the payload does not match our model, ...), you may want to define how errors are handled and how they are returned to the client.
{ 23 | 32 }
API Gateway has a set of default ๐—ฟ๐—ฒ๐˜€๐—ฝ๐—ผ๐—ป๐˜€๐—ฒ ๐˜๐˜†๐—ฝ๐—ฒ๐˜€ indicating different types of errors.
They contain:
โ€ข response type, parameters & templates
โ€ข the status code
You're able to overwrite those to adapt to your own needs.
{ 24 | 32 }
docs.aws.amazon.com
A common stumbling block is for example that there are by default not CORS headers return for rejected requests, which will lead to errors in frontends that you can't easily handle.
Custom response parameters allow you to define those headers for error responses.
{ 25 | 32 }
๐—›๐—ฎ๐—ป๐—ฑ๐—น๐—ถ๐—ป๐—ด ๐—ฅ๐—ฒ๐˜€๐—ฝ๐—ผ๐—ป๐˜€๐—ฒ๐˜€
If you're not using a proxy integration, we need to define integration responses
Those are the counterpart to our integration request in the request flow and transform the backend responses into something API Gateway can handle
{ 26 | 32 }
This is also done by using the VTL. Additionally, we also need to determine if our integration request was successful or if it returned an error - also finding out which exact error occurred.
{ 27 | 32 }
The last step that follows (also only if not using Lambda or HTTP proxy integrations) is the method response.
They are needed to define:
โ€ข the response status code
โ€ข the response body
that will be returned to the client.
{ 28 | 32 }
๐— ๐—ผ๐—ป๐—ถ๐˜๐—ผ๐—ฟ๐—ถ๐—ป๐—ด
CloudWatch contains a lot of default metrics for our API Gateways.
These include:
โ€ข number of HTTP 4xx and 5xx responses
โ€ข execution & integration errors
โ€ข integration latency
Besides that, you can enable API GW to write logs to CloudWatch
{ 29 | 32 }
๐—ฃ๐—ฟ๐—ถ๐—ฐ๐—ถ๐—ป๐—ด
For the first 12 months, you'll get 1m of API calls per month for free.
It also includes 1m messages & 750k connection minutes for WebSockets.
For more:
โ€ข HTTP APIs: $1.2/m requests
โ€ข REST APIs: $3.5/m requests
โ€ข Sockets: $1.1/m messages
{ 30 | 32 }
You may also leverage third-party tools like Dashbird.io for enhanced monitoring of your API Gateways.
It gives you a real-time overview of all API executions, detects errored requests within them, and lets you quickly identify the root cause.
{ 31 | 32 }
That's it for API Gateway.
๐—–๐—ฟ๐—ฒ๐—ฑ๐—ถ๐˜๐˜€ go to an awesome post by @alexbdebrie
To be honest: I learned a lot here, even though I already knew most things about API Gateway! ๐ŸŽ‰
It's a must-read & covers even more details! ๐Ÿ“š
alexdebrie.com
{ 32 | 32 }
Thank you for reading to the end!
If you've enjoyed this, โ™ป๏ธ or โ™ฅ๏ธ the initial post so other's can see it too.
Also, follow me & @thedashbird if you're interested in regular cloud & serverless content ๐ŸŒค ๐Ÿ™Œ

Loading suggestions...