Serverless AWS REST API Design Options

Designing and implementing an API in AWS Serverless Application model you use:

• AWS API Gateway for routing, validation =, and authorization of the API Calls to the AWS Lambda implementation
• AWS Cognito for authentication, basically implementing OAuth 2.0 client grant flow
• Parameter Store and AWS KMS to store configurations and connection strings in a secure way.
• Data Store, depending on your app the data store can be relational or non-sql etc.
• AWS Lambda for the implementation of the API.

The AWS Lambda, it basically creates a docker container to service each Lambda Function of the API implementation. With the AWS Lambda API implementation you options of how to divide your API Code:

• Large Size – One Lambda: All the API Code in one Lambda Function, this would mean that the API Gateway would roote /* to your function.
  • Pros:
    • All the code in one place
    • Use your development Language platform, API Library (Spring, Flask etc.) for resource and endpoint routing
  • Cons:
    • The API Gateway Authorization is on there root route any authorization on different resource routes, endpoints you would have to code yourself
    • Depending on the size of your code you will have to choose a very large Lambda Size
    • Since all endpoints are served with same image the image would run for all the calls, depending on the usage this can be almost 24/7, leading to higher costs
• Medium Size – One Lambda per Resources: All the API Code for say /products would exist in one lambda functions. The API Gateway would route to different function depending on /resource/*
  • Pros:
    • All code for a resource and its endpoints in one endpoint
    • Authorization per resource
    • Use you development language platform for endpoint routing
    • cheaper coasts
  • Cons:
    • The API Gateway authorization is on the resource, for endpoints authorization you will have to code this
    • Multiple lambda functions
    • Depending on the code size, you will still have to choose a large Lambda size.
    • All the operation on the resource are served with on lambda which would mean more running time by large lambda size leading to a moderate to a high cost
• Micro Size – One Lambda Function per Endpoint: The API code for each point say Get:/products would exist in one Lambda. The API Gateway would route to a different function for each endpoint.
  • Pros:
    • The API Gateway handles authorization at the EndPoint level
    • Smallest Lambda function size possible for your code can be utilized
    • The Lambda that run most are for the endpoint hit mostly leading to lowest cost possible
    • No need to use a platform framework like (Spring or flask) leading to even smaller code size
    • Easily grant rights on each endpoint or operations (can read can not write for example)
  • Cons:
    • Large Number of Lambda Functions can crowed you Lambda console

I choose Micro Size for a couple of implementations I did, let me know your experience with AWS Lambda sizing.