What AWS Blocks Is Really For
AWS says it built Blocks for AI agents. I think it had two other goals in mind.
Blocks went into public preview in June 2026, and the official pitch is interesting precisely for what it leads with. It doesn't open with "ship faster" or "less boilerplate." It opens by assuming an AI agent is the one writing your backend, and positions itself as the framework that keeps that agent on the rails. That's a real goal, and I'll come back to it.
But I read two other goals into the launch, and AWS won't put either on the announcement slide. The first is lowering the barrier to entry so that more developers can stand up production infrastructure without a cloud specialist holding their hand. The second is gravity. Once your application code is your infrastructure, leaving the ecosystem stops being a migration and starts being a rewrite.
There's a why-now underneath both goals, and I'd bet it's competitive. For years AWS owned the primitives and let the developer experience slip to a layer of platforms sitting on top of it. Vercel is the obvious one, with SST and Encore Cloud playing the same game. They give developers the deploy-in-one-command experience AWS never quite managed, and a lot of them run on AWS underneath while billing you for it. Blocks reads as AWS deciding it wants that layer back.
I'm suspicious of the second goal. I'm also fairly convinced this is the right direction. Both things are true at once, and that's what makes Blocks worth talking about.
What Blocks actually is
Blocks is an open-source TypeScript framework where the code you write for your backend becomes the AWS infrastructure that runs it. The industry term for this is Infrastructure-from-Code (IFC), and it's a different animal from the Infrastructure-as-Code (IaC) we're used to.
With IaC, you declare your infrastructure in a separate place from your application. A Terraform file or a CDK stack describes a database, and your app code consumes it. With IFC, the infrastructure grows out of the app. You instantiate a key-value store in your code, and at deploy time that line is a DynamoDB table.
None of this is brand new, which AWS's framing quietly skips over. Encore.ts and Nitric have done Infrastructure-from-Code for a few years. You declare a database or a queue as a typed object in your app code and the framework provisions it. Encore runs a real Postgres locally and maps the same declarations to RDS on deploy, and it already pitches itself as backend infrastructure "for humans and agents," which should sound familiar. Nitric goes multi-cloud by compiling those declarations down to Terraform or Pulumi underneath. The pattern has been proven for a while, and it stayed niche.
You get composable primitives across the usual categories: KVStore, Database, and FileBucket for data, AuthBasic and AuthCognito for auth, CronJob and AsyncJob for compute, plus Agent and KnowledgeBase for the AI side. Run npm run dev and you get a working app locally with a Postgres database and authentication, no AWS account required. Deploy, and the same code runs on Lambda, DynamoDB, Aurora, and Bedrock with no changes.
Why tying code to infrastructure is a good idea
I spent eleven years running Simpli, a software house that delivered 50+ products for clients of every size. The thing nobody tells you about that model is how much of the work is plumbing that has nothing to do with the product. Every new app meant wiring up the same backend scaffolding, and someone on the team babysitting a deploy that drifted from what the code assumed. A small team can't staff a dedicated infra person per project, so the knowledge lived in one or two heads, and those heads became bottlenecks.
The real problem with how most of us handle infrastructure today isn't the tooling. Terraform and CDK are genuinely good, explicit and reviewable. The trouble is that they keep infrastructure in a separate mental model from the application. You describe a table in one file, consume it in another, and over time the two drift apart. The developer writing the feature has to hold both models in their head and keep them in sync by hand.
Blocks collapses that gap. When the table definition and the code that reads from it are the same construct, they can't drift. For a working developer that's a genuine ergonomic win.
What the code looks like
Here's the shape of it, roughly as the preview API reads today:
import { KVStore, AuthBasic } from "aws-blocks";
const auth = new AuthBasic(app, "auth");
const todos = new KVStore(app, "todos");
export const addTodo = auth.handler(async (user, text: string) => {
await todos.put(`${user.id}:${Date.now()}`, { text, done: false });
});
Locally, todos is an in-memory store and addTodo is just a function you can call from a test. On deploy, that same KVStore becomes a DynamoDB table and the handler becomes a Lambda behind API Gateway. One declaration, different behavior in each context. That's the whole pitch in five lines.
The catches, and the escape hatches
The loudest concern I see from developers is the one I'd raise myself. When new KVStore(...) quietly provisions cloud resources, deleting that line reaches into your live infrastructure. What happens to the underlying table and its data then depends on the removal policy Blocks assigns. CDK's own default is to retain stateful resources, so you'd more likely orphan the table than wipe it, but in a preview framework I wouldn't stake production data on a default I hadn't checked myself.
The abstraction is convenient until it leaks, and abstractions always leak eventually. I wrote about where this kind of indirection stops paying for itself in a different context, and the lesson transfers. An abstraction is a tool you reach for when it earns its place.
To its credit, Blocks doesn't pretend the abstraction is total. There are honest escape hatches. You can drop into raw CDK in an index.cdk.ts file to wire up a service Blocks doesn't cover yet, like SQS. fromExisting wraps resources you've already deployed. And when you need full control, you can vendorize a Block, pulling its source into your repo. The common case is automated and the specific case stays reachable, which is the right shape for something aimed at production.
AWS's product page promises "no ceiling on what you can build." I'd push back on that. Today, every API method runs inside a single Lambda, the so-called Lambda-lith, with one memory ceiling and one timeout for everything. That's fine for a prototype or a small-to-medium API. It is not a microservices architecture, and pretending otherwise would set teams up for a painful rewrite.
To be fair, the single Lambda is just the current default. Anything you model as an AsyncJob or CronJob already deploys as its own function, so you can peel heavy work off the lith today, and the raw-CDK escape hatch lets you stand up more compute by hand. What Blocks won't do for you yet is split the API surface itself into per-method functions, so granular scaling and IAM per endpoint aren't on the table. The developers who've dug into it expect that to change, and so do I. I just wouldn't design around a promise.
The AI-agent premise, and where it ties to my own work
The part of the pitch I keep coming back to is the agent framing. Blocks ships with steering files that guide a coding agent toward correct architecture without custom setup. You prompt "add authentication and a database," and the framework constrains the agent so the output actually deploys to production-grade services instead of something that compiles and then falls over.
I find that compelling because I've built the same idea at a smaller scale. At Mosaic, we worked on pre-audited, composable smart contract modules with AI tooling that generated contract compositions from natural language. The whole point was to give the agent a safe vocabulary so a non-expert could assemble something sound. Blocks is doing that for AWS backends. It's also the argument I made in Discovery and Spec. If an agent is going to write your code, the leverage is in constraining it before the first line. Reviewing the mess afterward is the expensive path.
So when AWS attaches its name to "the correct way to let an agent build a backend," I think the standardizing effect is real. The weight of that name will push IFC from a niche idea toward a default, the same way it does with most things AWS commits to.
Where I land
Lowering the infrastructure barrier doesn't make infra specialists less important. It changes who you call them for. The abstraction handles the common path, and you bring in the person who understands DynamoDB access patterns or the Lambda-lith's limits exactly when the abstraction leaks. At 33Labs I came to a similar conviction about security. The expert's value shows up at the architecture stage, underneath the easy path, well before any clean-up is needed.
What does change is the default expectation for everyone else. When standing up real infrastructure costs five lines, "I just write the app, ops is someone else's job" stops being a defensible position for a backend or fullstack developer. Blocks is one more nudge toward every product developer also owning the deploy. I think that's mostly healthy, and I'd have killed for it during the Simpli years.
The lock-in is real, and I'd keep my eyes open about it. But it's leaky lock-in. It's open-source and runs locally on top of CDK. What you're actually adopting is an AWS-shaped way of thinking about your backend, and that mindset is stickier than any single resource definition. Whether it's a fair trade is the question every team should answer on purpose, before the abstraction quietly makes the decision for them three months in.
If you're building a product or just interested in improving your process, feel free to connect or message me. I'm always open to exchanging ideas and learning from other builders.
Written by Gil, a fullstack developer with 15+ years of experience, passionate about practical architecture, clean UX, and blockchain-powered applications.