バックエンドの検証を始めるとき、実装したい機能より先に、データ保存や認証、API、権限などの準備が必要になることがあります。小さなアイデアを試したいだけなら、この準備に時間がかかるのは少しもどかしいところです。
そんな中、AWS Blocksというフレームワークがあることを知り、実際に触ってみました。
触ってみて便利だったのは、AWSに接続しなくても、データ保存や認証を含むAPIの流れを試せることです。少ないコードで実装を始められるので、PoCにも使いやすそうだと感じました。一方で、Previewということもあり、Blockの種類はまだ少なめです。すでにAmplify Gen 2を使っている場合は、「Amplify Gen 2でよくね？」と思う場面もありました。
この記事では、実際に試した範囲をもとに、AWS Blocksの仕組みとAmplify Gen 2との違いを整理し、どのような場面で使いたいかをまとめます。
試した環境
| 項目 | 内容 |
|---|---|
| 執筆時点 | 2026年9月17日 |
| OS | macOS |
| Node.js | v23.11.0 |
| npm | 10.9.2 |
| AWS Blocks |
@aws-blocks/blocks v0.5.0 |
| 確認した主な機能 |
KVStore、DistributedTable、ApiNamespace
|
| 試した範囲 |
local を中心に、sandbox と deploy の仕組みも確認 |
AWS BlocksはPreview中のため、仕様が変わる可能性があります。実際に試すときは、公式ドキュメントを確認してください。
AWS Blocks自体は追加料金なしで利用できます。ただし、sandbox や deploy でAWSリソースを作成した場合は、利用したAWSサービスの料金が発生します。
AWS Blocksとは
AWS Blocksは、認証やデータ保存、AI、非同期処理などのバックエンド機能を、Building Block（機能単位の部品）として組み合わせるTypeScriptフレームワークです。2026年6月にPublic Previewとして発表され、ローカルでバックエンドを動かしてからAWSへ持っていける点を特徴としています。
AWS Blocksの中心となる単位はBlockです。Blockは、1つの機能に必要な要素をまとめたnpmパッケージです。公式ドキュメントでは、AWSリソース、実行時の処理、ローカル実装をBlockにまとめる仕組みとして説明されています。
1つのBlockには、主に次の要素が含まれます。
| 要素 | 役割 |
|---|---|
| API | アプリケーションから呼び出すメソッド |
| ローカル実装 | AWSを使わずに動かす実装 |
| AWS上の実行時処理 | LambdaからAWS SDKでサービスを呼び出す実装 |
| インフラ定義 | デプロイ時にAWSリソースを作るCDKの定義 |
例えば DistributedTable は、ローカルではファイルベースのストアとして動き、デプロイ時にはDynamoDBのテーブルとして構成されます。アプリケーションからの呼び出し方は、どちらの環境でも変わりません。
ApiNamespace は、フロントエンドから呼び出すバックエンドAPIをまとめるためのBlockです。図では、アプリケーションから ApiNamespace を経由して、各機能Blockを呼び出す構成を示しています。
この実装の切り替えには、Node.jsのconditional exportsが使われています。同じ import 文でも、ローカル実行時、CDK synthesis時、Lambda実行時で読み込む実装が変わります。開発者が環境ごとの切り替え処理を個別に書く必要はありません。
少ないコードでAPIを作る
AWS Blocksでは、ApiNamespace にフロントエンドから呼び出したいメソッドを定義します。その中で AuthBasic や KVStore などのBlockを組み合わせます。
import { ApiNamespace, AuthBasic, KVStore, Scope } from '@aws-blocks/blocks';
const scope = new Scope('my-app');
const auth = new AuthBasic(scope, 'auth');
const notes = new KVStore(scope, 'notes', {});
export const api = new ApiNamespace(scope, 'api', (context) => ({
async putNote(key: string, value: string) {
const user = await auth.requireAuth(context);
await notes.put(`${user.username}:${key}`, value);
return { success: true };
},
async getNote(key: string) {
const user = await auth.requireAuth(context);
return { value: await notes.get(`${user.username}:${key}`) };
},
}));
フロントエンドからは、型付きのAPIとして呼び出せます。
import { api } from 'aws-blocks';
await api.putNote('message', 'Hello Blocks');
const note = await api.getNote('message');
バックエンドで定義したメソッドの引数や戻り値が、フロントエンドの呼び出し側にも型として反映されます。APIクライアントを生成したり、型を手作業で定義したりする必要はありません。
なお、ApiNamespace のメソッドに認証チェックが自動で付くわけではありません。保護が必要な処理では、今回の例のようにハンドラー内で requireAuth などの認証チェックを明示する必要があります。
local、sandbox、deployの使い分け
AWS Blocksには、主に3つの実行環境があります。
| 環境 | コマンド | 用途 |
|---|---|---|
| local | npm run dev |
ローカルで日々の開発やAPIの動作確認を行う |
| sandbox | npm run sandbox |
実際のAWSサービスを使ってAWS固有の挙動を確認する |
| deploy | npm run deploy |
継続利用する環境をAWSにデプロイする |
local では、AWSアカウントやAWSの認証情報なしでアプリケーションを動かせます。永続化に対応したBlockのデータは、プロジェクトルートの .bb-data/ に保存されます。
このlocal-firstの考え方が、AWS Blocksの大きな特徴です。まずローカルでアプリケーションの流れを作り、IAM権限、サービスクォータ、スロットリング、DynamoDBの大規模データ性能、Bedrockの実際のモデル出力など、AWS上でしか確認できない部分をsandboxで確認します。
ローカル実装でも、入力や状態を扱い、APIレベルの挙動を確認できます。例えば DistributedTable ではキーやインデックスを使った検索、FileBucket ではアップロードやダウンロード、署名付きURLの発行を試せます。
ただし、ローカル実装で確認できるのは、あくまでBlockが再現しているAPIの挙動です。AWSサービスの性能やIAMの境界は、ローカルでは確認できません。
.bb-data/ にはローカル開発用のデータが保存されます。実データや機密情報を入れず、バージョン管理にも含めないようにしてください。
AWS Blocksが自動化する範囲
Blockを使うと、対応するAWSリソースや権限まで自動で用意されます。ただし、自動化されるのは選択したBlockの責任範囲です。
| AWS Blocksが用意するもの | 開発者が決めるもの |
|---|---|
| Blockに対応するAWSリソース | 要件に合うBlockの選択 |
| AWS SDKを使った実行時処理 | システム全体の構成と認可 |
| Blockに必要なIAM権限 | 性能、可用性、料金、監視、バックアップ |
| APIレベルのローカル実装 | BlockにないAWSサービスの構成 |
Blockカタログにないサービスは、CDKを直接書いて追加できます。ただし、その部分のローカル実装や推奨構成は自分で設計する必要があります。
Amplify Gen 2とどう違うのか
AWS Blocksを触っていて、何度か「これ、Amplify Gen 2でよくね？」と思いました。
実際、認証やデータ保存など、重なる機能はあります。触った印象では、AWS Blocksは機能Blockを組み合わせていく仕組みです。一方、Amplify Gen 2はデータモデルを起点にバックエンド全体を構成します。AWS公式ドキュメントでも、両者は補完関係として説明されています。
その違いを、データ定義やAPIの作り方で比べてみます。
| 観点 | AWS Blocks | Amplify Gen 2 |
|---|---|---|
| 中心となる単位 | データ保存、認証、AIなどの機能Block | データモデルやバックエンドリソース |
| データの定義 |
DistributedTable などでテーブルの形を指定 |
a.model() でデータモデルを定義 |
| API |
ApiNamespace にメソッドを定義 |
AppSync GraphQL APIを構成 |
| 得意な開発体験 | Blockのローカル実装を使って開発する | Amplifyの機能を組み合わせてバックエンドを構成する |
Amplify Gen 2では、例えば次のようにデータモデルを定義します。
const schema = a.schema({
Todo: a
.model({
title: a.string().required(),
completed: a.boolean(),
}),
});
一方、AWS Blocksの DistributedTable では、partition keyやsort keyなど、DynamoDBテーブルの形をより直接的に指定します。
つまり、Amplify Gen 2では、アプリケーションのデータモデルを定義し、それをもとにAPIやテーブルを構成します。一方、AWS Blocksでは、必要なバックエンド機能をBlockとして組み合わせます。
使い分けは、必要な開発体験で決めるのがよさそうです。データモデルを中心にGraphQL APIや認証を組み立てるなら、Amplify Gen 2の方が自然です。AWSアカウントを使わずにバックエンド機能の組み合わせを試したいなら、AWS Blocksのlocal-firstが効いてきます。
すでにAmplify Gen 2を中心に開発しているプロジェクトなら、AWS Blocksへ全面移行する必要はないと感じました。AWS BlocksはAmplify Gen 2のバックエンドに組み込めるため、既存構成を残したまま、新しい機能だけで試す使い方が現実的です。
触ってみて良かったところ
ローカルだけでAPIの動きを試せる
一番良かったのは、AWSに接続せずにAPIの動きを確認できることです。
AWSでAPIを1つ試すだけでも、Lambda、API Gateway、DynamoDB、IAMなどの準備が必要になることがあります。AWS Blocksでは、Blockを組み合わせて npm run dev を実行すれば、ローカルでバックエンドを動かせます。
データの保存や取得、入力検証、認証を含むAPIの流れを、AWSリソースの作成を待たずに確認できます。フロントエンドからAPIを呼ぶところまでローカルで試せるので、画面とバックエンドの接続を確認する用途にも向いています。
すぐに実装へ入れる
AWSの各サービスを個別に組み合わせる場合と比べて、最初に書くコードを減らせます。
もちろん、実際のアプリケーションでは業務ロジックや認証・認可を設計する必要があります。エラー処理、監視、バックアップも必要です。それでも、最初の「とりあえず動くもの」を作るまでの距離は短く感じました。
PoCとの相性が良さそう
アイデアを検証するPoCでは、最初から本番用のAWS構成を作り込むより、まず画面とAPIの流れを確認したいことがあります。
AWS Blocksなら、ローカルでバックエンドの動きを作り、必要な段階でsandboxへ進めます。AWSサービスの選定やIAMの細かい設定に入る前に、機能の方向性を確認できる点は、PoCと相性が良さそうです。
気になったところ
PreviewなのでBlockの選択肢が少ない
今回触った時点では、Blockの種類がまだ少なく感じました。
認証、データ保存、ファイル保存、AI、非同期処理、リアルタイム通信など、アプリケーションでよく使う機能は用意されています。ですがBlockカタログで対応している機能には、まだ限りがあります。
Blockカタログにないサービスは、CDKを直接書いて追加できます。しかし、その場合はローカル実装や推奨構成を自分で考える必要があります。AWS Blocksの「同じコードでローカルとAWSを動かす」体験をそのまま得られるのは、Blockとして提供されている機能に限られます。
AWS固有の検証は結局必要
本番環境では、ローカル実装では分からない項目も確認する必要があります。
例えば、IAM権限の設定が本当に適切か、DynamoDBの性能が要件を満たすか、Bedrockのモデル出力が期待通りか、といった確認にはsandboxや実環境を使います。
AWS Blocksは、AWSで確認するタイミングを後ろにずらし、最初に確認する対象を絞るための仕組みだと理解しました。
どんなときに使いたいか
個人的には、次のような場面で使いたいです。
- 新しいサービスや機能の方向性を確認する小規模なPoC
- フロントエンドとバックエンドAPIの接続を早く試したいとき
- AWSの複数サービスを使う機能を、まずローカルで組み立てたいとき
すでにAmplify Gen 2で大きなバックエンドを運用している場合は、全面移行よりも、独立した機能や新しいサブシステムの試作にAWS Blocksを使う方がよさそうです。
まとめ
AWS Blocksを触ってみた感想は、次のとおりです。
- ローカルだけでバックエンドとAPIの動きを試せるのは便利
- 少ないコードで実装を始められるので、PoCと相性が良さそう
- Previewということもあり、現時点ではBlockの種類が少なく感じる
- すでにAmplify Gen 2を使っている場合、全面移行するほどの理由はまだ感じない
今回の感想をまとめると、AWS Blocksは既存システムの置き換え候補というより、ローカルで素早く試したい機能に使うフレームワークです。Amplify Gen 2を使っている場合も、既存のバックエンドを残したまま、独立した機能や新しいPoCでAWS Blocksを試す使い方がよさそうです。
今後Blockの種類が増え、Previewから正式版へ進んでいくと、Amplify Gen 2と組み合わせる選択肢としても検討しやすくなりそうです。