AWS Blocks is a new framework that lets you test AI agents locally without an AWS account. By defining Blocks in just a few lines of CDK-based code, it automatically generates complex infrastructure and dramatically accelerates development. This article summarizes the features, procedures, and caveats based on official AWS information and the Zenn article.
📑Table of Contents
- What is AWS Blocks? A new framework for testing AI agents locally without an AWS account
- Infrastructure actually generated (example of 104 resources and how to check with cdk synth)
- Steps from local launch to production deployment (npm run dev / deploy / destroy)
- KnowledgeBase + RAG and HITL (needsApproval) mechanism
- Comparison with building from scratch (differences in wiring volume, resources, and development speed)
- Caveats and best practices (destroy is mandatory, Auth switching, billing management)
- Frequently Asked Questions (FAQ)
- Summary
What is AWS Blocks? A new framework for testing AI agents locally without an AWS account
AWS Blocks is an AI agent construction framework published by volunteers from Amazon Web Services Japan. By defining Blocks such as Agent and KnowledgeBase in just a few lines of code, CDK automatically generates complex resources.
The biggest feature is the ability to verify operations instantly in a local mock environment without an AWS account by specifying sandboxMode=true. Tool calls and Human-in-the-Loop (HITL) wiring can be validated immediately. Sources include the official AWS Bedrock Agents page and the Zenn introduction article.
In production, you can transition to a full RAG configuration combining Bedrock Claude Sonnet 4 and Knowledge Base. Locally, a simple TF-IDF search enables rapid iteration.
Infrastructure actually generated (example of 104 resources and how to check with cdk synth)
Defining just two lines for Agent + KnowledgeBase with AWS Blocks generates a total of 104 resources. Specific examples include 5 DynamoDB tables, 11 Lambda functions, and 3 S3 buckets, among others.
In production deployments, the resource count can grow further, with some cases reaching 120 resources. To check the generated content, run the following command:
npx cdk synth --app "npx tsx -C cdk aws-blocks/index.cdk.ts" --context sandboxMode=true
This command outputs a CloudFormation template locally so you can review resource definitions in advance. See the cdk synth examples in the Zenn article for details.
Steps from local launch to production deployment (npm run dev / deploy / destroy)
Local development is extremely simple. Clone the repository, install dependencies, and start with:
npm run dev
Running CDK synth with the sandboxMode=true context enables the local mock. To move to production deployment, configure AWS credentials, grant Bedrock access, and run:
npm run deploy
After deployment completes, always delete the stack when no longer needed:
npm run destroy
Leaving resources running risks unexpected charges, so destroy is a mandatory operational step. Also manage Auth switching and environment variables appropriately.
KnowledgeBase + RAG and HITL (needsApproval) mechanism
KnowledgeBase automatically indexes any Markdown files placed in the ./knowledge/ directory. Locally it uses TF-IDF simple search; in production it runs high-precision RAG powered by Bedrock Knowledge Base.
The HITL (Human-in-the-Loop) feature is enabled simply by setting needsApproval: true on a Block. When the agent determines a critical decision is needed, it enters an approval-waiting state; the user manually approves to proceed to the next step. This mechanism maintains safety while allowing flexible operation.
Comparison with building from scratch (differences in wiring volume, resources, and development speed)
| Item | Build from scratch | AWS Blocks |
|---|---|---|
| Wiring volume | Hundreds of CDK/IaC lines | A few lines of Block definitions |
| Resource count | Manual definition | 104 resources auto-generated |
| Development speed | Several weeks | Several hours to days |
| Local testing | Difficult | Immediate with sandboxMode=true |
Building an equivalent Agent + KnowledgeBase + HITL setup from scratch requires hundreds of lines of IaC code and wiring multiple services. AWS Blocks drastically reduces the definition volume and improves development speed. However, billing management and destroy procedures remain equally important in production operation.
Caveats and best practices (destroy is mandatory, Auth switching, billing management)
The most important caveat when using AWS Blocks is to always execute destroy. Leaving stacks after local testing can lead to unexpected charges.
Also, properly switch Auth information and avoid mixing sandboxMode with production mode. Regularly update Knowledge Base documents and organize old files to prevent stale information from entering the RAG.
When using billable services (Bedrock, Lambda, DynamoDB, etc.), periodically check usage with AWS Cost Explorer.
Frequently Asked Questions (FAQ)
Related articles:
- AIエージェントが自律的に自己改善する self-improvement スキルが良い
- 超高速ファイル検索fffが良さげかも | kawarimidoll.com
- 戦略17分野、フィジカルAIに10.5兆円 官民投資の全容が判明 – 日本経済新聞
Summary
AWS Blocks is a framework that balances rapid local AI agent development with smooth transition to production. The ability to generate 104-resource-scale infrastructure in just a few lines and the account-free testing via sandboxMode are major advantages.
When operating, be sure to thoroughly execute destroy and manage billing. For details, refer to the official AWS Bedrock Agents page and the Zenn introduction article.
As a next step, we recommend cloning the actual repository and trying npm run dev.
Author
krona23
Over 20 years in the IT industry, serving as Division Head and CTO at multiple companies running large-scale web services in Japan. Experienced across Windows, iOS, Android, and web development. Currently focused on AI-native transformation. At DevGENT, sharing practical guides on AI code editors, automation tools, and LLMs in three languages.








Leave a Reply