AWS Fundamentals Logo
AWS Fundamentals
Back to Blog
My fullstack AWS tech stack in 2026

Building apps with AI is easy now, right? One thing that helps me a lot is having one common tech stack across all my projects. I try to not change it up at all anymore, just to stay consistent.

Some features I love about my tech stack are simple.

  • Simplicity - It shouldn't require a lot to understand that
  • Maintainable - It should be easy to maintain this tech stack in the future
  • Longevity - I want that the tech stack can live, evolve, and survive out there!

There are some main components of a fullstack application where you need a service, framework, or other for. These are:

  • Backend: Where does your API live
  • Database: What kind of database do you use?
  • Frontend: The website your users are interacting with. This includes styling for me
  • Deployment: How do you deploy your overall application - often this is referred to frontend only. But for me it is the whole app.
  • Async: How do you run stuff in the background?
  • Authentication: How can your users authenticate?

Let's go through each and every category to see why I'm using what I use

Backend - Lambda with Hono API

I fell in love with Hono API. It is simple, it has a known chain syntax, is type-safe, and I can simply do a lot with it.

Look at that code and tell me you don't understand what it is doing:

app.post('/purchase', zValidator('json', analyticsIngestSchema), async (c) => {
    l.info('Purchase tracking request received');
    const { orderId, referrer, pagePath, utmParameters } = c.req.valid('json');

Hono API follows a chain syntax pretty similar to Express API. You can write custom middlewares, but Hono comes already with tons of middlewares.

My deployment of the API is typically in a Lambda Function. Either a function URL or behind an /* integration on API Gateway.

I love having a RPC App Client of my Hono API exported to my frontend. With that even my frontend has a type-safe API client which is completely underrated.

export type AppType = typeof routes;
const client = hc<AppType>(API_URL);


client.admin.stats.$get().then((res) => {
  if (res.ok) {
    res.json().then((data) => {

All of the above is completely typesafe now!

Alternatives I used in the past and don't want to use anymroe:

  • AppSync: GraphQL can be nice. But honestly it overcomplicates things, caching can be hard, and not everybody knows it. Just go with REST.
  • TRPC: Same thing. Just too complicated to set up.
  • Direct Integrations (VTL): Horrible too debug. Nobody understands it. Nobody knows it.
AWS Lambda Infographic

AWS Lambda on One Page (No Fluff)

Skip the 300-page docs. Our Lambda cheat sheet covers everything from cold starts to concurrency limits - the stuff we actually use daily.

HD quality, print-friendly. Stick it next to your desk.

Privacy Policy
By entering your email, you are opting in for our twice-a-month AWS newsletter. Once in a while, we'll promote our paid products. We'll never send you spam or sell your data.

Database - Postgres

I changed my approach on databases a lot in the past. I was a huge DynamoDB & Single Table Design fan. But honestly, NoSQL is just not meant for 95% of all applications.

Explain to your stakeholders, why it is that hard to count how many users are there with the name Alex. This can't be that hard, right?

I love using SQL. It forces you to think about your data. How it relates to each other, which type it can be, and what happens if you delete something.

I always go with RDS & Postgres now. If I don't go all in with AWS I use Supabase or Planetscale. But on AWS I simply go with RDS and thats it.

For ORM I always go with Drizzle. Drizzle is also fully type-safe, has an amazing community, and has so many capabilities which is amazing.

I use Drizzle completely for migrations, looking at my data (studio), and for interacting reading & writing to my database.

Frontend - TanStack Start SPA only

Also with my frontend technologies I went full circle.

PHP / HTML Fully server rendered -> React client-side only -> React with server-side rendering -> Fully static with Gatsby -> Client-side only

Now, each project for me is:

  • Vite
  • React
  • TanStack Start SPA only

I don't need or want server-side rendering. I want a webpage with some loading indicators (now called suspense 🧙🏽) and that's it. It should login, authenticate with an API, and get data from this API.

Deployment - CDK, CloudFront, S3, Lambda

For deployment I'm almost always use the following:

  • CDK for defining my infrastructure. Battle-tested, not perfect, but good enough
  • CloudFront & S3 for hosting my frontend application (SPA only so no extra backend needed)
  • Lambda for hosting my API

Nothing fancy. If I require shorter cold-starts (e.g. for my Shopify apps) I host my API in a container. This could be even more simplified and be cheaper but currently I'm quite happy with this setup.

Async - EventBridge & SQS

Once your application evolves you will need to have some asynchronous workloads, believe me. Some examples where I need them:

  • Incoming webhooks (orders from eCommerce)
  • Cron Jobs
  • Payments that failed

I love to integrate them with AWS Partners in EventBridge. For example, Stripe & Shopify have a native integration of their events into EventBridge. These events are free. I can listen to them and attach a Lambda function or SQS queue to this event.

Typically, for "low-scale" events I just attach a Lambda function which listens to these events. For "higher-scale" events such as orders I add a SQS queue which works on events in batches.

This is a perfect scalable setup and is surprisingly minimal, once you've figured it out.

Authentication

Here I have again two replies:

  • Fully AWS: Cognito
  • Free to choose: Better Auth

I love better auth. It is kind of a self-hosted authentication. But it is so freaking simple.

Cognito comes with User Pools, Identity Pools, Settings for each, Duplicated Users, App Clients, Hosted Pages, etc.

Better Auth just gives you integrations for nearly every login possible. And also plugins to make things super straightforward like

  • multi-tenancy
  • roles & scopes
  • admins

Better Auth is optionated. But I think in a very good way. So, I can only recommend it!

Summary

That is it! This is the tech stack I use for every new project by now. I "bundle" everything together in one pnpm workspace.

I have an example project lying on my disk. Once I start a new project I simply tell claude to copy this exacty project structure. And I can get started working on it right away.

Learn AWS for the real world