profile

AWS for the Real World

My fullstack AWS stack in 2026

Published about 2 hours 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

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...

6 days agoΒ β€’Β 2 min read

AWS FOR THE REAL WORLD ⏱️ Reading time: 11 minutes 🎯 Main Learning: Most teams should stay serverless. EKS only pays off at real scale. πŸ“ Blog Post Hey Reader πŸ‘‹πŸ½For years we told everyone the same thing: don't run Kubernetes! And we meant it. Running k8s yourself is a second full-time job. Cluster upgrades, etcd backups, some networking plugin that falls over on a Tuesday and nobody can say why.We're serverless people through and through. Lambda first, a queue behind it, scale to zero, go...

about 2 months agoΒ β€’Β 3 min read

AWS FOR THE REAL WORLD ⏱️ Reading time: 12 minutes 🎯 Main Learning: Most of the complaints in the viral "leaving AWS" post are skill issues β€” but egress pricing is a fair hit. πŸ“ Blog Post Hey Reader πŸ‘‹πŸ½Recently, a post with the title "I returned to AWS and was reminded why I left" hit 810 upvotes on Hacker News last week and went pretty viral with it.I read it twice before forming an opinion. My honest take: most of the complaints are skill issues! πŸ€·β™‚οΈNevertheless, the post is well written and...

3 months agoΒ β€’Β 2 min read