AWS Deep Dive
author: Nathan Acks
Amazon API Gateway
Continued notes about the Amazon API Gateway.
Working With HTTP APIs
Throttling Requests to Your HTTP API in API Gateway
Throttling for HTTP APIs is handled in more-or-less the same as with REST APIs.
- Throttling requests to your HTTP API
- 2022-11-17 - AWS Deep Dive (Throttle API Requests for Better API Gateway Throughput)
Configuring Mutual TLS Authentication for an HTTP API in API Gateway
Mutual TLS authentication is handled in more-or-less the same as with REST APIs.
(Note that trust stores are
pem files containing the complete chain of trust for the certificate authority issuing client certificates - it’s not about the client certs at all. I somehow missed this during the earlier discussion.)
- Configuring mutual TLS authentication for an HTTP API
- 2022-11-17 - AWS Deep Dive (Configuring Mutual TLS Authentication for a REST API in API Gateway)
Configuring Logging for an HTTP API in API Gateway
CloudWatch logging for HTTP APIs is similar to REST APIs. Note that
$context.extendedRequestId are identical for HTTP APIs.
- Configuring logging for an HTTP API
- 2022-11-19 - AWS Deep Dive (Setting up CloudWatch Logging for a REST API in API Gateway)
Troubleshooting Issues With HTTP API Lambda Integrations in API Gateway
$context variables for logging:
$context.error.message (the error message generated by API Gateway),
$context.integrationErrorMessage (the error message generated by the backend itself).
Troubleshooting Issues With HTTP API JWT Authorizers in API Gateway
JWT authentication responses from API Gateway include a
www-authenticate header with information about the authentication process (including errors).
Working With WebSocket APIs
WebSocket APIs in API Gateway are always bidirectional. They can be tied to an AWS service (often Lambda or DynamoDB) or to an HTTP backend. JSON messages are directed based on configured routes (which are determined by a specified property in the incoming JSON message), while non-JSON messages are always directed to the
There are also
$disconnect routes that are called automatically when a client, well, connects or disconnects.
Managing Connected Users and Client Apps in API Gateway
WebSocket connections are not finalized until the
$connect request returns success; because WebSocket connections are stateful, this is the only request for which AuthN/AuthZ can be performed. If the
$connect route returns a failure, API Gateway will respond with a 401 or 403 to the client, depending on the type of failure.
$connect route is only required if AuthN/AuthZ needs to be performed, subprotocols need to be specified, or a callback URL needs to be established to push messages to the client.
$disconnect is called after the WebSocket connection close event, so it’s not really clear what the advantage is to setting up this route. Additional logging, maybe?