AWS API Gateway is extremely powerful and easy to deploy. You don’t have to manage any infrastructure (i.e. no purchasing, scaling, patching), the gateway is capable of handling tens of thousands of requests per second, and you only pay a very small price based on the number of requests served . In addition, it also provides many other functionalities, such as managed websocket support.
One of these lesser-known, but potentially very useful, functionalities of API Gateway is its service integrations, which give you the ability to connect API gateway directly to other AWS services, such as dynamodb, sqs, step functions or sns (not just lambda). A standard pattern is API gateway -> lambda -> sns (or some middleware or end point service such as S3, DynamoDB, SQS etc.)
Example: Api gateway -> lambda -> middleware (i.e. sns)
With this approach, API gateway triggers a (nodejs) lambda, which performs validation, and if the request is valid, it publishes an event to the sns topic.
The folder containing all of the project code including the SAM or Serverless Application Model template which provisions the architecture can be found here.
Here is the evaluation of this design using the six pillars
reliability
- we can do more complex validation in lambda — this means we can do more validation before publishing an event
cost optimization
- less repeatedly failed requests—since API gateway validation does not give indicative error messages, as well as it short-circuits on the first error, users will often end up making multiple requests before sending a valid request (see Contrasting Error Responses section)
NOTE: this could accrue negligibly more cost than API gateway directly to lambda, but this is likely only a few cents per month. You refer to the Cost Evaluation section for more analysis.
Default is to use API gateway -> lambda -> middleware (i.e. sns).
While this architecture might incur slightly more cost and slightly more overhead, the p99 latency is still under 300ms, and the benefits given by this solution outweigh these slight drawbacks.
Some of these benefits include the flexibility of doing custom (or more complex) validation, the saving of engineer’s time, as they can use whatever language they like within AWS lambda instead of learning how to transform requests using apache templates in cloudformation, as well as the ability to provide clients with more helpful error messages, as well as all error messages at once (this saves them from getting frustrated and leaving our site, or at least saves us from them making multiple calls).
The one drawback to watch out for is if this lambda is called frequently and it ends up consuming a lot of concurrency, some ways to mitigate this include:
- make sure most functions are triggered asynchronously, so that they can be retried when throttled
- request an increase on the concurrency limit on your account
- if needed, you can play around with reserved concurrency for lambdas
The only time to use an API gateway direct service integration is if the API is extremely high traffic and we are concerned about saving a few dollars, or we see throttles on synchronously invoked functions which cannot be made asynchronous.