profile

AWS for the Real World

My fullstack AWS stack in 2026

Published 3 months ago • 2 min read
AWS FOR THE REAL WORLD
⏱️
Reading time: 6 minutes
🎯
Main Learning: One stack, reused for every project. Hono on Lambda, Postgres with Drizzle, a TanStack SPA on S3 and CloudFront, and Better Auth for login.
📝

Hey Reader 👋🏽
we've build a lot of fullstack applications so far:

  • client projects
  • side projects (this one, shopify apps, etc.)
  • example tutorial apps

Over the past few years we switched up tech stacks a lot. That taught us what actually matters in a stack and what is just noise.
Three things I want from mine:

  • Simplicity. It shouldn't take much to understand it.
  • Maintainable. It should still be easy to work on in a year.
  • Longevity. I want the stack to live, evolve, and survive out there.

We stopped switching the tech stack.

Every project gets almost the same tech stack now.

And this is the one.

Sponsored
Four data stores, or one
Oracle AI Database does text extraction, embeddings, and vector search inside the engine
Browser to CloudFront to Lambda to Oracle AI Database, with S3 serving the frontend

I built a document processor. It takes purchase orders, delivery notes, and invoices, classifies them, and pulls out the fields. Normally that needs four data stores. S3 for the blobs, DynamoDB for the key/values, Pinecone for the vectors, Postgres for the aggregations. This one runs on a single database.

Text extraction, summaries, embeddings, and the LLM call that returns structured JSON all run inside Oracle through DBMS_VECTOR_CHAIN. Classification is a k-NN vote over VECTOR_DISTANCE, so no LLM call at all. AWS just provides the compute.

Same stack as this issue. Hono on Lambda, TanStack SPA, CDK  •  Runs on the Always Free tier

Read the full write-up →

Sponsored by Oracle. I built and ran the demo myself.

My fullstack AWS stack, drawn as a tower of six blocks

📚 This Week's Deep Dive

Every fullstack app needs an answer for six things: backend, database, frontend, deployment, async, and auth. Here is mine, and I give the same answer every time now.

Backend, Hono on Lambda

One monolithic Lambda function, behind a function URL or a single API Gateway integration. Easy to test, easy to debug. The part people sleep on is the RPC client: export the route types and your frontend gets a fully type-safe API client for free.

Database, Postgres with Drizzle

I was a big DynamoDB and Single Table Design fan. I changed my mind. NoSQL is not what 95% of applications need. Try explaining to a stakeholder why counting users named Alex is hard. SQL forces you to think about your data up front, and Drizzle handles migrations, studio, and queries.

Frontend, a SPA and nothing more

Vite, React, TanStack Start in SPA mode. I went full circle on this one: server rendered, then client only, then SSR, then static, and back to client only. I don't want server-side rendering. I want a page that logs in, calls an API, and shows a loading state.

Deployment, CDK with CloudFront, S3, Lambda

Nothing fancy. CDK for the infrastructure, S3 and CloudFront for the SPA, Lambda for the API, GitHub Actions to ship it on git push. When cold starts matter, the API moves to a container on ECS Fargate.

Async, EventBridge and SQS

Stripe and Shopify push their events natively into EventBridge, and those events are free. Low volume gets a Lambda on the rule. Higher volume gets an SQS queue in front so it batches.

Auth, Better Auth or Cognito

All in on AWS means Cognito, with its User Pools, Identity Pools, app clients, and hosted pages. Free to choose means Better Auth. It is opinionated, in a good way, and the plugins cover multi-tenancy, roles and scopes, and admins.

What I dropped

AppSync, because GraphQL overcomplicates things and caching gets hard. tRPC, too much setup. VTL direct integrations, horrible to debug and nobody on the team knows them. REST is fine.

How does your stack look?
I love reusing this one over and over. As devs we do need to keep learning, no argument there. But some things like REST, SQL, Lambda are settled enough that switching costs more than it gives back.
Have a great week ahead and talk to you next week!
Best Sandro & Tobi ✌🏽

AWS for the Real World

by Tobi & Sandro

We teach AWS for the real world - not for certifications. Join more than 10,500 developers learning how to build real-world applications on AWS.

Read more from AWS for the Real World

⏱️ Reading time: 15 minutes 🎯 Main Learning: A public container on AWS for $7 a month, with no VPC to own. 📝 Blog Post 🤝 Sponsored by AWS. What we built, what it cost and what we think of it are our own. Hey Reader 👋🏽 Your first container on ECS comes with homework: a VPC, subnets in two Availability Zones, a load balancer, security groups, a certificate and a task role. Express Mode creates most of it for you now (App Runner's successor, so ECS abstraction number three), but it all lands in...

5 days ago • 2 min read

AWS FOR THE REAL WORLD ⏱️ Reading time: 6 minutes 🎯 Main Learning: You cannot skip a level of AWS observability. Structured logs come first, then the AI agent that reads them for you. 📝 Blog Post 📂 Claude Code agent (free gist) 🎬 Watch on YouTube Hey Reader 👋🏽 This week I'm bringing back one of our most-read posts: the 3 levels of AWS observability. A lot of you joined after it went out in May, and the topic fits this week perfectly. Because the real question isn't "do I have logs?" anymore....

18 days ago • 2 min read

AWS FOR THE REAL WORLD ⏱️ Reading time: 10 minutes 🎯 Main Learning: Every convenience layer AWS built on ECS is dead or dying, while ECS itself has not changed since 2014. Build on the primitive, and make the layer above it prove itself first. 📝 Blog Post Hey Reader 👋🏽 Getting started with an AWS service often feels more complicated than it should. Four concepts must be understood before a single container runs. A VPC is required before a single request. So, the fancy CLI that promises to do...

about 1 month ago • 3 min read