AWS Blocks Preview: Local Backends, Zero-Change Deploy

On June 16, 2026, AWS announced the public preview of AWS Blocks — an open-source TypeScript framework for composing application backends on AWS (announcement). 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:

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.

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:

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).
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).

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.

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 packages Block APIs and deployment workflows for agentic scaffolding — complementary to our Kiro IDE guide, not a replacement for reading the Blocks docs.

Cost: No Blocks Surcharge

Illustrative note, June 2026 — not a client engagement.

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)
• AWS Blocks on GitHub
• AWS Blocks Developer Guide

Scaffold a new app (Node.js 20+, June 2026):

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.

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. For visual CloudFormation prototyping, see Application Composer.

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 for current Block catalog and release notes.