インフラを学ばずにAWSバックエンドを組む — AWS Blocksは何を肩代わりし、どこでCDKに"降りる"のか
AWS Blocksがパブリックプレビューで登場しました。インフラツールを学ばずにAWS上でフルスタックのバックエンドを組むOSS(Apache-2.0)のTypeScriptツールキットで、同一コードがローカル開発／CDK→CloudFormation／Lambdaランタイムの3コンテキストに自動で切り替わります。CDK(上位抽象)・Amplify(補完関係)との違い、Block→AWSサービスの対応(DynamoDB/Aurora DSQL/Bedrock/S3…)、抽象を外しても自分が所有するCFnスタックが残るロックインの軽さ、プレビュー段階でどの案件に使えるかをAWSフリーランス実務目線で整理します。本番可否やSLA・GA時期は公式の最新情報もご確認ください。
- #AWS Blocks
- #TypeScript
- #サーバーレス
- #IaC
- #CDK
- #開発生産性
TypeScript でフルスタックのアプリを作るとき、DB・認証・バックグラウンド処理・通知などをひとつずつ AWS で組み上げる手間に時間を取られた経験はないでしょうか。私もMVPや小規模案件で、「アプリ本体より周辺のインフラ設定に時間がかかる」という相談をよく受けます。かといって特定のツールに深く縛られるのも避けたい——そんな悩みに関わる発表が2026年6月16日にありました。AWS が「AWS Blocks」をパブリックプレビュー（一般公開前の試用提供）として公開した、というものです。
AWS Blocks は、インフラツールを学ばずに AWS 上でフルスタックのバックエンドを組むための、OSS（Apache-2.0 ライセンス）の TypeScript ツールキットです。この記事では、何を肩代わりしてくれるのか、CDK や Amplify と何が違うのか、そして「どこで CDK に降りられるのか（＝ロックインの心配はどうなるのか）」、プレビューの今どんな案件に使えるのかまでを整理してみましょう。煽らず、断定できないところは正直に「公式をご確認ください」と書きます。
背景：なぜいま「バックエンド構築フレームワーク」なのか
フルスタックの TypeScript 開発では、フロントは速く書けても、その裏側で動く AWS のリソースを用意する部分が負担になりがちです。CDK や SAM といった IaC（Infrastructure as Code＝インフラをコードで定義する手法）には学習コストがあり、一方で「インフラを意識せず速く作りたい」という需要も根強くあります。
ここで鍵になるのが infrastructure from code（コードからインフラを導く） という考え方です。インフラを別途定義するのではなく、アプリのコードを書くと、そこから必要な AWS リソースが自動的に導かれる、という発想です。「速く作りたい」と「将来は細かく制御したい・ロックインは避けたい」を両立させたい、という現場の要求に応えようとするのが、今回のツールキットだと位置づけられます。
AWS Blocksとは：同一コードが3つのコンテキストに自動で切り替わる
AWS Blocks の中心にあるのが「Block」という単位です。ひとつの Block は、アプリのコード・ローカル開発用の実装・実行に必要なインフラを束ねた、自己完結したバックエンド機能です。npm パッケージとして配布され、npx @aws-blocks/create-blocks-app で開発を始められます。Block 同士は自由に組み合わせられます。
技術的な肝は conditional exports（Node.js が読み込む文脈に応じて、同じ名前でも実体の実装を切り替える仕組み）です。これにより、同じコードが次の3つのコンテキストに、コードを書き換えずに切り替わります。(1) ローカル開発——メモリやファイルシステムで動き、AWS アカウントすら要りません。(2) CDK シンセシス——CDK の定義を組み立てて（シンセシス＝合成）、CloudFormation（AWS リソースの構成を記述するテンプレート）を生成します。(3) Lambda ランタイム——本番では SDK 経由で実際の AWS サービスを呼びます。たとえば new KVStore(...) の1行が、開発ではローカルのストア、デプロイ時には DynamoDB テーブル、本番では SDK 呼び出しになる、という具合です。
対応範囲も広く、Web（Next.js・Nuxt・Astro・React・Vue・Svelte・Angular など）に加え、Swift・Kotlin・Dart/Flutter といったネイティブモバイルまでカバーし、型安全（型の不一致をコンパイル時に検出できること）がバックエンドからクライアントまで貫通します。対応プラットフォームは更新され得るので、最新は公式ドキュメントでご確認ください。
CDK・Amplifyと何が違うか：二層構造とロックインの軽さ
ここが記事のいちばんの本題です。「既存の CDK や Amplify とどう違うのか」を、公式の位置づけに沿って整理します。
公式は、AWS Blocks アプリはそれ自体が CDK アプリであると述べています。任意の CDK コンストラクト（CDK の部品）を Block と一緒に使え、既存の CDK スタックに Blocks を埋め込むこともできます。つまり CDK と競合するのではなく、その上に乗る高水準の抽象層という位置づけです。Amplify については、公式は補完関係だと明言しています。Amplify はホスティングや CI/CD、マネージドなバックエンド体験を担い、Blocks は型安全な infrastructure from code とローカルファーストな開発に焦点を当てる、という役割分担です。なお、SAM や SST との比較は公式資料には見当たりません。思想が近いと語られることはありますが、それは公式見解ではないので、本記事では断定を避けます。
3者の位置づけを表にまとめます。優劣の順位づけではなく、役割の違いとして読んでください。
| 観点 | AWS CDK | AWS Blocks | AWS Amplify |
|---|---|---|---|
| 立ち位置 | 低レベルの土台。リソースをコードで細かく定義する | 高水準の抽象（二層構造）。Blocksアプリは中身がCDKアプリ | 補完関係。ホスティング・CI/CD・マネージド体験 |
| Blocksとの関係 | Blocksの下層。制御が要ればここへ降りて直接設定できる | — | 公式に「補完」と明言（優劣でなく役割分担） |
| ロックインの軽さ | — | デプロイ実体は標準のCDK→CFn。抽象を外しても自分が所有するCFnスタックが残る（生成物の構造はプレビューゆえ変わり得る） | — |
差別化の核は、この二層構造にあります。普段は高水準の抽象で速く作り、より細かい制御が必要になったら CDK に「降りて」直接設定できる——公式の言葉では「抽象に縛られて詰むことはない（never stuck in an abstraction）」と表現されています。デプロイの実体が標準の CDK から CloudFormation である以上、抽象を外しても、自分が所有する CloudFormation スタックが手元に残ります。独自のコントロールプレーン（管理基盤）に囲い込まれない、という意味で、ロックインが比較的軽いと言えます。導入も1 Block ずつ進められ、組み込みの移行パスで既存バックエンドに段階的に足していけます。ただし、プレビュー段階のため、生成される CloudFormation テンプレートの構造は今後変わり得ます。この点は公式リポジトリで最新をご確認ください。
Block→AWSサービス早見表：1行で何のサービスが立つか
「抽象的で中身が見えない」と不安になるかもしれませんが、各 Block の下回りは使い慣れた AWS サービスです。主な対応を早見表にまとめます（2026年6月時点の公式 Developer Guide 準拠。最新は公式でご確認ください）。
| カテゴリ | Block | 下回りのAWSサービス |
|---|---|---|
| データ／ストレージ | KVStore / DistributedTable | Amazon DynamoDB |
| Database | Amazon Aurora Serverless v2 | |
| DistributedDatabase | Amazon Aurora DSQL | |
| FileBucket | Amazon S3（presigned URL対応） | |
| 認証 | AuthBasic | Amazon DynamoDB＋JWT |
| AuthCognito | Amazon Cognito | |
| AuthOIDC | OAuthリダイレクトフロー | |
| バックグラウンド | AsyncJob | Amazon SQS＋AWS Lambda |
| CronJob | Amazon EventBridge＋AWS Lambda | |
| AI | Agent | Amazon Bedrock |
| KnowledgeBase | Amazon Bedrock Knowledge Bases | |
| 通信 | Realtime | Amazon API Gateway WebSocket |
| EmailClient | Amazon SES | |
| 設定 | AppSetting | AWS Systems Manager Parameter Store |
| 可観測性 | Logger / Metrics / Dashboard | Amazon CloudWatch |
| Tracer | AWS X-Ray | |
| ホスティング | Hosting | Amazon CloudFront＋Amazon S3 |
補足すると、FileBucket の presigned URL は、署名付きの一時 URL でファイルを直接やりとりする仕組み、KnowledgeBase は文書を意味で検索する RAG（検索した情報を生成 AI の回答に活用する手法）の土台です。中身が見えるサービスがそのまま立つので、後から各サービスの作法で踏み込める安心があります。
この早見表は、それぞれの掘り下げ記事への入口にもなります。DistributedDatabase の下回りである Amazon Aurora DSQL、Agent が使う Bedrock 系では Amazon Bedrock AgentCore、KnowledgeBase の RAG を安価に支える保存層として Amazon S3 Vectors、AsyncJob や CronJob が乗るサーバーレス基盤の起動コストとして AWS Lambda SnapStart for Python も、あわせて読んでみてください。Agent ブロックで使うモデルの選択肢としては Grok 4.3 on Bedrock を、エージェントの各ステップに安全策を足すなら Bedrock Guardrails の新API（InvokeGuardrailChecks） も参考になります。
どの案件で使うか、プレビューの制約
最後に、自分の案件に採用すべきかを考える材料を整理します。
向きやすいケースは、小〜中規模やMVP、スタートアップ開発で速く形にしたい場合、型安全をバックエンドからフロントまで通したい場合、AWS アカウントなしでローカル完結の開発をしたい場合、将来は CDK で細かく制御したい・ロックインを避けたい場合、そして Agent や KnowledgeBase で生成 AI 機能を素早く足したい場合です。
慎重に判断したいケースは、本番運用に SLA やサポート体制が要件として求められる場合、既存の IaC 資産が厚い大規模システム、プレビュー仕様や API の変動を業務に組み込みづらい場合です。
誠実にお伝えしておきたい点を挙げます。AWS Blocks は現時点でパブリックプレビューであり、本番運用の可否・SLA・ロードマップ・サポート体制は公式に明記されていません。GA（一般提供）の時期も未公表です。全商用リージョンへデプロイでき、東京リージョンでも技術的には利用できますが、日本での実運用の知見はまだ広く共有されていません。料金については追加料金はなく、使った分の AWS サービス料金のみがかかります（具体的な単価はワークロード次第のため、ここでは出しません）。いずれも仕様は変わり得るので、採用前に公式の最新情報とリポジトリをご確認ください。
まとめ
ポイントを3つに絞ります。
- AWS Blocks は、インフラを学ばずに AWS バックエンドを組む OSS（Apache-2.0）の TypeScript ツールキットで、同一コードがローカル開発／CDK→CloudFormation／Lambda ランタイムの3コンテキストに自動で切り替わります。
- 公式の位置づけでは CDK は上位抽象・Amplify は補完関係で、差別化の核は二層構造です。抽象を外しても自分が所有する CloudFormation スタックが残るため、ロックインが比較的軽いと言えます（生成物の構造はプレビューゆえ変わり得ます）。
- 現状はパブリックプレビューで、SLA・ロードマップ・GA 時期は未公表です。採否は案件の規模と要件で判断し、最新は公式の情報・リポジトリでご確認ください。
最近の発表を横断して読みたい方は AWS最新サービスの解説ハブ もどうぞ。インフラの細部に時間を取られず、フルスタックの TypeScript やサーバーレスで素早く形にできる力は、小回りの利く案件で評価されやすい領域だと感じています。