5 Reasons Why I’m Moving To A Serverless Architecture on AWS For My Next SaaS Side-Project

2 min readMar 22, 2022

I’ve built my last SaaS, Designvote, using a classic REST server for the backend, and while this was fine initially, small problems kept adding up as time went by.

After playing around in my free time with an AWS serverless solution, here are my top 5 reasons for choosing this architecture for my next venture:

#1 🙋‍♂️Authentication & User Management

In my last project, I used a 3rd party solution for authentication (Auth0), which worked well, but I had to integrate it in both frontend and backend.

I had to duplicate some user data in my own tables, and integration had some friction. This is much easier done with a native serverless solution like Cognito.

#2 🚀GraphQL AppSync

I used REST for my last SaaS, and dabbling with GraphQL has been impressive:

You request only the data you need
You have direct support for subscriptions.
Complete type definitions

#3 🔐 Granular permissions for each endpoint

If you use lambdas or request resolvers, you can specify what resources they can access and what operations they can perform.

Example: The lambda function getUser can only access the Users table and can only perform read operations. This improves security considerably.

#4 🧨Avoids Single point of failure

One error can make your server crash and compromise the entire app in classic back-end servers.

In modern serverless architectures, if a lambda or a resolver malfunctions, this will not propagate to other parts, as they are completely isolated in terms of runtime.

#5 🤑Cheaper

Serverless architectures operate from a Pay-Per-Use model, while classic back-end API servers operate on pay-per-month for the underlying server you are using.

Serverless is far cheaper initially, and with optimizations, even when exceeding 1k sessions/day, you can come out paying less than classic server models.

This post was created with Typeshare