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
  1. What is AWS Blocks? A new framework for testing AI agents locally without an AWS account
  2. Infrastructure actually generated (example of 104 resources and how to check with cdk synth)
  3. Steps from local launch to production deployment (npm run dev / deploy / destroy)
  4. KnowledgeBase + RAG and HITL (needsApproval) mechanism
  5. Comparison with building from scratch (differences in wiring volume, resources, and development speed)
  6. Caveats and best practices (destroy is mandatory, Auth switching, billing management)
  7. Frequently Asked Questions (FAQ)
  8. 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)

Q: Can AWS Blocks really run without an AWS account?

Yes. Specifying sandboxMode=true allows it to run in a local mock environment without an AWS account. Tool calls and HITL wiring verification are possible. However, production deployment requires an AWS account and Bedrock access permissions.

Q: What is the difference between the local mock and production Bedrock?

Locally it uses TF-IDF simple search. In production it runs high-precision RAG combining Bedrock Claude Sonnet 4 and Knowledge Base. Local is for wiring verification; production is for real operation.

Q: Is it realistic to write all 104 resources yourself?

Not realistic. Building from scratch requires hundreds of lines of CDK code, but AWS Blocks auto-generates equivalent resources with just a few lines of Block definitions.

Q: How is the HITL approval flow implemented?

Simply set needsApproval: true on the Block to enable it. When the agent determines a critical decision is needed, it enters an approval-waiting state and proceeds after manual approval.

Q: How are Knowledge Base documents managed?

Any Markdown files placed in the ./knowledge/ directory are automatically indexed. Regular updates and cleanup of old files are recommended.

Q: How much does it cost?

Local testing is free. After production deployment, charges for Bedrock, Lambda, DynamoDB, etc. apply. Always run destroy and monitor with Cost Explorer.

Q: How do I delete after deployment?

Use the npm run destroy command to delete the entire stack. Leaving resources risks charges, so always run it after testing.


Related articles:

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.

krona23

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.

DevGENT about →

Leave a Reply

Trending

Discover more from DevGENT

Subscribe now to keep reading and get access to the full archive.

Continue reading