Serverless AWS REST API Design Options

AWS Serverless 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.

An EndPoint is the operation on the API plus the resource.

Example Post: /users

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.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: