Bedrock Agent Blueprint: Deploying Strands Agents on AWS AgentCore
TL;DR: A GitHub template for deploying a tool-using AI agent on AWS Bedrock AgentCore using Strands + Docker + Terraform, with a clean, repeatable build/push/apply workflow.
Most AI agent demos stop at localhost. Production is where things get real: container images, infrastructure state, IAM permissions, versioning, and repeatable deployments. That gap between “it works on my laptop” and “it runs reliably in the cloud” is what this template is designed to close.
I’ve been exploring the infrastructure side of AI for a while. Models are improving rapidly, but production systems still fail for boring reasons: inconsistent environments, manual deployments, drifting configurations. If you want agents to be reliable, you need reproducibility first.
AWS has been moving in a direction that makes this practical. With Bedrock as the model layer and AgentCore as the managed runtime, you get isolation, scaling, and traceability built into the platform. That makes it possible to treat agents as deployable infrastructure rather than experiments.
To test that approach, I built bedrock-agent-blueprint: a GitHub template that deploys a simple Strands-based agent into AWS using Docker and Terraform.
GitHub: https://github.com/weijianzhg/bedrock-agent-blueprint
Why Strands Agents?
Strands Agents (https://strandsagents.com/latest/) is a lightweight Python agent framework that integrates cleanly with AWS Bedrock models and keeps tool wiring explicit. It avoids excessive abstraction while still giving you structured agent behaviour. That makes it a good fit for production-oriented deployments where you want clarity.
Deployment Model
The project is set up as a GitHub template. Click “Use this template” and you get a clean copy of the repository.
From there, the workflow is simple and repeatable:
# edit terraform variables (you only need to do this once)
cp infra/terraform.tfvars.example infra/terraform.tfvars
# build and push the agent image
./scripts/build_and_push.sh
# deploy infrastructure and agent runtime
terraform -chdir=infra init
terraform -chdir=infra apply -var="container_tag=<git-sha>"Each deployment is tied to an immutable container tag. That means your infrastructure state and runtime image stay version-aligned. If something breaks, you know exactly which image was deployed.
Every time you make a change:
Build and push a new container image
Run terraform apply with the new tag
You can also wire this into GitHub Actions for CI/CD.
What It Looks Like in AWS
Once deployed, the agent runs inside Bedrock AgentCore as a managed serverless runtime.
After provisioning, you can invoke the agent directly:
python scripts/invoke.py --prompt "What is sqrt(144) + 3 * 2?"
Example response:
{
"result": {
"role": "assistant",
"content": [
{
"text": "The answer is 18."
}
]
}
}This is what it looks like in AWS Bedrock AgentCore Console:
The example agent is intentionally simple. It uses Claude Sonnet 4.5 and has three basic tools. The goal is not complexity. It’s demonstrating a clean production deployment pattern. You can replace the tools, models, or logic with your own use case while keeping the infrastructure workflow intact.
Why This Matters
Agents are easy to prototype. They are much harder to operate.
If you treat agents like scripts, you’ll eventually hit scaling, observability, or deployment issues. If you treat them like infrastructure (versioned, containerised, reproducible) they become manageable systems.