AWS Blocks Is Too Little, Too Late

Before we get to the latest announcement, here are some of the past attempts AWS has made to simplify backend development:

AWS Blocks is the newest attempt at the same category.

AWS announced AWS Blocks in preview earlier this week: an open-source TypeScript framework that runs a full backend locally — Postgres, auth, storage, and real-time messaging — and deploys to AWS without changing your code. AI agents and observability are in the box too. CDK is available as the option when you need to customize or extend.

The overall concept of the offering tells me it would have been very valuable option a few years ago but isn't that appealing right now.

What has changed recently?

Over the last few years, a lot of startups have emerged with better offerings for specific layers of the backend stack.

• Vercel for frontend hosting and edge serverless.
• Supabase for Postgres + auth + real-time + storage as a single managed product.
• Neon for serverless Postgres specifically.
• Auth0 for production identity (Clerk is now eating the modern-stack slice).
• Cloudflare for edge runtime, R2, and the broader Workers ecosystem.
• Resend for transactional email API.

Each one has become very popular and has become developer preferred product for their specific use case.

Now, let's look at what AWS Blocks offers. Its local environment is Postgres + auth + real-time messaging. That's the Supabase product spec, line for line. AWS shipped “AWS's Supabase, plus you also have to learn CDK when the abstraction leaks.” Builders already know how to reach for the original.

Local-first is not a trending preference

The framing — develop locally, deploy when ready — felt fresh around 2022. Today, it is just not the case. Builders want working and reachable on day one — the URL, the auth, the database, the deploy, all done. Vercel and Supabase nailed this pattern: there's no “local-first” step; first is on the internet. With AI code generation tools, the whole process can be done in an hour.

A local-first dev loop in 2026 is probably an unnecessary friction, and not a feature, for certain audiences. The faster the deploy story, the better the developer experience.

The foundational pieces are few years late

The foundational building blocks of the backend stack — hosting, database, auth, storage, APIs, observability — could have been shipped in 2022, because AWS already had those services, which is currently used behind the blocks. Now, every one of these layers has a specialized leader with a dedicated audience and at the same time AI coding agents are capable of solving most of the problem for these individual layers. AWS Blocks is fighting on already-conceded territory. They tried to do this in bits and pieces with Amplify Gen 1 or App Runner but that didn't really get good attention.

The AI agent piece could have been genuinely interesting, except there's already a full AI-routing layer (OpenRouter, LLM aggregators, half a dozen production agent runtimes). AWS arrived on this layer late too. Different reason, same outcome.

But I want to make a case for Bedrock as AI Gateway and other Bedrock features, a genuinely good service, we heavily use and prefer for most of our AWS-native solutions.

Being the wrapper has its own problems

The Blocks reference documentation gives you three auth tiers:

AuthBasic — username/password with JWT. Use for prototypes and internal tools.
AuthOIDC — OIDC sign-in. Use for social login.
AuthCognito — Production-grade auth with MFA, social, SAML, and passkeys. Use for production applications.

Read the last line again. It explicitly routes users to use AWS Cognito for any production application. Which means the moment your prototype grows real — you are learning Cognito. User Pool vs Identity Pool. Hosted UI vs custom. SES sandbox to production for verification emails. The leak is built into the product.

The same logic extends through every “real production” path the abstraction will eventually demand: IAM, VPC, ALB, RDS Proxy, NAT Gateway, the works. As that's how AWS infrastructure is architected.

The customization issue

Every infrastructure abstraction really needs customization at some point. The customization path here is CDK — meaning the moment you want anything Blocks doesn't ship out of the box, you write CDK. So you're still learning AWS, just through a different pattern.

A good abstraction makes the underlying primitives feel optional.

Who is this for?

If you already use AWS, you have your own patterns and your own opinions and you're not switching to Blocks. If you're new to backend infrastructure, you're already reaching for Vercel + Supabase + Clerk + Resend + OpenRouter — the stacks builders are actually reaching for in 2026 — and AWS Blocks isn't on that list.

The existing AWS user won't migrate. The new-stack user has no reason to choose this over the dedicated providers. Who is this for?

I don't have an answer. We will have to wait and see.

Good abstractions earn trust by hiding complex things consistently. You don't have to peek behind Vercel to ship a Next.js app. You don't have to peek behind Supabase to ship a Postgres-backed app with auth.

A better abstraction for AWS would be to provide a knowledge base of best practices and patterns for each of the services and how to use them together, ultimately AWS has the experience of building, running, managing these services in the most simple to most complex scenarios - they have the perfect runbooks, they know what can go wrong, they know how to fix it. They should provide this knowledge to the users in a way that is easy to consume and use.

AI is already eating the abstractions, one by one, from the top to the bottom.