AWS Blocksとは？Blockの一覧・ローカル開発・CDKとの違いと採用判断

AWS Blocksは、データベース・認証・リアルタイム通信・AIエージェントといったバックエンド機能を「Block」という部品として組み合わせ、TypeScriptだけでAWS上のバックエンドを構成するオープンソースのツールキットです。2026年6月16日にPublic Previewとして公開され、本記事執筆時点（2026年9月23日）の最新版は@aws-blocks/blocks 0.6.0です。公開直後から提供されるBlockも開発フローも入れ替わっているため、本記事では公式のデベロッパーガイドとnpm・GitHubの一次情報で現行仕様を確認し、20種類のBlockとAWSサービスの対応、ローカル開発の実体と限界、AWS CDKやAmplify Gen 2との使い分け、既存構成への組み込み、Preview段階での採用判断までを整理します。GPUを予約するEC2 Capacity Blocksとは別物である点も切り分けます。

まとめ｜AWS Blocksの現状と採用判断の結論

AWS Blocksは、インフラ定義を別ファイルに書かず、アプリケーションコードからインフラを導出する「infrastructure from code」型のツールキットです。npm run devでAWSアカウントもコンテナデーモンも不要のローカル環境が起動し、同じコードを無変更でAWSにデプロイできます。フレームワーク自体は追加料金なしで、課金は実際に使ったAWSサービス分だけです。

結論として、PoCや社内ツール、新規SaaSの立ち上げを素早く回したいチームには有力な選択肢です。一方で2026年9月時点でも0.x系のPublic Previewであり、本番の基幹系や構成を長期間固定したい要件では全面採用を見送るのが妥当です。採用するなら、Block IDを変更すると保存済みデータが失われるという公式の警告を先にチームへ共有してください。判断の軸は「0.x系の変化を許容できるフェーズかどうか」に集約されます。

AWS Blocksの定義と現行バージョン｜Preview公開後3か月の変化

定義｜Blockという完結した機能単位でバックエンドを組む仕組み

1つのBlockは、クラウドリソース・実行時API・ローカル実装をまとめた完結した機能単位で、それぞれが個別のnpmパッケージとして公開されています。公式は「すべてのBlockは他のすべてのBlockと組み合わせて動作するため、どの組み合わせでも機能するバックエンドになる」と説明しています。必要なBlockを選べば、AWSのベストプラクティスに沿ったインフラ構成が自動的に定義されます。仕様の一次情報はAWS Blocksデベロッパーガイドにあります。アンブレラパッケージの@aws-blocks/blocksが各Blockとコアランタイムを再エクスポートします。ライセンスはApache-2.0、リポジトリはaws-devtools-labs/aws-blocksです。

現行バージョンと更新頻度｜2026年9月時点で0.6.0・3か月で17リリース

npmレジストリで確認できる最新版は、2026年9月23日時点で@aws-blocks/blocksが0.6.0、@aws-blocks/coreが0.5.0で、どちらも公開日は2026年9月17日です。初版0.1.0は2026年6月15日（日本時間16日）公開で、そこから0.6.0までに17のバージョンが出ています。GitHubリポジトリはスター394・フォーク49・コントリビューター28名で、クローズ済み70件に対して未解決のIssueが25件あります。@aws-blocks/blocksの週次ダウンロードは5,051件（2026年9月15日から21日）です。検証時は実行日と各パッケージのバージョンを記録しておくと再現性を確保できます。

動作原理｜conditional exportsとIFC層・ApiNamespace

IFC層とScope｜1つのファイルからインフラを導出する構造

バックエンドの入口はaws-blocks/index.tsで、公式はこれをIFC（Infrastructure from Code）層と呼びます。ここでBlockを生成してAPIを定義すると、AWS Blocksがそのコードから直接インフラを導出します。従来のInfrastructure as Codeが要求する別管理のインフラ定義ファイルは不要です。IaC側の考え方と対比すると差がはっきりするので、前提はIaCとは？Infrastructure as Codeの仕組み・メリットと導入判断で押さえてください。すべてのBlockはScopeの中に生成し、BlockのフルIDはScope名と指定したIDから導かれます。

import { ApiNamespace, Scope, KVStore, AuthBasic } from '@aws-blocks/blocks';

const scope = new Scope('my-app');
const auth = new AuthBasic(scope, 'auth');
export const authApi = auth.createApi();
const todos = new KVStore(scope, 'todos', {});

export const api = new ApiNamespace(scope, 'api', (context) => ({
  async createTodo(title: string) {
    const user = await auth.requireAuth(context);
    const todoId = crypto.randomUUID();
    await todos.put(`${user.username}:${todoId}`, { title, done: false });
    return { todoId };
  },
}));

conditional exportsの4条件｜実行文脈によるimport先の切り替え

AWS BlocksはNode.jsのconditional exports（条件付きエクスポート）を使い、同じimport文を実行文脈ごとに別ファイルへ振り分けます。条件はdefault（ローカル実装）・cdk（CDKコンストラクト）・aws-runtime（AWS SDK実装）・browser（フロントエンドへバンドルされるコード）の4つです。ローカル実装がdefaultなので、テストランナーや自作スクリプトからバックエンドをimportしても自動的にローカル実装になり、ローカルモードを有効化する操作は要りません。公式は「バックエンドをLambda用にバンドルするときだけaws-runtime条件を適用するため、ローカル開発中にAWS SDKが読み込まれることはない」と明記しています。

ApiNamespaceとBlocksContext｜コード生成なしの型安全RPC

ApiNamespaceは、フロントエンドから直接呼べる型安全なバックエンドメソッドを定義するBlockです。フロントエンドはimport { api } from 'aws-blocks'と書くだけで、クライアント生成・APIのURL設定・SDKの初期化が不要です。バックエンドのメソッドシグネチャを変えると、フロントエンド側で即座にコンパイルエラーになります。呼び出しはローカルではHTTPサーバー経由、本番ではAPI Gateway経由でLambdaに届きます。cookieやヘッダーを扱うBlockは、ハンドラーに渡されるBlocksContextを引数で受け取ります。ただしこの「生成なし」はWeb向けの話です。Swift・Kotlin・Dart（Flutter）向けのネイティブクライアントは、blocks.spec.jsonからビルド時に型付きクライアントを生成し、JSON-RPCでバックエンドを呼ぶランタイムライブラリと組み合わせます。

提供される20種類のBlockとAWSサービスの対応関係

デベロッパーガイドが一覧している20種類のBlockについて、ローカル実装とAWS上の実体を対応させたものが下表です。同じ型付きAPIのまま裏側だけが差し替わる、という関係が読み取れます。

DatabaseとDistributedDatabaseの違い｜Aurora Serverless v2とAurora DSQL

表のうち取り違えが起きやすいのが2つのSQL系です。DatabaseはKyselyクエリビルダー経由のSQLを提供し、AWS上ではAurora Serverless v2（PostgreSQL）へ展開されます。一方DistributedDatabaseはAurora Serverless v2ではなくAmazon Aurora DSQLにデプロイされます。DSQLにはPostgreSQL非対応の機能があるため、選ぶ前にAmazon Aurora DSQLとは？DPU課金の仕組みとPostgreSQL非対応機能・採用可否の判断基準で制約を確認してください。ローカルではDistributedDatabaseがPGliteにDSQL互換の検証層を重ねるため、DSQLが受け付けないSQLはデプロイ時ではなく手元で失敗します。

認証Blockの選定基準｜AuthBasicの適用範囲とAuthCognitoの機能差

認証は3種類で、性格がはっきり違います。AuthBasicはbcryptでハッシュ化した資格情報をDynamoDBに保存しJWTでセッションを管理する方式で、公式はこれを「プロトタイプと社内ツール向け」とし、本番にはAuthCognitoを推奨しています。AuthCognitoはMFA・グループ・パスキー・SAML／OIDCフェデレーション・アカウント復旧に対応します（Amazon Cognito（コグニート）とは？料金・できること・使い方）。AuthOIDCはGoogle・GitHub・Oktaなど準拠プロバイダーへのリダイレクトフローを担います。

通信・設定・観測性・Hosting｜初版から揃っていた残り8種

残る8種類は、メール送信のEmailClient、設定と機密情報を扱うAppSetting、観測性の4種類（Logger・Metrics・Tracer・Dashboard）、リアルタイム通信のRealtime、フロントエンド配信のHostingです。これらは新機能ではなく、初版0.1.0の配布物にもほぼ揃っていました（0.1.0と0.6.0のtarballを比べると、アンブレラパッケージの依存に加わったのはhostingと内部用のbb-lambda-computeだけです）。3か月で変わったのはBlockの品揃えではなく各Blockの挙動だという点が、採用判断では重要になります。

Hostingだけは扱いが他と違います。CloudFrontとS3オリジン、SSR用のLambda、任意のWAF、CloudWatchアラーム、ローリングデプロイ中の利用者を単一ビルドに固定するskew protection（既定で有効）までを1つのコンストラクトで作り、IFC層ではなくCDK層に置きます。npm run deployには含まれますが、npm run sandboxはバックエンドのホットスワップに集中するためHostingを省きます。

ローカル開発の実体と限界｜.bb-dataに置かれる本物のPostgres

ローカル実装の中身とテスト戦略｜「すべてモック」とは言えない部分

ローカル環境はNode.js 22以降さえあれば動き、AWSアカウント・認証情報・インターネット接続・コンテナデーモンのいずれも不要です。押さえておきたいのは、ローカル実装を単なるモックと理解すると判断を誤る点です。DatabaseはWebAssembly製の組み込みPostgresであるPGliteを使い、マイグレーション・トランザクション・行レベルセキュリティまで実際に動きます。LoggerとMetricsは本番と同じコードパスを通り、出力先だけが端末とCloudWatchで違います。一方でDashboardはローカルに相当物が無く、デプロイを促すメッセージを返すだけです。

永続化するBlockは、プロジェクト直下の.bb-data/にBlockごとのサブディレクトリを作って書き込みます。素のファイルなのでエディターで直接開けて、再起動してもテーブル行が残ります。EmailClientは送信せずemails.jsonへ書き出すため、パスワード再設定の文面をテストから読んで検証できます。初期化は.bb-data/ごと、または特定Blockのサブディレクトリだけを削除します。テストは単体・ローカル実装への結合・sandboxへのエンドツーエンドの3階層に分けるのが公式の推奨で、手前の2階層は手元で完結します。

ローカル実装の限界｜sandboxで確認するIAM・クォータ・実サービス挙動

ローカル実装はAPIレベルで本番と揃っていますが、AWSサービス自体の挙動は再現されません。IAMの権限境界、サービスクォータとスロットリング、規模が出たときのDynamoDBのクエリ性能、Bedrockの実際のモデル出力は、npm run sandboxでAWSに出してから確かめる領域です。公式のトラブルシューティングは、ローカルと本番で挙動が変わる原因としてDynamoDBの400KBのアイテムサイズ上限、ページネーション（ローカル実装は全件を1レスポンスで返す）、Auroraの接続数上限、Lambdaのコールドスタートを挙げています。ページネーションの差はローカルで通ったコードが本番だけで取りこぼす典型なので、一覧取得の実装では意識する価値があります。

AWS BlocksとCDK・Amplify Gen 2・SAMの使い分け

AWS CDKとの関係｜土台であり、いつでも降りられる設計

AWS BlocksのアプリケーションはCDKアプリケーションです。任意のCDKコンストラクトをBlockと並べて使えますし、既存のCDKスタックへ組み込むこともできます。抽象化で表現しきれない制御が必要になったら、CDK層（aws-blocks/index.cdk.ts）でリソースを直接設定できます。CDK層を作らなければIFC層から既定のCDKアプリケーションが自動生成されます。土台側の概念はAWS CDK（cdk）とは？仕組み・使い方とCloudFormation・Terraformとの違いで押さえると、Blocksが何を肩代わりしているかが見えてきます。

Amplify Gen 2・SAMとの違い｜補完関係と抽象度の差

AWS公式は、BlocksとAmplifyを競合ではなく補完関係と説明しています。Amplifyがホスティング・CI/CD・マネージドなバックエンド体験を担うのに対し、AWS Blocksは型安全なinfrastructure from codeとローカルファースト開発に重心を置きます。プロジェクト作成CLIはAmplify Gen 2を自動検出して統合し、amplifyテンプレートも用意されています（AWS Amplify Gen 2の使い方：ampxで初期化からCI/CDまで）。SAMやServerless Frameworkとの違いは抽象度です。これらが「関数とイベントを宣言する」レイヤーである一方、AWS Blocksは「データベースや認証といった機能Blockを組み合わせる」上位のレイヤーで、ローカル実行と型安全をまとめて提供します。

既存AWS構成との統合｜部分採用の4パターン

新規プロジェクト向けの紹介に偏りがちですが、公式は既存インフラとの併存を4パターンとして整理しています。既存資産を持つチームでは、ここが実際の採用可否を左右します。

fromExistingで既存リソースを包む｜最も手数が少ない選択

一部のBlockは、すでにデプロイ済みのAWSリソースを包めます。Blockは型付きAPIとローカル実装を提供しつつプロビジョニングを省き、リソースの所有権は元のまま残ります。対応するのはKVStore.fromExisting（DynamoDBテーブル）・DistributedTable.fromExisting（同）・FileBucket.fromExisting（S3バケット）・Database.fromExisting（RDSインスタンス）・AuthCognito.fromExisting（Cognitoユーザープール）です。

const sessions = new KVStore(scope, 'sessions', {
  table: KVStore.fromExisting('my-legacy-sessions-table'),
});

このパターンではローカル開発が維持され（npm run devは実テーブルではなくローカルストレージを使う）、Lambdaへの権限も自動で付与されます。制約は2つで、BlockのAPIが公開していない機能は使えず、クロスアカウントのリソースはIAMを手で設定します。

CDK直書き・カスタムBlock・vendorizeの選び分け

該当するBlockが無いリソースは、CDKを直接書いて併存させます。BlocksStack（Blocks専用のスタック）かBlocksBackend（既存スタックに差し込むコンストラクト）を使い、どちらも公開する.handlerへ権限付与や環境変数の注入を行います。BlocksBackend.create()は非同期なので、コンストラクターではなく静的ファクトリーメソッドから呼びます。このパターンにはローカル実装が無くnpm run devでも実際のAWSを呼ぶため、スタブは自分で用意します。同じパターンを2箇所以上で繰り返すなら、カスタムBlockに切り出すのが公式の判断基準です。AWSが提供するBlockでCDK側の変更だけが必要な場合はnpm run vendorizeでソースを取り込めますが、以後の保守と上流追従は自分の責任になります。

始め方と、公式ドキュメントが警告している運用上の罠

プロジェクト作成からsandbox・本番デプロイまで

必要な環境はNode.js 22以降とnpm 10以降です。npm create @aws-blocks/blocks-app@latest my-appでプロジェクトを作り、npm install後にnpm run devを実行すると、localhost:3000でフロントエンドとAPIが立ち上がります。既存プロジェクト内で実行すれば、aws-blocks/のバックエンドを後から足せます。AWSへ出す経路は2つで、npm run sandboxはLambdaのホットスワップを使う短命な環境（数分ではなく数秒で反映・開発者ごとに分離）、npm run deployはCDK経由の本番相当のデプロイです。いずれもアカウントとリージョンの組み合わせごとにnpx cdk bootstrapが一度必要で、撤収はnpm run sandbox:destroyとnpm run destroyです。

テンプレートは--templateで指定しますが、ここは情報源で食い違います。デベロッパーガイドのCLIリファレンスはdefaultとdemoの2つだけを挙げる一方、リポジトリのcreate-blocks-appパッケージにはamplify・auth-cognito・backend・bare・default・demo・nextjs・reactの8つが実在し、READMEもこの8つを列挙しています。公開版のタグ（[email protected]）でも8つが入っているため、掲載範囲が資料によって違うということです。選ぶときは、使うCLIのバージョンに対応した一覧を確認してください。なおbackendとamplifyだけは開発サーバーのAPIがlocalhost:3001になります。

Block IDの変更リスク｜リソースの再作成とデータ消失

公式のScopeの説明が警告として明記している落とし穴がこれです。コンストラクターの第2引数であるBlock IDを変更すると、対応するAWSリソースが次回のデプロイで削除・再作成されます。KVStore・DistributedTable・Database・FileBucketのような状態を持つBlockでは、これが恒久的なデータ消失になります。命名を後から整えたくなる場面は必ず来るため、デプロイ済みのBlock IDは不変として扱う運用を最初に決めておくべきです。リネームが避けられないなら、データ移行を伴う作業として計画してください。

料金とテレメトリ｜追加料金なしと、3通りの停止方法

AWS Blocks自体は追加料金なしで、公式発表の日本語版も「お支払いいただくのは、アプリケーションが使用する AWS のサービスに対してのみです」と述べています。デプロイ先は全商用リージョンです。一方、CLIは既定で匿名の利用データを送信します。停止方法は3つあり、npx blocks-telemetry --disable（--globalで全プロジェクト）、環境変数AWS_BLOCKS_DISABLE_TELEMETRY=1、.blocks/config.jsonでtelemetry.enabledをfalseにする方法です。現在の状態はnpx blocks-telemetry --statusで確認できます。CI/CDでは環境変数が扱いやすく、いずれかの方法で無効化すればAWS Blocksが起動するCDK CLI側のテレメトリも連動して止まるため、別途設定は不要です。

AWS Blocksを採用すべき場面と見送るべき場面

効くのはスピードが価値になる場面です。認証・ファイルアップロード・バックグラウンドジョブ・AIエージェントを一度の作業で足し、手元でフルスタックを検証してからAWSへ出せるため、PoCや社内ツール、新規SaaSの初期立ち上げと相性が良いです。既存資産がある場合もfromExistingで1つのBlockから部分採用でき、全面移行を決断せずに試せます。AIコーディングエージェント向けの指示ファイルがnpmパッケージに同梱されており、追加のプラグイン設定なしで実装指針を渡せる点も公式が前面に出す特徴です。

逆に、停止が許されない基幹系の基盤にはまだ向きません。リリース件数ではなく変更内容が理由です。@aws-blocks/core 0.5.0のCHANGELOGは観測性の作り直しを記録しており、LoggingOptionsのretentionオプション廃止（保持期間はcompute側のlogRetentionへ移動）、LoggerがLOG_LEVEL環境変数を読まなくなる変更、Tracerを1つ作るとアプリ内の全computeでX-Rayが有効になる挙動変更が明記されています。0.x系ではこうした変更がマイナー更新で入るため、追従には毎回CHANGELOGの確認と影響検証が必要です。構成を長期間固定したい要件も同様で、その運用コストが無視できません。IAMやネットワーク、レイテンシを厳密に作り込む要件では、検証の重心がAWS上に移るためローカル開発の恩恵が薄くなります。これらに当てはまるならCDKやAmplify Gen 2を主軸に据えてください。採用する場合でも@aws-blocks/*のバージョンはlockファイルで固定し、@latestでの無自覚な更新を避けます。

よくある質問

AWS Blocksは無料で使えますか？

フレームワーク自体は追加料金なしで、Apache-2.0のオープンソースとして公開されています。ローカル開発だけならAWSアカウントも不要です。費用はデプロイ後にアプリケーションが使う各サービス（Lambda、DynamoDB、Auroraなど）の標準料金分だけです。

AWS BlocksとAWS Amplifyはどう違いますか？

公式は競合ではなく補完関係と説明しています。Amplifyがホスティングやマネージドなバックエンド体験を担い、AWS Blocksは型安全なinfrastructure from codeとローカルファースト開発に重心を置きます。プロジェクト作成CLIはAmplify Gen 2を自動検出して統合でき、専用のamplifyテンプレートもあるため併用も想定されています。

AWS Blocksは本番環境で使えますか？

全商用リージョンへのデプロイは可能ですが、2026年9月時点でも0.6.0のPublic Previewです。停止が許されない基幹系での全面採用は時期尚早で、社内ツールや新規プロダクトの初期段階から始め、Block IDを不変に保つ運用を決めてから広げるのが現実的です。

ローカル開発にDockerやAWSアカウントは必要ですか？

どちらも不要です。必要なのはNode.js 22以降だけで、コンテナデーモンもエミュレーターも要りません。npm run devでPostgres（PGlite）・認証・リアルタイム通信・ファイル保存・バックグラウンドジョブが立ち上がり、データは.bb-data/に残るため再起動しても消えません。

EC2 Capacity Blocksとの違いは何ですか？

まったく別のものです。EC2 Capacity Blocks for MLは機械学習向けにGPUインスタンスの容量を予約する購入オプションで、本記事のAWS Blocksはバックエンドを構成するTypeScript製のツールキットです。VPCのCIDR blocksや「building blocks」という言い方とも関係ありません。

関連記事

• AWS CDK（cdk）とは？仕組み・使い方とCloudFormation・Terraformとの違い
• Amazon Aurora DSQLとは？DPU課金の仕組みとPostgreSQL非対応機能・採用可否の判断基準
• AWS Amplify Gen 2の使い方：ampxで初期化からCI/CDまで【2026年版】
• Amazon Cognito（コグニート）とは？料金・できること・使い方を初心者向けにわかりやすく解説
• IaCとは？Infrastructure as Codeの仕組み・メリットと導入判断を解説