AWS Blocks：ローカルで動かしAWSへそのままデプロイするInfrastructure from Codeフレームワーク
AWS Blocksは、TypeScriptで書いたバックエンドがそのままAWSインフラになる「Infrastructure from Code」のOSS（Apache-2.0・Preview）。

この記事はOSS観察・解説記事です。 aws-devtools-labs/aws-blocks（AWS Blocks）は、AWSが2026年6月16日にPreview公開したオープンソースのフルスタックバックエンドフレームワークです。 本稿は2026年6月21日（JST）時点で、公式リポジトリ・AWSの発表・第三者の実使用レポートから確認できる事実を整理し、LocalStackやMiniStack・kumoといった「AWSローカルエミュレータ」とどう違うのか を中心に切り分けます。

「ローカルでAWSを動かす」と聞くと、多くの開発者はまずLocalStackを思い浮かべます。 しかしAWS Blocksは、同じ「AWSアカウント不要でローカル開発」を実現しながら、まったく別のアプローチ を取っています。 ここを混同すると選定を誤るので、本稿ではそのカテゴリの違いを最初に押さえます。

まず動画で全体像をつかむ：コミュニティ解説「AWS Blocks: A New Way to Build on AWS」。出典：YouTube
この記事のポイント
  • ・AWS Blocksは「Infrastructure from Code」のフレームワーク。TypeScriptで書いたバックエンドのコードが、そのままAWSインフラになる。
  • ・new KVStore(...) の1行が、ローカルではメモリ実装・デプロイ時はDynamoDB・本番ではAWS SDK呼び出しへと、コード無改変で姿を変える。
  • ・PGlite（インプロセスPostgres）・ローカルJWT・WebSocketでAWSアカウント不要のローカル開発。20+のBlockを提供。
  • ・LocalStack/MiniStack/kumoはAPIエミュレータ系、AWS BlocksはIfCフレームワーク系で、解く課題が違う。「既存構成のテスト」か「新規アプリ構築」かで使い分ける。
  • ・Apache-2.0・Preview（スター約153）。本番採用は時期尚早だが、設計思想は明快。

AWS Blocksは「ローカル開発をどう自動化するか」というテーマの最新解のひとつです。ローカルテストやCI自動化を含むツール全体像は AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 にまとめてあるので、自動化スタックの中での位置づけを確認したい場合はあわせて読むと整理しやすくなります。

1. AWS Blocksとは — 書いたコードがそのままAWSインフラになる

AWS Blocksを一言で言うと、「バックエンドのTypeScriptを書くと、それがAWSインフラそのものになる」 フレームワークです。 READMEのタグラインは次のとおりです。

A backend toolkit for building full-stack applications on AWS.（AWS上にフルスタックアプリを構築するためのバックエンドツールキット）

公式の説明では、各Blockは 「アプリケーションコード・ローカル開発環境・インフラを1つにまとめた、自己完結のバックエンド機能」 とされています。 Blockを組み合わせることでベストプラクティスに沿ったAWSインフラを定義でき、アプリはAWSの資格情報なしにローカルで動き、同じコードを無改変で本番にデプロイできる ——これがコンセプトです。

この「コードがインフラになる」考え方は Infrastructure from Code（IfC） と呼ばれます。 Terraformのように構成を別途記述するInfrastructure as Code（IaC）とは異なり、アプリのコードそのものから必要なインフラを導き出す発想です。 IfCという概念そのもの（IaCとの違い・主要フレームワークの盛衰・AWS Blocksの位置づけ）は Infrastructure from Codeとは｜IaCとの違いと主要フレームワーク、AWS Blocksの登場 で詳しく解説しています。

基本情報（2026-06-21時点）

公式リポジトリとAWSの発表から確認できる基本情報は次のとおりです。

項目値
リポジトリaws-devtools-labs/aws-blocks
言語TypeScript 77.6%
ライセンスApache-2.0
提供形態オープンソース・Preview（2026-06-16発表）
Stars / Forks約153 / 19（公開直後）
必要環境Node.js 22+ / npm 10+
提供Block数20+（データ・認証・AI・通信・監視など）
開発元AWS（aws-devtools-labs）

スター数が約153と少なく見えますが、これはAWSが公開したばかりのPreviewだからです。 「AWS公式が、Infrastructure from Codeという比較的新しいパラダイムをOSSで出してきた」こと自体が、このプロジェクトの注目点です。

Infrastructure from Code（IfC）とは
インフラ構成を別ファイル（Terraform/YAML等）で書くのがIaCだとすれば、IfCはアプリのコードから必要なインフラを推論して生成するアプローチ。AWS Blocksでは「TypeScriptで書いたバックエンドが、そのままAWSの構成になる」。インフラとランタイムのコードを型安全に一体で書けるのが特徴。

2. 何が新しいのか — 1行のコードが文脈ごとに3つの姿になる

AWS Blocksの最大の発明は、同じ1行のコードが、実行される文脈に応じて別の実装に化ける 点です。 公式が挙げる代表例がこれです。

// この1行が、文脈ごとに別物になる
new KVStore(scope, 'todos')

このコードは、書き換えなしで次の3つの姿を取ります。

AWS Blocksの3実行モード：ローカル開発・CDK合成・本番ランタイム
同じ new KVStore(scope, 'todos') が、ローカルではメモリストア、デプロイ時はDynamoDBテーブル、本番ではAWS SDK呼び出しになる。コードは一切書き換えない。

仕組みは、Node.jsの 条件付きエクスポート（conditional exports） によるモジュール解決です。 同じインポート文に対し、文脈ごとに違う実装が読み込まれます。

・ローカル開発モード：メモリ・ファイルシステム上の実装が動く。AWSアカウント不要
・CDK合成モード：BlockがCDKコンストラクトを生成し、CloudFormationテンプレートを出力する
・Lambdaランタイムモード：BlockがAWS SDK経由で実際のAWSサービスを呼び出す

開発者から見ると「KVStoreを使った」という事実だけが残り、それがローカルでメモリ、本番でDynamoDBになる差分はフレームワークが吸収 します。 LocalStackのように「ローカル用のエンドポイントURLを設定する」必要すらありません。コード側にAWS固有の接続設定が出てこないのです。

この設計は、型安全がバックエンドからフロントエンドまで一気通貫で流れることにもつながっています。 Webフレームワーク（Next.js / Nuxt / Astro / React / Vue / Svelte / Angular）向けにはコード生成ステップなしで型が通り、ネイティブクライアント（Kotlin / Swift / Dart）には blocks.spec.json から型付きクライアントを生成します。

3. 使えるBlock一覧と、ローカル開発の中身

AWS Blocksは20以上のBlockを提供し、フルスタックでよくある機能をカバーします。 カテゴリごとに整理すると次のとおりです。

カテゴリBlock
データ・ストレージKVStore / DistributedTable / Database / DistributedDatabase / FileBucket
認証AuthBasic / AuthCognito / AuthOIDC
コンピュート・バックグラウンドAsyncJob / CronJob
AIAgent / KnowledgeBase
通信Realtime / EmailClient
設定AppSetting
監視Logger / Metrics / Tracer / Dashboard
ホスティングHosting

注目すべきは、ローカル開発が 「それっぽいモック」ではなく、本物に近い実装 で動く点です。

・Database：PGlite を使い、本物のPostgresエンジンをインプロセスで 起動する。ゼロレイテンシで、本番のマネージドPostgresと同じ型安全インターフェース
・Auth：ローカルで 本番と同じクレーム構造のJWT を発行・検証する
・Realtime：ローカルのWebSocketサーバーが、インターネット接続なしで 完全なpub/subセマンティクス を提供する

つまり「ローカルでは雑なモック、本番で初めて本物」という従来の落とし穴を避け、ローカルの段階から本番に近い挙動を確認できる設計になっています。

クイックスタート

導入はnpmの雛形作成コマンド一発です。

npm create @aws-blocks/blocks-app@latest my-app
cd my-app
npm install
npm run dev
# → http://localhost:3000 でフルスタックアプリが起動（AWSアカウント不要）

npm run dev した時点で、Postgres・認証・リアルタイム通信を含む環境がローカルで立ち上がります。 ここまでにAWSの資格情報は一度も要りません。 料金体系も「AWS Blocks自体は追加料金なし、使ったAWSサービスの分だけ課金」とされており、ローカル開発のあいだはコストゼロです。

4. LocalStack・MiniStack・kumoとの決定的な違い

ここが本稿の主題です。 結論から言うと、AWS BlocksとLocalStack系は「同じローカル開発」でも解いている課題が違い、カテゴリが別物 です。

AWSローカル開発ツールの2系統：APIエミュレータ系とInfrastructure from Code系
AWSローカル開発ツールには2系統ある。①APIエミュレータ系（LocalStack/MiniStack/kumo/Emulate）と、②Infrastructure from Code系（AWS Blocks）。

① APIエミュレータ系（LocalStack / MiniStack / kumo / Vercel Emulate） は、AWSのAPIをローカルで模倣します。 あなたは普段どおりAWS SDKやTerraform/CDKで「AWS向けのコード」を書き、接続先のエンドポイントをローカル（多くは localhost:4566）に向けることで、AWSアカウントなしにそのコードを動かしてテストします。 既存のAWS構成をそのままローカルで検証する のが目的です。

② Infrastructure from Code系（AWS Blocks） は、AWSのAPIを模倣しません。 あなたはBlockという高レベル部品で「アプリ」を書き、それがローカル実装→CDK合成→実AWSへと姿を変えます。 ローカルファーストで新規のフルスタックアプリを作り、そのままAWSへ持っていく のが目的です。

どちらを選ぶべきかは、出発点で決まります。

flowchart TD A{"出発点はどっち？"} -->|"既にAWS向けの
SDK/IaCコードがある"| B["APIエミュレータ系"] A -->|"これから新規に
アプリを作る"| C{"書き方の好みは？"} B --> B1["LocalStack：最大手・多機能"] B --> B2["MiniStack：MIT無料・軽量・実コンテナ"] B --> B3["kumo：Go製単体バイナリ"] B --> B4["Vercel Emulate：Docker不要・TS"] C -->|"高レベル部品で
素早く・型安全に"| D["AWS Blocks（IfC）"] C -->|"低レベルを自分で
細かく制御"| E["CDK / SAM を直接"]

主要ツールを並べると、立ち位置の違いがはっきりします。

ツールカテゴリやることライセンス
AWS BlocksIfCフレームワークBlock部品でアプリを書き、無改変でAWSへデプロイApache-2.0（Preview）
LocalStackAPIエミュレータAWS APIをローカル模倣（Community有償化済み）BSL / 一部有償
MiniStackAPIエミュレータ40+サービスを模倣・RDS等は実コンテナ起動MIT
kumoAPIエミュレータGo製・76サービス・単体バイナリOSS
Vercel EmulateAPIエミュレータDocker不要・AWS/Slack/GitHubをローカルモックOSS

エミュレータ系の選び方そのものは、すでに本サイトで詳しく扱っています。 LocalStackの有償化に対する無料代替としては MiniStack徹底解説：MIT・無料のAWSローカルエミュレータ、LocalStack有償化への対抗馬 が、Goエコシステム中心なら kumo v0.12｜Go製AWSエミュレータ76サービス対応・DynamoDB GSI/EventBridge API Destinations追加 が、Docker不要のテスト用途なら Vercel Emulate入門｜LocalStack代替・Docker不要でAWS/Slack/GitHubをローカルテスト が参考になります。 これらは「既存のAWS構成をテストする」道具で、AWS Blocksとは目的が重なりません。

混同しやすい注意点
「AWS Blocksは無料のLocalStack代替だ」と紹介されることがあるが、正確ではない。AWS Blocksで書いたアプリは、LocalStackでテストする対象にはならない（そもそもエンドポイントを差し替える発想がない）。既存のSDK/Terraformコードをローカルで回したいならエミュレータ系、新規アプリをローカルファーストで作るならAWS Blocks、と目的で選ぶこと。

5. Amplify・App Studioとの違い — AWSの中での位置づけ

AWS内にも、似た方向のサービスとしてAmplifyやApp Studioがあります。 DEV Communityの解説は、AmplifyとBlocksの思想の違いをうまく言語化しています。

Amplifyはインフラを意識の外に追いやることで共通のゴール（フロントエンド開発者を楽にする）に到達する。Blocksは、インフラを意識できる状態に保ったまま、それを要求しないことで到達する。前者は抽象の壁を厚くし、後者は壁を薄く透明にする。

つまりAmplifyは「インフラを見せない」方向、AWS Blocksは「インフラは見えるが、書かなくてよい」方向です。 必要になれば前述のとおり、いつでもCDKに降りて細かく制御できる——壁が薄いので、低レベルへ抜けやすいわけです。 App Studioがノーコード/ローコード寄りなのに対し、AWS Blocksはあくまでコードファーストである点も異なります。

もう一つ見逃せないのが、AIエージェントがコードを書く前提で設計されている という点です。 同じ解説は、AWS Blocksについて「AIエージェントがコードを書くことを当然視し、フレームワーク自体に正しい書き方が最初から組み込まれている。これは人間の学習コストだけでなく、エージェントが間違えるコストも下げる設計だ」と評しています。 高レベルで型安全なBlock部品は、人間にとってもエージェントにとっても「踏み外しにくい」ガードレールとして働く、という発想です。

6. 使用感・コミュニティの反応

Previewながら、公開直後から実使用レポートが出ています。 ここでは一次に近い第三者の手触りを引用します（本サイトの方針として、実際に触った人のレポートを重視します）。 全体像は冒頭のコミュニティ解説動画（AWS Blocks: A New Way to Build on AWS）でも確認できます。

実際にローカルとAWSサンドボックスの両方で試したクラスメソッド（DevelopersIO）のレポートは、次のように評価しています。

AWSアカウントなしでバックエンドのプロトタイプを作り、同じコードをAWSへデプロイできる体験は、ローカルファーストでフルスタック開発を進めたい人なら試す価値がある。

AWS Heroesコミュニティの記事も、サンドボックスアカウントの取得という障壁を取り払い、「ノートPC上でAWS資格情報ゼロのまま自己完結する部品でアプリを書き、検証できたら実インフラへデプロイできる」点を、このツールの本質的な価値として挙げています。

総じて、現時点の評価は 「ローカルファーストの開発体験」と「無改変デプロイ」への好意的な驚き が中心です。 一方で、Infrastructure from Codeという考え方自体への賛否（抽象に乗ることのトレードオフ）を論点として挙げる声もあり、ここは後述の注意点にもつながります。

7. 注意点・Preview段階のリスク

率直に課題感も書いておきます。

まず、まだPreview です。 Apache-2.0のOSSとはいえGitHubスターは約153と公開直後で、Block仕様やAPIは今後変わる可能性があります。 本番採用は、Previewが取れる段階を待つか、変更を許容できるプロトタイプ用途に留めるのが無難です。

次に、Infrastructure from Codeという抽象に乗ることのトレードオフ です。 Block部品でアプリを書く以上、「どのAWSリソースがどう作られるか」はフレームワークの判断に委ねられます。 生成物がCDK/CloudFormationという標準の仕組みである点、そしていつでもCDKに降りられる点は安心材料ですが、独自抽象に依存するぶん、他基盤への移植容易性は通常のSDK直書きより下がります。 「壁は薄いが、壁はある」ことは理解して採用すべきです。

最後に、カテゴリの取り違え です。 繰り返しになりますが、AWS BlocksはLocalStackの置き換えではありません。 既存のAWS向けSDK/IaCコードをローカルで回したいなら、本稿で挙げたエミュレータ系を選ぶべきで、AWS Blocksは「これから新規にローカルファーストで作る」ケースのための道具です。 要件の出発点を取り違えると、どちらを入れても噛み合いません。

まとめ

AWS Blocksは、「バックエンドのTypeScriptを書くと、それがそのままAWSインフラになる」 Infrastructure from CodeのOSSフレームワークでした。

確認できた事実を整理すると、次のようになります。

・new KVStore(...) の1行が、ローカルではメモリ実装・デプロイ時はDynamoDB・本番ではAWS SDK呼び出しへと、コード無改変で姿を変える
・PGliteの本物Postgres・本番同等のJWT・WebSocketのpub/subで、AWSアカウント不要のローカル開発が完結する
・20+のBlock（データ・認証・AI・通信・監視・ホスティング）を提供。Web/ネイティブまで型が通る
・LocalStack/MiniStack/kumo/EmulateはAPIエミュレータ系、AWS BlocksはIfC系で、解く課題が違う
・Apache-2.0・Preview（スター約153）。本番採用は時期尚早だが、AWS公式がIfCをOSSで出した意義は大きい

結論
「既存のAWS構成をローカルでテストしたい」ならMiniStackなどエミュレータ系、「ローカルファーストで新規フルスタックを素早く作りたい」ならAWS Blocks。両者は競合ではなく、解く課題が異なる別カテゴリ。AWS BlocksはまだPreviewだが、無改変デプロイとローカル本物実装の体験は新規プロジェクトの立ち上げで試す価値がある。まずは npm create @aws-blocks/blocks-app@latest でローカルだけ触ってみるのがおすすめ。

参照ソース

・aws-devtools-labs/aws-blocks（公式リポジトリ・README）
・AWS announces AWS Blocks (Preview)（What’s New）
・AWS Blocks 製品ページ
・What is AWS Blocks?（AWS公式ドキュメント）
・I tried AWS Blocks (Preview) both locally and on AWS sandbox（DevelopersIO）
・What is AWS Blocks? How it differs from Amplify and App Studio（DEV Community）