Are There Boilerplates That Integrate Out-of-the-Box with AWS CDK?

Short answer: yes. But there’s a catch worth understanding before you pick one. Most templates — including many of AWS’s own samples — are piecemeal: you get a frontend with no backend, or a backend with no frontend, or one Lambda as a demo. That’s a very different thing from a boilerplate that’s end to end — app and infrastructure, wired together and deployable with one command. Here’s how to tell them apart.

What “out-of-the-box CDK integration” should actually mean

The bar isn’t whether CDK is present at all — plenty of templates name-drop CDK and still leave you assembling the real app yourself. The bar is whether it’s end to end. A boilerplate that genuinely integrates with AWS CDK should give you all of this on day one:

• The whole topology defined in CDK — DNS, certificates, auth, database, API, and every frontend, not just one Lambda as a demo.
• One-command deploy — a single cdk deploy brings the stacks up in dependency order, and tears them down just as cleanly.
• Separate stacks per concern — so the blast radius of a change is bounded and you can reason about each piece independently.
• Typed cross-stack references — a Cognito pool ID or API URL passed to a frontend as a checked value, not a string you copy by hand.
• App code and infra in one repo and one language — TypeScript end to end, so a change that spans your app and its infrastructure is a single, coherent edit.

Why most “CDK boilerplates” fall short

Search around and you’ll find the same disappointments. Most are piecemeal — and this is especially true of AWS’s own samples, which exist to showcase one service rather than to be a complete app: a frontend with no backend, or a backend with no frontend, each a polished half that leaves the other half (and the wiring between them) as “your problem.” Some use a different IaC tool entirely (Serverless Framework, SAM, or Terraform) and mention CDK only in passing. And some include CDK but only for a single resource — one function, one bucket.

But across all of them, the part that’s actually missing is the same: the auth and API layer, wired end to end. That’s the hard part and the part nobody decides for you — how a user signs in, how that identity reaches your API, and how the frontend, the API, and the auth provider agree on it. A template that hands you a login page and a separate template that hands you an API have each skipped the connective tissue that makes them one app. Picking those pieces and wiring them together is the work, and it’s exactly the work most boilerplates leave on your desk.

The templates that do give you end to end usually do it by hiding the infrastructure behind heavy abstraction — a framework that generates the cloud resources from its own config and conventions, so you can’t see or adjust what it actually deploys without fighting the tool. So you’re left choosing between piecemeal pieces you have to assemble and an opaque framework you have to trust. The thing that’s genuinely rare is end to end without that abstraction: the whole stack, in plain CDK you can read.

What a real one looks like

cdkbase is built CDK-first by design. The entire application is expressed as a topology of nine CDK stacks — DNS, auth, database, API, billing, two MCP servers, and the web SPA and SSR frontends — wired together with typed references. The part everyone else skips is already decided and connected here: Cognito-based auth and the API are wired end to end, so a signed-in user’s identity flows from the frontend through to the API without you choosing a scheme or hand-rolling the glue. The whole thing deploys with one command:

pnpm run deploy   # builds the frontends, then cdk deploy --all

It’s end to end — nothing left as “your problem” — but it gets there without hiding the infrastructure: it’s plain CDK you can open and read. There’s no separate infrastructure project to reconcile and no hand-copied ARNs, and no framework generating resources you can’t see — the same TypeScript that builds your app defines the cloud it runs on. Add a feature and its stack in the same language; remove one by deleting its stack file and folder. Because it’s CDK on CloudFormation, every deploy also leaves an auditable record of exactly what was created — a property an API-driven tool doesn’t give you.

A checklist for evaluating any CDK boilerplate

Before you commit to one, ask:

• Does cdk deploy stand up the entire app, or just a sample?
• Are auth, database, and frontends all defined as CDK stacks?
• Are values passed between stacks as typed references, not manual config?
• Is there one repo and one language, or an app here and infra somewhere else?
• Can you deploy multiple environments (dev/prod) from the same code?

If the answer to those is yes, the CDK integration is real — not a checkbox.

The bottom line

So: yes, boilerplates that integrate out-of-the-box with AWS CDK exist — just hold them to the standard of end to end, “the whole stack deploys with one command,” not a piecemeal half or an opaque framework. That higher bar is exactly what cdkbase is, and it pairs the CDK foundation with auth, billing, a database, and frontends already wired in. See how the stack fits together or the getting-started guide.