AWS Deep Dive

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.

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 Logging for an HTTP API in API Gateway

CloudWatch logging for HTTP APIs is similar to REST APIs. Note that $context.requestId and $context.extendedRequestId are identical for HTTP APIs.

Troubleshooting Issues With HTTP API Lambda Integrations in API Gateway

Some useful $context variables for logging: $context.error.responseType, $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 $default route.

There are also $connect and $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.

The $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.

Note that $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?