What is AWS Blocks? How it differs from Amplify and App Studio, and what each one is aiming for

On June 16, 2026, AWS announced AWS Blocks as a public preview. It is an open-source framework where the TypeScript you write for your backend becomes the AWS infrastructure that runs it.

https://github.com/aws-devtools-labs/aws-blocks

The first thing many AWS users will think is "another full-stack tool." If you want a tool for frontend developers to build full-stack apps in TypeScript, Amplify Gen2 already exists. For people who don't write code, there is App Studio. I compared those three earlier in a write-up on App Studio, Amplify Gen1, and Amplify Gen2. Now Blocks joins them.

This article organizes what AWS Blocks is from the official docs and the open-source code, lines it up against Amplify and App Studio, and finally sketches a map of what each one is aiming for. Rather than stopping at a feature-diff table, I want to get at why AWS is offering multiple entry points into full-stack development.

A note: this is based on the official docs right after the preview announcement and on reading the open-source code. It is not based on long-term production use of Blocks. Read it with the understanding that implementation details may change.

What is AWS Blocks

Here is how the official docs define it. AWS Blocks is a backend toolkit for full-stack applications, where each Block is a self-contained backend capability that bundles the application code, a local development setup, and the infrastructure to run it. Pick the Blocks you need and compose them, and the infrastructure following AWS best practices is defined automatically.

Type safety doesn't stop inside the backend. Types flow from the backend all the way to the client, reaching web frameworks (Next.js, Nuxt, Astro, React, Vue, Svelte, Angular) and native targets (Swift, Kotlin, Dart/Flutter). From a single backend, you can generate typed client code for both web and mobile.

https://github.com/aws-devtools-labs/aws-blocks

That said, at the time of the preview announcement the frontends officially listed are SPAs (Vite + React) and SSR frameworks (Next.js, Nuxt, Astro), with support expected to widen over time. Blocks itself adds no extra charge; you pay only for the AWS services you use, and you can deploy to all commercial AWS Regions.

https://aws.amazon.com/about-aws/whats-new/2026/06/aws-blocks-preview/

From here, let's walk through the concepts you can't skip to understand Blocks.

Block = an npm package bundling infrastructure, runtime, and local implementation

One Block is one npm package, holding the cloud resources, runtime code, and local implementation for a single capability. Instantiate one KVStore, for example, and you get all at once: a DynamoDB table auto-provisioned at deploy time, runtime code that runs on Lambda, and an in-memory implementation for local development.

https://docs.aws.amazon.com/blocks/latest/devguide/concepts.html

The available Blocks cover most backend needs: data (KVStore, DistributedTable, Database, DistributedDatabase, FileBucket), auth (AuthBasic, AuthCognito, AuthOIDC), async work (AsyncJob, CronJob), AI (Agent, KnowledgeBase), communication (Realtime, EmailClient), configuration (AppSetting), observability (Logger, Metrics, Tracer, Dashboard), and hosting (Hosting).

https://docs.aws.amazon.com/blocks/latest/devguide/what-is-blocks.html

What the official overview page doesn't give you, though, is a list of which AWS service each Block actually becomes inside. I was curious, so I read the open-source code (aws-devtools-labs/aws-blocks) to confirm the real services behind the main Blocks.

A few findings the overview alone doesn't reveal:

DistributedDatabase is Aurora DSQL, so DSQL's own constraints surface directly in the development experience. You can't mix DDL and DML in the same transaction, and only one DDL statement is allowed per transaction. Blocks rejects these on the client side with validation.

KnowledgeBase uses S3 Vectors, which arrived in 2025, as the vector store for RAG.

Agent sits on top of Strands Agents SDK, AWS's open-source agent framework.

Hosting is less "CloudFront + S3" and more a heavier part that also bundles WAF, Route 53, and ACM.

IFC layer = the entry point where code becomes infrastructure

The backend entry point of Blocks lives in a single file, aws-blocks/index.ts. Instantiate Blocks and define your API there, and the infrastructure is derived directly from that code. No separate file for infrastructure definitions.

This idea of deriving infrastructure from code is called Infrastructure from Code (IFC), and in the source this backend part was named the IFC subpackage.

In other words, the code that describes infrastructure and the code that describes the app aren't separated. Infrastructure grows out of the app's code. This is the heart of Blocks' philosophy.

Conditional exports = the same import switches implementation by context

The reason a single file can play three roles at once, namely local development, deploy, and production runtime, is Node.js conditional exports, which route the same import statement to a different implementation per context.

The same line new KVStore(scope, 'todos') becomes a local store in development, a DynamoDB table at deploy time, and an SDK call in production. You never change the code. Without writing any configuration by hand, module resolution picks the implementation per context. Reading the source package.json, they are switched by conditions like cdk, aws-runtime, types, and default (the local mock).

ApiNamespace = type-safe RPC with no code generation

The part that calls the backend from the frontend is handled by ApiNamespace. The frontend imports and calls methods defined in the backend directly.

// Frontend: import the backend API directly
import { api } from '../aws-blocks/index.js';

const result = await api.greet('World');
// TypeScript knows the return type too

No code generation step, no API client initialization, no URL configuration. Change a backend method signature and the frontend gets a compile error instantly. Locally it goes through an HTTP server; in production it reaches Lambda through API Gateway.

The transport underneath is JSON-RPC 2.0. When you call a typed method, it is converted into a JSON-RPC request internally and delivered to the backend. The developer never assembles a payload by hand; the transport stays hidden behind the types.

Local-first = everything runs without an AWS account

Run npm run dev and the whole app starts locally. Blocks resolve to local implementations (an in-memory store, local auth, an embedded DB), running at http://localhost:3000 with hot reload. No AWS account, no internet connection, no cloud billing. Local data is persisted under .bb-data/ at the project root.

The "embedded DB" here turns out to be PGlite (a WebAssembly build of PostgreSQL). Not only Database but also DistributedDatabase, which uses Aurora DSQL, falls back to PGlite locally. It works because DSQL is PostgreSQL-compatible, so a near-real Postgres comes up locally without an AWS account.

When you want to check behavior against real cloud services, npm run sandbox deploys to a fast, disposable environment using hot-swap to Lambda. The mocks are swapped for real AWS services (DynamoDB, Aurora, S3, Lambda, and so on), and once you are done you can tear it all down with npm run sandbox:destroy. To ship to production, you run npm run deploy. The same backend code runs in all three.

Direct CDK access = if Blocks isn't enough, write it yourself

Every Blocks app is a CDK app. You can use arbitrary CDK constructs alongside Blocks, and you can embed Blocks into an existing CDK stack.

When you want to add a resource Blocks doesn't provide (SNS, Step Functions, and the like) or set up a custom domain, you write aws-blocks/index.cdk.ts and access CDK constructs directly. Normally the infrastructure is derived from the backend definition (aws-blocks/index.ts), so you don't need to touch CDK directly. When you do need it, you just write CDK and can build as far as you like, beyond the edges of the framework. By design, it is structurally hard to get trapped and stuck inside the abstraction.

AGENTS.md bundled = agents write correct code from the start

Blocks ships an agent-facing guide inside the npm package. Without adding a plugin, an AI coding agent is said to be steered toward writing correct code from the start.

Its actual form turned out to be an AGENTS.md placed in the project. Reading it, rather than carrying the full guide inline, it is a pointer to references. The detailed explanation, how to choose a Block, and how to use each Block live under node_modules/@aws-blocks/blocks/ in README.md, docs/index.md, and docs/.md, and it tells the agent to read those. Alongside, the Rules forbid anti-patterns: always use a Block for persistence (no local files, in-memory arrays, or local DBs), and don't assemble JSON-RPC payloads by hand.

Rather than pouring everything into the agent's context, you have it read only the docs it needs when it needs them. This pointer approach is sound as a design for agent-facing docs, and it is worth noting that an official AWS framework ships with it.

How it differs from Amplify and App Studio

Let me line up what we have covered against Amplify Gen2 and App Studio.

Amplify Gen2 is a development platform where you describe data models, business logic, and authn/authz in TypeScript and the appropriate cloud resources are auto-provisioned. It is built on CDK internally and offers categories like Data, Auth, Storage, and Functions out of the box. Per-developer cloud sandboxes, shared environments mapped one-to-one to Git branches, and the Amplify Console that bundles hosting and CI/CD are its hallmarks.

https://docs.amplify.aws/react/how-amplify-works/concepts/

App Studio sits on the low-code side, letting non-developers and beginners with little coding experience design and build apps. Where Amplify Gen2 and Blocks target developers, App Studio aims at a fundamentally different audience. I have organized the product details in the write-up I mentioned at the top.

https://zenn.dev/ikenyal/articles/c2c3ccf9fdd0cf

Lined up by aspect:

A shared obsession with iteration speed shows up too. Amplify Gen2 advertises up to 8x faster iteration than Gen1, speeding up cloud-side reflection via hot-swap to per-developer sandboxes. Blocks, on the other hand, completes locally, so in many cases there is no round trip to the cloud at all. The direction of "faster" differs, but the aim of shortening the write-then-check loop is shared.

What each one is aiming for

Rather than feature diffs, let me put into words what the three are trying to achieve.

What App Studio aims for is delivering apps to people who don't write code. Its abstraction is the highest, and it minimizes the developer's involvement the most.

What Amplify aims for is freeing frontend developers from infrastructure. Even though Gen2 was rebuilt on CDK, what developers face day to day are categories like Data, Auth, and Storage, and that managed mass covers up the infrastructure underneath. It takes care of hosting and CI/CD together, freeing developers from stitching individual AWS services by hand. The key is to hide.

What Blocks aims for looks a little different. The entry point of making infrastructure tools unnecessary to learn is similar to Amplify, but its means leans toward making things transparent with code and types rather than hiding them. Infrastructure grows from the app's code, the same code runs both locally and in the cloud, and you can write CDK directly when needed. Rather than ease through concealment, it aims for reassurance through transparency and the absence of a ceiling.

In short, Amplify reaches the shared goal of making frontend developers' lives easier by keeping infrastructure out of mind, while Blocks does it by letting you stay aware of infrastructure without requiring you to. They take two routes to the same place. The former thickens the wall of abstraction; the latter makes it thin and transparent.

And Blocks carries one more premise that is distinctive of 2026. It takes for granted that AI agents write code, and the framework itself carries the correct way to write from the start. This is a design that lowers not only the cost of humans learning but the cost of agents making mistakes, and its starting point looks different from Amplify's design philosophy.

Where is Amplify headed

What follows is interpretation, not fact. I write it on the premise that none of it is certain.

The official docs explicitly call the relationship between Blocks and Amplify complementary. Amplify provides hosting, CI/CD, and a managed backend experience; Blocks focuses on type-safe infrastructure-from-code and local-first development.

Still, the overlap is not small. Amplify Gen2 also defines backends code-first in TypeScript, on top of CDK. Blocks' IFC layer and Amplify Gen2's backend definition are both a "write your backend in TypeScript" experience standing on CDK, so they sit close in philosophy.

The closeness shows on the implementation side too. Blocks' project-creation CLI auto-detects an existing Amplify Gen2 project and integrates with it, and there is even a dedicated amplify template. Adding Blocks to an Amplify Gen2 backend is an entry path assumed from the start. The complementary relationship is not just a line in the docs; it is implemented as tool behavior.

One possibility I read from this: Amplify shifts its center of gravity toward the hosting and managed-experience layer, while Blocks takes the composable-backend-parts and local-development layer. In fact, Hosting in Blocks is treated as one part bundling CloudFront, S3, and even WAF, and the integrated hosting and CI/CD experience remains a strength on Amplify's side.

What matters is that this doesn't necessarily mean Amplify is shrinking. It reads more naturally as AWS deliberately keeping multiple entry points into full-stack development. App Studio for non-developers, Amplify for those who want a managed experience, Blocks for those who want to command infrastructure with code and types. Rather than converging on a single right answer, it looks like a strategy of preparing a different door for each developer's stance.

Closing

AWS Blocks turned out to be not a replacement for Amplify but one more entry point into full-stack development. Amplify, which makes things easy by hiding; Blocks, which makes things transparent and hands you the controls. Which you choose is also a statement of how you want to relate to infrastructure.

AWS is not converging on a single answer. When the doors multiply, the question isn't which tool is better, but which kind of developer you want to be.