---
title: AWS Blocks Preview: Local Backends, Zero-Change Deploy
description: On June 16, 2026, AWS launched AWS Blocks in public preview — an open-source TypeScript framework with ~20 building blocks that run locally without an AWS account and deploy to production services with zero code changes. No Blocks surcharge; you pay only for underlying AWS services.
url: https://www.factualminds.com/blog/aws-blocks-application-backends-preview/
datePublished: 2026-06-17T00:00:00.000Z
dateModified: 2026-06-17T00:00:00.000Z
author: palaniappan-p
category: Cloud Architecture
tags: aws-blocks, developer-tools, typescript, cdk, serverless, aws
---

# AWS Blocks Preview: Local Backends, Zero-Change Deploy

> On June 16, 2026, AWS launched AWS Blocks in public preview — an open-source TypeScript framework with ~20 building blocks that run locally without an AWS account and deploy to production services with zero code changes. No Blocks surcharge; you pay only for underlying AWS services.

On **June 16, 2026**, AWS announced the **public preview of AWS Blocks** — an open-source TypeScript framework for composing application backends on AWS ([announcement](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-blocks-preview/)). Blocks is not a separate PaaS. It is a backend toolkit where each **Block** bundles application code, a local development implementation, and the AWS infrastructure to run it in production. There is **no additional charge for AWS Blocks**; you pay only for the underlying AWS services your application consumes. At preview, Blocks deploys to **all commercial AWS regions**.

The pitch is straightforward: run a fully functional local stack — Postgres, authentication, real-time messaging — with **zero AWS credentials**, then deploy the **same application code** to production AWS services when the feature is validated. When you outgrow a Block's defaults, drop into **AWS CDK** via `aws-blocks/index.cdk.ts`. Blocks is application-first infrastructure, not infrastructure-first application code.

## The Problem: Backend-on-AWS Still Stalls Teams

Most AWS backend projects still follow an infrastructure-first loop:

```
Write app code → request sandbox account → write CloudFormation/CDK →
deploy → wait → discover IAM error → fix → redeploy → repeat
```

That loop creates four predictable failures:

| Friction                   | What breaks                                                      |
| -------------------------- | ---------------------------------------------------------------- |
| Sandbox account gating     | Days waiting for AWS access before "hello world"                 |
| Deploy-wait-fix cycle      | IAM and capacity errors surface only after CloudFormation runs   |
| Split infra + app layers   | Terraform/CDK templates drift from application code over sprints |
| Frontend/backend contracts | OpenAPI specs and codegen fall behind API signature changes      |

AWS Blocks targets teams where the bottleneck is not AWS service availability — ECS alone provisions roughly **3 billion tasks per week** — but the **onboarding friction** between "I have a container/API idea" and "it runs on HTTPS with auth and a database."

Traditional IaC tools (CDK, Terraform, SAM) excel at production-grade infrastructure but require a separate definition layer that application developers often do not own. Visual tools like Application Composer help prototype CloudFormation templates but still produce infrastructure artifacts, not runnable application backends. AWS Blocks inverts the model: **your backend entry point is both runtime code and infrastructure definition**.

## How AWS Blocks Solves It: Infrastructure from Code

AWS calls the model **Infrastructure from Code**. Your backend lives in `aws-blocks/index.ts` — that file defines Blocks (tables, auth, APIs, jobs) and exports typed APIs your frontend imports directly.

AWS CLI v2 not required for local dev. TypeScript + Node.js 20+, AWS Blocks preview, June 2026.

```typescript
import { Scope, ApiNamespace, DistributedTable } from '@aws-blocks/blocks';
import { z } from 'zod';

const scope = new Scope('my-app');

const tasks = new DistributedTable(scope, 'tasks', {
  schema: z.object({
    userId: z.string(),
    taskId: z.string(),
    title: z.string(),
    done: z.boolean(),
  }),
  key: { partitionKey: 'userId', sortKey: 'taskId' },
});

export const api = new ApiNamespace(scope, 'api', (context) => ({
  async addTask(userId: string, title: string) {
    await tasks.put({ userId, taskId: crypto.randomUUID(), title, done: false });
  },
}));
```

Run `npm run dev` and the table persists to `.bb-data/` on disk. The API serves on localhost with hot reload. Your frontend imports `api` directly — change a backend signature and TypeScript breaks the frontend at compile time, not in production.

When ready for AWS, the same code deploys without modification:

| Command           | Purpose                 | What deploys                                                                      |
| ----------------- | ----------------------- | --------------------------------------------------------------------------------- |
| `npm run dev`     | Local development       | `.bb-data/` on disk, localhost API, hot reload                                    |
| `npm run sandbox` | Fast ephemeral AWS test | Backend-only; Lambda hot-swap; seconds                                            |
| `npm run deploy`  | Production              | Full CDK stack — DynamoDB, Lambda, API Gateway, CloudFront + S3 hosting, SSR, WAF |

Three properties matter for adoption:

1. **~20 building blocks** at preview covering data, identity, messaging, compute, storage, AI, and observability.
2. **End-to-end type safety** from schema to frontend — no codegen, no OpenAPI maintenance (per [AWS announcement](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-blocks-preview/)).
3. **Built-in AI coding tool guidance** — steering files ship inside the npm package for agents that read `node_modules` documentation.

Supported frontends at preview include **Vite + React** SPAs and SSR frameworks **Next.js, Nuxt, and Astro**.

## Building Blocks: What You Write vs What Runs

Each Block is a self-contained npm module. The umbrella package `@aws-blocks/blocks` re-exports every Block plus the core runtime ([GitHub](https://github.com/aws-devtools-labs/aws-blocks)).

| You write                       | Runs locally as        | Deploys to AWS as       |
| ------------------------------- | ---------------------- | ----------------------- |
| `DistributedTable`              | JSON file on disk      | DynamoDB with GSIs      |
| `Database`                      | PGlite (WASM Postgres) | Aurora Serverless v2    |
| `DistributedDatabase`           | PGlite (WASM Postgres) | Aurora DSQL             |
| `AuthCognito`                   | Local JWT mock         | Cognito User Pool       |
| `AuthBasic` / `AuthOIDC`        | Local JWT / OIDC mock  | JWT / federated auth    |
| `Realtime`                      | Local WebSocket server | API Gateway WebSocket   |
| `AsyncJob`                      | Runs in-process        | SQS + Lambda            |
| `CronJob`                       | Manual trigger         | EventBridge + Lambda    |
| `FileBucket`                    | Local filesystem       | S3 with presigned URLs  |
| `KnowledgeBase`                 | Local vector search    | Bedrock Knowledge Bases |
| `Agent`                         | Canned responses       | Amazon Bedrock          |
| `EmailClient`                   | Console log            | Amazon SES              |
| `Logger` / `Metrics` / `Tracer` | Console / no-op        | CloudWatch / X-Ray      |
| `Hosting`                       | —                      | CloudFront + S3 (+ SSR) |

Additional Blocks include `KVStore`, `AppSetting` (config/secrets), and `Dashboard` (auto-generated observability views). The pattern is consistent: import a Block, use it in application logic, and Blocks provisions the AWS resources following AWS best practices when you deploy.

## When to Choose Blocks (and When Not To)

**We recommend AWS Blocks when:**

- A **full-stack TypeScript team** is building a SaaS MVP or internal tool.
- You need **local-first iteration** without sandbox account dependency or AWS credentials.
- Typed frontend/backend coupling matters more than maintaining OpenAPI contracts.
- You expect to **outgrow Block defaults** and want a CDK escape hatch, not a platform lock-in.

**We recommend CDK/Terraform/SAM instead when:**

- Org policy mandates **reviewed IaC modules**, multi-account landing zones, or non-TypeScript stacks.
- You need **custom VPC topology from day one** — private-only APIs, cross-account peering, specialized compliance boundaries.

**We recommend Application Composer instead when:**

- You want **visual CloudFormation/SAM prototyping** for serverless spikes. See our [Application Composer guide](/blog/aws-application-composer-iac-generator/).

**We recommend Amplify Gen 2 instead when:**

- You want a **managed full-stack hosting framework** with Amplify's auth/data/hosting opinions baked in.

**Kiro synergy:** Blocks ships AI steering files in the npm package. A community Kiro Power at [github.com/awsdataarchitect/aws-blocks](https://github.com/awsdataarchitect/aws-blocks) packages Block APIs and deployment workflows for agentic scaffolding — complementary to our [Kiro IDE guide](/blog/kiro-ide-aws-agentic-coding/), not a replacement for reading the Blocks docs.

## Cost: No Blocks Surcharge

_Illustrative note, June 2026 — not a client engagement._

| Line item                       | Cost                        |
| ------------------------------- | --------------------------- |
| AWS Blocks framework            | **$0** surcharge at preview |
| DynamoDB, Lambda, API Gateway   | Standard AWS list prices    |
| CloudFront + S3 (via `deploy`)  | Standard AWS list prices    |
| Cognito, Bedrock, SES (if used) | Standard AWS list prices    |

Preview status means the Blocks pricing model itself could change at GA. Underlying service costs follow normal AWS billing. Model your bill from the services each Block provisions, not from Blocks itself.

> **What broke** — Preview-appropriate failure modes reported in early adoption: (1) **Preview API churn** — Block constructor signatures may change between preview releases; pin versions and read release notes before upgrading. (2) **`sandbox` vs `deploy` confusion** — `sandbox` deploys backend-only; expecting a CloudFront URL after sandbox means you needed `deploy`. (3) **CDK escape hatch required** — Block defaults may not match org networking (VPC endpoints, private-only APIs); drop into `aws-blocks/index.cdk.ts` when defaults are insufficient. (4) **First AWS deploy IAM errors** — local dev needs no credentials, but the first `sandbox` or `deploy` still surfaces IAM permission gaps on the infrastructure role.

> **Reproduce this** — Official paths only:
>
> - [AWS Blocks preview announcement (Jun 16, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/06/aws-blocks-preview/)
> - [AWS Blocks on GitHub](https://github.com/aws-devtools-labs/aws-blocks)
> - [AWS Blocks Developer Guide](https://docs.aws.amazon.com/blocks/latest/devguide/)
>
> Scaffold a new app (Node.js 20+, June 2026):
>
> ```bash
> npx @aws-blocks/create-blocks-app my-app
> cd my-app
> npm install
> npm run dev
> ```
>
> Alternative scaffold command from the GitHub README: `npm create @aws-blocks/blocks-app@latest my-app`.

## Getting Started

AWS Blocks preview, Node.js 20+, June 2026.

```bash
npx @aws-blocks/create-blocks-app my-app
cd my-app
npm install
npm run dev          # local — no AWS credentials
npm run sandbox      # backend on real AWS (seconds)
npm run deploy       # full production stack + hosting
npm run destroy      # tear down deployed resources
```

The CLI supports templates (`--template nextjs`, `react`, and others) and can add an `aws-blocks/` backend to an existing project. It auto-detects AWS Amplify Gen 2 projects for integration.

For infrastructure-first container deployment (ALB + Fargate without Blocks), see our [ECS Express Mode guide](/blog/amazon-ecs-express-mode/). For visual CloudFormation prototyping, see [Application Composer](/blog/aws-application-composer-iac-generator/).

## What to Do This Week

1. **Scaffold a greenfield app** with `npx @aws-blocks/create-blocks-app` in a dev folder — pick a template matching your frontend (React, Next.js, or Astro).
2. **Run `npm run dev`** and confirm the local stack works without AWS credentials — add one Block (auth or a table) and verify TypeScript types flow to the frontend.
3. **Deploy with `npm run sandbox`** to validate IAM permissions and real DynamoDB/Lambda behavior against AWS services.
4. **Compare against your current baseline** — time-to-first-API for a greenfield CRUD endpoint vs your standard CDK/SAM template.
5. **Document the CDK escape hatch** — identify which Block defaults your org would override via `aws-blocks/index.cdk.ts` before betting a production roadmap on preview software.

## What This Post Doesn't Cover

- **Production hardening** — WAF rule tuning, multi-account deployment, private-only VPC endpoints, and enterprise security review of preview software.
- **GovCloud availability** — preview announcement covers commercial regions; verify GovCloud support before regulated workloads.
- **Migrating existing CDK or Terraform stacks** into Blocks (greenfield + escape hatch is the practical path at preview).
- **First-party deployment benchmarks** — this post uses AWS-published facts and illustrative pricing notes, not measured time-to-deploy from a FactualMinds benchmark run.
- **Every Block API** — the preview ships ~20 Blocks; see the [GitHub repository](https://github.com/aws-devtools-labs/aws-blocks) for current Block catalog and release notes.

## FAQ

### When should you not use AWS Blocks at preview?
Skip Blocks at preview if your org mandates Terraform-first IaC with pre-approved modules, requires non-TypeScript stacks, or needs fine-grained VPC topology from day one (private-only APIs, cross-account peering, custom endpoint policies). Preview software also means API surfaces may change between releases — avoid betting a production roadmap on Blocks until GA unless your team can absorb breaking changes. Blocks optimizes for full-stack TypeScript teams building greenfield SaaS or internal tools, not for migrating complex multi-account landing zones.

### What is the difference between npm run sandbox and npm run deploy in AWS Blocks?
sandbox deploys the backend only to real AWS services using fast, ephemeral Lambda hot-swapping — useful for validating DynamoDB schemas, IAM permissions, and API behavior against production services without deploying frontend hosting. deploy runs a full CDK/CloudFormation deployment including frontend hosting (CloudFront + S3), SSR support for Next.js/Nuxt/Astro, custom domains, and WAF. A common preview mistake is running sandbox and expecting a public CloudFront URL — that requires deploy. Use sandbox during feature development; use deploy for staging and production environments.

### Can you use AWS Blocks with an existing CDK stack?
Every AWS Blocks application is a CDK application underneath. When you outgrow what a Block provides, drop into aws-blocks/index.cdk.ts and add any CDK construct directly — VPC configurations, custom security groups, additional Lambda functions, or resources Blocks do not yet expose. Blocks does not automatically import or wrap an existing CDK stack; the practical path is greenfield Blocks apps with CDK escape hatches, or adding an aws-blocks/ backend directory to an existing frontend project via the create-blocks-app CLI.

### Does AWS Blocks replace Terraform in our organization?
No. Blocks is an application-first TypeScript framework for composing backends — it generates CDK/CloudFormation under the hood, not Terraform HCL. Organizations with Terraform-first governance, multi-cloud requirements, or existing module registries should keep Terraform for infrastructure and treat Blocks as a developer productivity layer for greenfield TypeScript applications, not a replacement for org-wide IaC standards. Blocks and Terraform can coexist when different teams own different layers.

### Which frontend frameworks are supported at preview?
At preview, AWS Blocks supports SPAs such as Vite + React, and SSR frameworks including Next.js, Nuxt, and Astro. The create-blocks-app CLI offers templates for several stacks (react, nextjs, and others). Types flow from the backend definition in aws-blocks/index.ts to the frontend import — no OpenAPI spec or codegen step. Native client SDK generation (Swift, Kotlin, Dart) is also part of the broader Blocks ecosystem for mobile clients sharing the same backend definition.

### How does AWS Blocks compare to Amplify Gen 2?
Amplify Gen 2 is a managed full-stack framework with opinionated auth, data, and hosting primitives tied to the Amplify console and deployment model. AWS Blocks is an open-source composable backend toolkit where each Block (DistributedTable, AuthCognito, Realtime, etc.) bundles application code, local dev implementation, and AWS infrastructure. Blocks emphasizes local-first development without AWS credentials and explicit CDK escape hatches. Choose Amplify when you want Amplify hosting and data opinions out of the box; choose Blocks when you want typed Infrastructure-from-Code with local mocks and direct CDK control when you outgrow a Block.

---

*Source: https://www.factualminds.com/blog/aws-blocks-application-backends-preview/*