Bringing server and server-less together with AWS API Gateway
By: Balu Vyamajala
Tags: AWS, Cloud Computing, Serverless Architecture, Serverless

In most micro-service architectures, application is broken down into multiple small apis which falls into two categories server or server-less. Blog is about how do we serve such content with web apps using AWS services.

Going fully server-less is not always be a practical

Why not server-less for everything?

My choice is always ‘Go Server-Less’ unless one of the below criteria is met.

Total Run time: An api is heavily used and is constantly running for more than 50% of the time, setting up a server might actually save some cost.

Development Time: Imagine building CRUD Apis for bunch of tables with a framework like Spring Boot vs building multiple NodeJs lambdas for each table. Time needed on former is just 10% of time needed for development and Dev-Ops of the later. Setting up single small server on Fargate is far easier choice.

Datastore type: Managing tcp connection pools to relational database in server-less might get tricky and will add overhead to api performance especially when running Lambdas with in VPC to be able to connect to private RDS or on-prem.

so, most of the times, we end up having a mix of server and server-less.

Imagine we have a relational database running in RDS in a private subnet in our VPC and we need bunch of apis to be exposed with combination of server and server-less. Let’s put together an architecture.

Server-less APIs

AWS Lambda functions, I typically choose a simple NodeJS instead of heavy framework with Java to reduce startup time.

we can run Lambdas within VPC to be able to connect to RDS privately.

Server APIs

Going with Java Spring boot, an easiest of choices, for exposing rest apis built as docker container deployed to AWS ECS Fargate.

Load Balancer

With servers we need to handle scaling, health checks, monitoring cpu usage, etc.

Setting up a AWS ELB to redirect requests to a healthy task.

This can be an internal LB as requests will not be directly from internet but only from Gateway.

Gateway

Public facing AWS Api Gateway to expose apis from both Lambdas and Fargate.

Choose a prefix for Fargate apis and another prefix for apis from Lambda. For example /server and /serverLess

Any api prefix with /server/** should be proxied to ELB and all other endpoints will be sent to individual lambdas.

Api Gateway to Private ELB

Integration from AWS Api Gateway to a private ELB can only be done to a Network Load Balancer.

We must create a Vpc link to NLB and redirect /server/{proxy+} to nlb-dns-name/{proxy} via Integration type ‘VPC Link’

we don’t need TLS Termination at NLB, instead API Gateway will terminate and initiate a new connection to NLB, which simply passed to Fargate services.

Offloading security outside application code always a better choice.

Api Security

Likely to get a Bearer Token like a JWT for most of the Authentication types. It is best to offload activities like token validation and parsing outside the application code instead of implementing something like Spring Security within server code.

We can go with AWS Api Gateway Custom Authorizer to validate the token and set context attributes to pass id information as http headers.

Same custom authorizer works for both server and server-less endpoints

Architecture