profile

AWS for the Real World

My fullstack AWS stack in 2026

Published about 1 month 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: 21 minutes 🎯 Main Learning: Same CloudFront logs: 12.5s through Kinesis, S3, Glue and Athena, about 1s through Tinybird's managed ClickHouse. 📝 Blog Post Hey Reader 👋🏽 We've been running Plausible for the analytics on awsfundamentals.com. Good software, no complaints. We still wanted the data to be ours: our retention, our schema, nobody's script in the visitor's browser. So we built the dashboard ourselves. Twice, on two different backends, fed by the same CloudFront logs....

6 days ago • 1 min read

AWS FOR THE REAL WORLD ⏱️ Reading time: 11 minutes 🎯 Main Learning: A Karpenter NodePool is a placement policy, not an instance preference. Pin one instance family, and a Spot shortage moves your fleet across availability zones, where every internal call starts costing $0.01 per GB. 📝 Blog Post Hey Reader 👋🏽 Important off topic things first: Sandro got married! 🎉We were in Munich for it and it was a fantastic day! ☀️Highly recommend a wedding over sprint planning or fighting with AWS...

20 days ago • 3 min read

AWS FOR THE REAL WORLD ⏱️ Reading time: 10 minutes 🎯 Main Learning: Wildcards come from the tooling, not from laziness. Put least privilege at the account level and let an agent write the policies. 📝 Blog Post Hey Reader 👋🏽 I have shipped my share of s3:* at unusual hours and told myself I would refactor it later - which obviously never happened 😅 So when someone on r/aws asked why developers can't write least privilege policies and put it down to laziness, I was excited to read through all...

about 2 months ago • 2 min read