AWS Blocks offers a local-first backend, targeting the TypeScript BaaS space

AWS's new open-source framework promises a no-account local development workflow for building on AWS. We analyze its initial offering and positioning against SST, Amplify, and Supabase.

The Answer Up Front

AWS Blocks is for TypeScript developers already committed to the AWS ecosystem who want a simplified, local-first development loop without directly managing infrastructure. The ability to build and test a full backend locally, without even an AWS account, is its core value proposition. You should skip it if you require a multi-cloud solution, a mature framework with a large community, or a true Backend-as-a-Service (BaaS) with a fully managed database offering. It’s a promising, AWS-native competitor to SST, but its ecosystem is nascent and its long-term traction within AWS's crowded toolset is unproven.

Methodology

This is a v0 review of AWS Blocks, based on the official launch tutorial published on dev.to on June 18, 2026, and the associated public GitHub repository. The analysis covers the features and developer workflow as presented by AWS in their 'World Cup Bracket Picker' example application. We evaluated the framework's stated goals, its core primitives (auth, data, scheduling), and its local-first development model.

This review does not include independent performance benchmarks, a real-world cost analysis of a deployed application, or long-term testing of the developer experience. All features and capabilities described are based on the vendor's claims and public artifacts. This v0 review draws on the founder's published claims at https://dev.to/aws/building-a-world-cup-bracket-picker-with-aws-blocks-1k8; independent benchmarks are pending. We will re-evaluate when we can conduct hands-on testing.

What It Does

Based on the launch material, AWS Blocks is a TypeScript framework for building cloud backends that abstracts away AWS infrastructure complexity. Its workflow is designed to be local-first.

Develop locally, no AWS account needed

The primary feature is a local development server that emulates AWS services, allowing developers to build and test a full-stack application without needing an AWS account or an internet connection. The sample project shows the Blocks backend running on localhost:3001 alongside a Vite frontend. For features like AI, it integrates with local tools like Ollama.

Define infrastructure with TypeScript

Developers define backend resources using TypeScript classes provided by the @aws-blocks/blocks package. The tutorial demonstrates instantiating AuthBasic for authentication, and implies similar high-level constructs for data, real-time updates, and scheduled jobs. This 'Infrastructure from Code' approach is similar to SST and Pulumi, but aims for a higher level of abstraction.

A curated set of backend primitives

The framework provides built-in modules for common backend needs. The example application uses primitives for authentication (basic username/password, with options for Cognito and OIDC), real-time data sync (to show other users' picks), scheduled jobs (to sync match results hourly), and an AI chat agent. This suggests an opinionated, batteries-included approach.

One-command deployment to AWS

When ready to deploy, Blocks uses the AWS Cloud Development Kit (CDK) under the hood. The promise is that the same code written and tested locally can be deployed to a developer's AWS account with a single command, with no code changes required. The framework handles the provisioning of the necessary underlying resources like Lambda, API Gateway, and DynamoDB.

What's Interesting / What's Not

The most interesting aspect of AWS Blocks is its explicit focus on the local development loop. Requiring an AWS account and configuring credentials just to start a project has long been a major friction point for AWS tooling compared to competitors like Supabase or Vercel. By removing this barrier, AWS is clearly targeting the indie developer and startup audience that has drifted towards these more DX-focused platforms. It's a direct response to the success of SST's sst dev live lambda development environment.

What's less clear is how Blocks fits into the existing, crowded landscape of AWS developer tools. AWS already has Amplify, Serverless Application Model (SAM), Chalice, and the CDK itself. Launching another framework risks further fragmenting the ecosystem rather than unifying it. The value proposition must be significantly better than Amplify's to gain traction. The claim of 'zero changes' for deployment is also a classic promise that often breaks down with real-world complexity, state management, and environment-specific configurations.

Compared to SST, Blocks appears to be a direct, AWS-blessed competitor with a similar philosophy. However, SST is more mature, has a larger community, and supports more constructs. Compared to Supabase, Blocks is not a managed service. You own the infrastructure, the scaling, and the costs, which is a fundamentally different model. Blocks is a framework, not a platform.

Pricing

(As of June 18, 2026)

AWS Blocks is an open-source framework and is free to use. There is no pricing for the framework itself. When you deploy an application built with Blocks, you pay for the underlying AWS resources that it provisions in your account. These costs will vary depending on usage but would typically include services like AWS Lambda, Amazon API Gateway, Amazon DynamoDB, and AWS IAM. A detailed cost analysis would require deploying a sample application and monitoring usage.

Verdict

AWS Blocks is a compelling new entry for developers who are building on AWS and prioritize a modern, local-first TypeScript workflow. Its biggest strength is eliminating the initial friction of cloud setup, allowing for rapid iteration entirely on a local machine. It is a solid choice for greenfield projects where the team is already committed to the AWS ecosystem.

However, its newness is a liability. Teams that need a proven, stable framework with extensive community support and documentation would be better served by SST for now. Developers looking for a fully managed BaaS experience, including a managed Postgres database, should still look to Supabase or Firebase. AWS Blocks is a framework to watch, but not yet one to bet a critical project on without careful evaluation.

What We'd Test Next

For a v1 review, we would need to move beyond the vendor's tutorial. First, we would deploy the World Cup application to a fresh AWS account and monitor its baseline costs for one week of light usage. Second, we would test the 'zero changes' deployment claim by introducing more complex application logic, such as external API dependencies and stateful operations, to see where the local emulation and cloud reality diverge. Finally, we would benchmark the performance and scalability of its real-time and data components against established solutions like Supabase Realtime and AWS AppSync.

The investor read

AWS Blocks is a defensive move by AWS to recapture mindshare among indie and startup developers who have flocked to higher-abstraction, DX-focused platforms like Vercel, Supabase, and SST. It's not a startup to invest in; it's a market signal that validates the 'Infrastructure from Code' approach and confirms that developer experience is a key battleground. The existence of Blocks puts pressure on SST, its closest philosophical competitor. For investors, the key question is whether AWS's distribution and brand can help Blocks overtake the more mature, community-driven SST. This move suggests AWS may be more inclined to build or open-source its way into new developer markets rather than acquire, potentially capping the exit valuations for startups in the AWS tooling ecosystem.

Pull quote: “The ability to build and test a full backend locally, without even an AWS account, is its core value proposition.”