cdkbase
← All posts

How to Build a SaaS on AWS Serverless: The 2026 Stack

8 min readAWSServerlessSaaSArchitecture

Standing up a SaaS on AWS is less about any single service and more about how a dozen of them fit together. This is the stack we reach for in 2026 — fully serverless, pay only for what runs, and shaped so an AI coding agent can extend it without fighting the infrastructure.

Why serverless for a SaaS

The appeal hasn’t changed: no servers to patch, scaling that follows traffic instead of guesswork, and a bill that starts near zero. For an early-stage product, the most valuable property is that idle is cheap. You can run a real production environment for a handful of paying customers without provisioning capacity you don’t use yet, and the same architecture absorbs a launch-day spike without a re-platform.

The catch is integration. Each managed service is straightforward on its own; the work is in auth tokens reaching your API, your API reaching the database, billing webhooks updating entitlements, and all of it deploying reproducibly. That glue is where most “start a SaaS” weekends quietly disappear.

The components

1. Identity — Amazon Cognito

Cognito handles sign-up, sign-in, email verification, password resets, and JWT issuance. The part people underestimate is that different clients want tokens stored differently: a server-rendered web app wants them in HttpOnly cookies, a single-page app typically keeps them in localStorage, and a mobile app belongs in secure device storage. Decide this per surface up front — retrofitting cookie auth onto an app that assumed bearer tokens is painful.

2. Database — Aurora DSQL

For a genuinely serverless data layer, Amazon Aurora DSQL is the most interesting option in 2026: Postgres-compatible, active-active, and it scales to zero so an idle environment costs almost nothing. If you prefer a more familiar operational model, Aurora Serverless v2 or plain RDS still work — but DSQL’s cost curve fits the “many cheap environments” pattern that SaaS teams actually live in.

3. API — Hono on Lambda

A thin, fast HTTP layer beats a heavyweight framework here. Hono runs cleanly on Lambda behind a function URL or API Gateway, gives you typed routing, and keeps cold starts small. Your API’s job is narrow: validate the Cognito token, authorize the request, talk to the database, return JSON. Keep business logic out of the frontends and in here.

4. Billing — Stripe

Stripe Checkout for the purchase flow and Stripe webhooks for the source of truth. The rule that saves you: never trust the browser redirect to grant access. The checkout.session.completed and subscription webhooks are what flip entitlements in your database; the success page is just UX. Verify the webhook signature and make the handler idempotent.

5. Frontends — SSR, SPA, and mobile

Most SaaS products end up needing more than one client: a server-rendered marketing and onboarding site for SEO, an authenticated SPA dashboard, and often a mobile app. They can share an API client and an auth package while differing only in where they keep tokens. Building them on a common contract from day one is far cheaper than unifying three divergent codebases later.

6. Infrastructure — AWS CDK

Define all of it in code. AWS CDK lets you express the whole topology in TypeScript — the same language as the rest of the stack — with real types across stack boundaries. One cdk deploy brings up DNS, certificates, auth, database, API, and frontends in dependency order, and tears them down just as cleanly for ephemeral environments.

How the pieces connect

Browser / App
   │  (Cognito JWT — cookie, localStorage, or secure storage)
   ▼
Hono API on Lambda ──► Aurora DSQL (Postgres)
   ▲
   │  webhooks (entitlements)
Stripe

All of it defined in AWS CDK and deployed per environment.

Nothing here is exotic. The leverage is in having the connections — token formats, the webhook-to-database path, the per-environment deploy — decided once and wired correctly, so you spend your time on the product instead of the plumbing.

The part that’s changed: build it with an agent

The newest shift is that an AI coding agent can own large parts of this stack — adding a billing tier, a table, an endpoint — if the codebase is laid out predictably and documented for it. A consistent structure, a deploy command that just works, and an operating manual the agent can read turn “scaffold a SaaS” from a multi-week project into a first-session conversation. That’s the bet behind shaping the whole template for Claude Code.

Skip the wiring and start from a working stack

cdkbase is a fork-ready AWS serverless template that ships everything in this article — CDK infrastructure, Cognito auth, Aurora DSQL, a Hono API, Stripe billing, and web/SPA/mobile frontends — already wired together and built for Claude Code. See pricing or read the getting-started guide.