AWS Blocks徹底解説｜ローカルで動かしAWSへそのままデプロイ、LocalStack系との違い

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

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

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

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

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

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

公式の説明では、各Blockは 「アプリケーションコード・ローカル開発環境・インフラを1つにまとめた、自己完結のバックエンド機能」 とされています。 ここが最初のポイントです。ふつう「認証」を実装するときは、①アプリ側の認証ロジック、②ローカルで動かすためのモックやDocker、③本番のCognitoやIAMの構成——この3つを別々に用意します。AWS Blocksの各Blockは、この3つを1つの部品として束ねて配布 します。必要なBlockを選んで組み合わせれば、AWS Blocksがベストプラクティスに沿ったAWSインフラを自動で定義し、アプリはAWSの資格情報なしにローカルで動き、同じコードを無改変で本番にデプロイできる ——これがコンセプトです。

読者の3問に先に答えておくと、「何ができる」＝AWSアカウント無しでフルスタックのバックエンドを型安全に書き、そのまま本番AWSへ持っていける。「何を解決する」＝ローカル用と本番用でコードやインフラ定義を二重に持つ手間、そしてサンドボックス取得の面倒。「何を代替する」＝新規アプリ立ち上げにおける “SDK＋IaC＋ローカルモック” の三点セットの手書き です。

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

基本情報（2026-07-02時点）

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

スター数が約345で、公開から約3週間という若さです。 「AWS公式が、Infrastructure from Codeという比較的新しいパラダイムをOSSで、しかもApache-2.0という緩いライセンスで出してきた」こと自体が、このプロジェクトの注目点です。数値としては小さくても、パラダイムとしての意味は大きいわけです。

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

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

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

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

仕組みは、Node.jsの 条件付きエクスポート（conditional exports） によるモジュール解決です。 同じインポート文に対し、実行される文脈ごとに違う実装が読み込まれます。READMEの「How it works」がそのまま3モードを列挙しています。

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

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

この設計は、型安全がバックエンドからフロントエンドまで一気通貫で流れることにもつながっています。 公式によれば、Webフレームワーク（Next.js / Nuxt / Astro / React / Vue / Svelte / Angular）向けには コード生成ステップなしで型が通り、ネイティブクライアント（Kotlin / Swift / Dart・Flutter）については blocks.spec.json（Blocksの仕様ファイル）からビルド時に型付きクライアントを生成し、実行時ライブラリがJSON-RPCでバックエンドを呼び出します。 つまり「バックエンドで型を1回定義すれば、Web・モバイル・デスクトップのどのクライアントでも同じ型が効く」——これが「Blockはランタイムのコードとインフラを一体で書ける」という主張の実体です。

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

AWS Blocksは20のBlockを提供し、フルスタックでよくある機能をカバーします。 Blockはそれぞれ個別のnpmパッケージとして公開され、傘パッケージ @aws-blocks/blocks が全Blockとコアランタイムを再エクスポートします。カテゴリごとに整理すると次のとおりです（READMEの一覧より）。

「何を代替するのか」を具体化するために、各Blockがデプロイ時にどのAWSサービスに化けるのかも押さえておきましょう。 ただし注意点として、公式が明言しているのは KVStore → Amazon DynamoDB のみ です。以下の対応表は、Block名・一般的なAWS構成・第三者レポートからの 推定を含みます。実際にどのサービスが使われるかはデプロイ時のCDK合成で決まるため、正確な対応は公式ドキュメントで確認してください。

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

・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-blocks/index.ts、フロントエンドは src/ に書き、型は生成ステップなしで端から端まで流れます。ここまでにAWSの資格情報は一度も要りません。

雛形は用途別のテンプレートも選べます。--template <name> で default / nextjs / react / auth-cognito / demo / bare / backend / amplify を指定でき、ディレクトリを省略して既存プロジェクト内で実行すれば、そのプロジェクトに aws-blocks/ バックエンドを追加できます。CLIはAWS Amplify Gen 2プロジェクトを自動検出して統合する、という記述もREADMEにあります。 料金体系も「AWS Blocks自体は追加料金なし、使ったAWSサービスの分だけ課金」とされており、ローカル開発のあいだはコストゼロです。

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

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

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

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

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

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

エミュレータ系の選び方そのものは、すでに本サイトで詳しく扱っています。 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とは目的が重なりません。

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部品は、人間にとってもエージェントにとっても「踏み外しにくい」ガードレールとして働く、という発想です。細かいIAM権限やリソース名を毎回手で書かせるより、new KVStore(...) のような1行に寄せたほうが、生成AIが正しいコードを書きやすい——ここは「AWSがなぜ今このパラダイムを推すのか」を理解するうえで重要な補助線になります。

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

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

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

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

AWS Heroesコミュニティの記事も、サンドボックスアカウントの取得という障壁を取り払い、「ノートPC上でAWS資格情報ゼロのまま自己完結する部品でアプリを書き、検証できたら実インフラへデプロイできる」点を、このツールの本質的な価値として挙げています。開発の入口で「まずAWSアカウントとIAMを整える」という重い儀式が消えるのは、学習用途やハッカソン、社内PoCでは特に効いてきます。

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

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

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

まず、まだPreview です。 Apache-2.0のOSSとはいえGitHubスターは約345（2026-07-02時点）、npm公開版は v0.1.6 と公開直後で、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（スター約345 / npm v0.1.6）。本番採用は時期尚早だが、AWS公式がIfCをOSSで出した意義は大きい

参照ソース

・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）