DEV Community: Haowen Huang

Agent Toolkit for AWS in Practice (1) - Claude Code

Haowen Huang — Sun, 06 Sep 2026 08:24:59 +0000

Part 1 of the series "Agent Toolkit for AWS in Practice."

Agent Toolkit for AWS gives your coding agent two things it normally lacks: curated knowledge of how AWS services are meant to be used, and a way to actually call them. Setup is one command.

This walkthrough covers the install, two verification tasks against a real account, and three things worth knowing before you rely on it. Every command and output below is from an actual run on macOS with Claude Code.

What you're installing

Two independent pieces. Knowing which is which saves time when something misbehaves.

Piece	Role	Where it lives
Agent Skills	AWS knowledge — service selection, tested procedures, troubleshooting	Files on your disk
AWS MCP Server	Lets the agent call AWS APIs and search current docs	AWS-managed, reached through a local proxy

They work independently. Skills don't require the MCP server, and the MCP server doesn't serve your locally installed skills.

A skill is a directory with a SKILL.md and often a references/ folder:

aws-storage/
├── SKILL.md
├── .aws-skill-metadata      # {"version": "v1"}
└── references/
    ├── s3-general-purpose-knowledge.md
    ├── ebs-knowledge.md
    └── ...

The front matter's description is what the agent uses to decide whether a skill applies — and it spells out what the skill is not for, which keeps irrelevant skills from loading:

---
name: aws-storage
description: >-
  Selects, investigates, and compares AWS object, file, and block storage
  services... Not applicable for SQL query engines (Athena, Spark, Redshift,
  EMR), ETL (Glue), streaming (Kafka, MSK, Kinesis), or managed database
  services (RDS, Aurora, DynamoDB).
version: 1
---

The body holds behavioural rules. One from aws-storage explains why the toolkit is worth having: it requires the agent to verify current figures rather than recall them, to cite the pricing page for any cost claim, and to name a value it couldn't verify rather than guess. That pairs directly with the MCP server's documentation tools — the skill demands verification, the server provides the means.

Skills are open source in aws/agent-toolkit-for-aws (Apache-2.0), so you can read them before installing.

Prerequisites

aws --version    # need 2.35.0 or later
uv --version     # required — the MCP proxy runs through uvx
node --version   # v22+ for Claude Code

uv is easy to miss. Nothing in the setup output mentions it, but the MCP server won't connect without it. See the uv install guide.

If your AWS CLI is older than 2.35, upgrade by reinstalling the package — there's no self-update:

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /
rm AWSCLIV2.pkg

aws --version
# aws-cli/2.36.40 Python/3.14.6 Darwin/25.6.0 exe/arm64

Install

aws configure agent-toolkit --region us-east-1

Why the region flag? Agent Toolkit is served from us-east-1 only. Official examples omit it, which works if that's already your default. Mine is us-west-2, and without the flag the wizard completes agent detection and the selection screen, then fails at the fetch:
Fetching default AWS skills...
aws: [ERROR]: AgentToolkit is only available in us-east-1
Check aws configure get region first.

The wizard detects installed agents, offers a checklist (everything selected by default), installs skills, and configures the MCP server:

Detecting installed AI coding agents...
  ✓ Claude Code — ~/.claude/skills
  ✓ Codex — ~/.agents/skills/
  ✓ Cursor — ~/.cursor/skills
  ✓ Kiro — ~/.kiro/skills

Install 23 default AWS skills? [Y/n]: Y
Configure AWS MCP server connection? [Y/n]: Y

Restart your agent afterwards to pick up the config — if Claude Code is already open, exit with /exit and launch it again.

What you got

ls -1 ~/.claude/skills | wc -l
# 23

Those 23 are the catalog's aws-core category — covering IaC, core services, databases, networking, storage, security, observability, messaging, SDKs and cost management. They're installed as a full copy per agent, not symlinks.

The catalog holds more, at finer granularity, which you add yourself:

aws agent-toolkit search-skills --search-query "dynamodb" --region us-east-1

That surfaces single-service skills like amazon-dynamodb — access-pattern enumeration, partition key and GSI selection, single- versus multi-table decisions, cost estimation — well past what the domain-level aws-database covers.

Verify it works

Read path: query your bill

Launch Claude Code from the directory you want to work in:

claude

On first run in a project it asks you to enable the MCP server. Press Enter to accept — pressing Esc rejects it, and the server stays silently disabled with no further prompting.

Once you're at the prompt, check the connection by typing:

/mcp

aws-mcp · ✔ connected · 8 tools

That's success. Now ask for something real:

Get my AWS billing details for July 2026, grouped by service.
Do the sorting and totalling inside the script.

The agent reaches for aws___run_script and shows you the whole script before running it:

resp = await call_boto3(
    service_name="ce",
    operation_name="GetCostAndUsage",
    region_name="us-east-1",
    params={
        "TimePeriod": {"Start": "2026-07-01", "End": "2026-08-01"},
        "Granularity": "MONTHLY",
        "Metrics": ["UnblendedCost"],
        "GroupBy": [{"Type": "DIMENSION", "Key": "SERVICE"}],
    },
)

# Confirm the API actually ran
assert any(c.get("operation_name") == "GetCostAndUsage" for c in resp.get("api_calls", [])), resp

rv = resp["return_value"]
results = rv["ResultsByTime"][0]
groups = results["Groups"]

unit = None
rows = []
for g in groups:
    svc = g["Keys"][0]
    amt = g["Metrics"]["UnblendedCost"]
    unit = amt["Unit"]
    rows.append((svc, float(amt["Amount"])))

# Sort descending by cost, inside the script
rows.sort(key=lambda r: r[1], reverse=True)

total = sum(a for _, a in rows)

result = {
    "period": "2026-07-01 to 2026-07-31",
    "currency": unit,
    "estimated": results.get("Estimated"),
    "service_count": len(rows),
    "total": round(total, 2),
    "services": [
        {"service": s, "cost": round(a, 2), "pct": round(100 * a / total, 1) if total else 0.0}
        for s, a in rows
    ],
}
result

Reading it is worth the few seconds. One thing is visibly right: the sorting and totalling really do happen in the script, as the prompt asked — those are the rows.sort(...) and sum(...) lines, not something the model does in its reply afterwards.

Two things are wrong, and they share a cause. Both of these assume call_boto3 returns a wrapper around the API response:

assert any(c.get("operation_name") == "GetCostAndUsage" for c in resp.get("api_calls", [])), resp
rv = resp["return_value"]

Neither api_calls nor return_value exists on what call_boto3 hands back, so the assert can never pass and the script fails on the spot. The agent worked it out immediately:

The response is the raw API dict directly. Let me fix that.

Here's the corrected script it submitted next — the version that actually works:

resp = await call_boto3(
    service_name="ce",
    operation_name="GetCostAndUsage",
    region_name="us-east-1",
    params={
        "TimePeriod": {"Start": "2026-07-01", "End": "2026-08-01"},
        "Granularity": "MONTHLY",
        "Metrics": ["UnblendedCost"],
        "GroupBy": [{"Type": "DIMENSION", "Key": "SERVICE"}],
    },
)

results = resp["ResultsByTime"][0]
groups = results["Groups"]

unit = None
rows = []
for g in groups:
    svc = g["Keys"][0]
    amt = g["Metrics"]["UnblendedCost"]
    unit = amt["Unit"]
    rows.append((svc, float(amt["Amount"])))

# Sort descending by cost, inside the script
rows.sort(key=lambda r: r[1], reverse=True)

total = sum(a for _, a in rows)

result = {
    "period": "2026-07-01 to 2026-07-31",
    "currency": unit,
    "estimated": results.get("Estimated"),
    "service_count": len(rows),
    "total": round(total, 2),
    "services": [
        {"service": s, "cost": round(a, 2), "pct": round(100 * a / total, 1) if total else 0.0}
        for s, a in rows
    ],
}
result

Both wrong assumptions are gone: resp["ResultsByTime"] replaces resp["return_value"]["ResultsByTime"], and the assert on api_calls has been dropped entirely.

call_boto3 hands back the boto3 response directly. A return_value envelope does exist, but one level up — it wraps your script's final value in the MCP tool response, which is a different object. Inside the script, read the API response as-is.

This is a good template to reuse. Take the raw response, aggregate and sort in the script, return a compact dict.

Then it asks permission:

 Do you want to proceed?
 ❯ 1. Yes
   2. Yes, and don't ask again for aws-mcp — Aws Run Script commands in <this directory>
   3. No

Choose 1, and this is what a working setup produces:

Note what came back beyond the raw numbers: percentages per service, a count of how many services had zero spend, a note that the figures are finalized rather than estimated, and an unprompted takeaway pointing at the two services worth optimising. The skill's guidance is visible in the shape of that answer.

Two things to notice about how it got there.

1 / It's Python in a sandbox, not the AWS CLI. The tool executes code with AWS access through call_boto3 and no other network. call_boto3 takes a service name, a canonical API operation name and a parameter dict. Aggregation happens inside the script rather than by pulling raw data back into context, which keeps token use down.

2 / Ask for the maths to be done in the script. That's why the prompt above says "Do the sorting and totalling inside the script". Left to itself, the model may pull the raw numbers back and add them up in its reply — which in one of my runs produced a total $48 too high, with nothing to indicate anything was wrong. Doing it in Python avoids that.

To check the total the agent gives you, ask Cost Explorer for the same month without grouping. Skip --group-by and the API fills in Total for you, so you get one number to compare against:

aws ce get-cost-and-usage --time-period Start=2026-07-01,End=2026-08-01 \
  --granularity MONTHLY --metrics UnblendedCost --region us-east-1 \
  --query 'ResultsByTime[0].Total.UnblendedCost.Amount' --output text
# 2116.6859001279

Add --group-by and Total comes back empty — you get per-service groups and have to sum them yourself. That's why the agent does the adding, and why you want it doing that in Python.

Write path: create and delete a bucket

Create an S3 bucket named "example-toolkit-test" in us-east-1.

Then verify from a normal terminal rather than trusting the summary:

aws s3api head-bucket --bucket example-toolkit-test --region us-east-1
aws s3api get-bucket-encryption --bucket example-toolkit-test
aws s3api get-public-access-block --bucket example-toolkit-test

Encryption came back SSE-S3 (AES256) and all four public access blocks enabled — the secure defaults, nothing extra needed. Clean up:

Delete the S3 bucket "example-toolkit-test".

aws s3api head-bucket --bucket example-toolkit-test --region us-east-1
# An error occurred (404) ... Not Found

Read, write and delete all working end to end.

Three things worth knowing

1. The setup command doesn't update skills

Re-running aws configure agent-toolkit installs newly published skills and skips everything already on disk. Not "checks and confirms current" — untouched. Mine sat a month behind without any indication:

ls -l ~/.claude/skills/aws-cdk/SKILL.md
# Aug  6 06:06     ← still the version installed a month earlier

add-skill states the rule outright:

aws-cdk is already installed (v2) at /Users/you/.claude/skills/aws-cdk.
Run "aws agent-toolkit update-skill --skill-name aws-cdk" to update, or remove it first to reinstall.

Updating is a separate verb, and it does compare versions:

aws agent-toolkit update-skill --skill-name aws-cdk --region us-east-1
# Updated aws-cdk (v2) to Claude Code — ~/.claude/skills.
# ... and to the other three agent directories

One command covers every agent copy. To audit what's behind:

aws agent-toolkit list-available-skills --category-filter aws-core --region us-east-1

for s in ~/.claude/skills/*/; do
  printf "%-34s %s\n" "$(basename "$s")" "$(cat "$s/.aws-skill-metadata")"
done

Worth putting on a schedule. A stale skill doesn't error; it quietly supplies last month's guidance.

2. The MCP server runs remotely

Selecting the server in /mcp shows how it's wired:

The two lines that matter, in text so you can compare them against your own:

Command: uvx
Args:    mcp-proxy-for-aws@latest https://aws-mcp.us-east-1.api.aws/mcp --metadata INSTALL_SOURCE=aws-cli

There's no local server. It's an AWS-managed endpoint, and uvx mcp-proxy-for-aws is a thin local proxy that signs requests with your AWS credential chain. Hence the uv prerequisite and the region in the URL.

This view is also where you go when something isn't working — Reconnect and Disable are right there, and Status tells you whether the problem is the connection or something further along.

Note the @latest. The official examples pin a version and recommend doing so for reproducible behaviour; the CLI writes @latest. Both are defensible — @latest picks up fixes automatically, a pin keeps behaviour stable — so make the choice deliberately rather than inheriting it.

Pick View tools from that menu and Claude Code lists all eight with their annotations:

Six of the eight are read-only lookups, three of those being documentation search and retrieval. Exactly one — aws___run_script, the only one marked destructive — can change your account. Every write goes through it.

Worth scrolling this list once. It's the clearest picture you'll get of what the agent can actually do, and the destructive label tells you which single tool to pay attention to when an approval dialog appears.

3. Approval is coarser than it looks

That's the dialog for a two-line script that returns the string OK. The one for deleting an S3 bucket looks the same — same three options, no extra warning for destructive work. I compared it across five operations.

Which makes option 2 more consequential than it reads. "Don't ask again for aws-mcp — Aws Run Script commands in this directory" sounds narrow, but because reads, writes and deletes all travel through that single tool, it covers every subsequent AWS operation there, deletions included. The grant can't be scoped per operation.

Two practical follow-ups.

1 / Check autoApprove in the configs the wizard touched. On this machine it added "autoApprove": ["aws___run_script"] to ~/.kiro/settings/mcp.json — the one tool that can change your account, pre-approved. Claude Code and Cursor got no such field, and the official example config doesn't include it. Remove it if you'd rather be asked.

2 / Read the code in the dialog, not the comments in it. One delete script arrived with a # Verify empty first comment, computed an object count, never branched on it, and deleted anyway — then reported that it had "verified the bucket was empty". The check the comment promised wasn't there.

Where the real guardrails are

The client is the wrong place to look for granularity. The toolkit's mechanism for this sits on the AWS side: the condition keys aws:ViaAWSMCPService and aws:CalledViaAWSMCP distinguish requests made through the AWS-managed MCP server from direct API calls.

You can use them in IAM policies and SCPs to write rules that apply only to agent-initiated actions — for example, permitting only read-only operations through MCP even where the underlying role can write. Every request also lands in CloudWatch metrics and CloudTrail.

That's the control point worth investing in. Clicking through identical dialogs doesn't scale, and the tool annotation gates nothing on its own.

Command reference

# install / reconfigure
aws configure agent-toolkit --region us-east-1

# skills — add --region unless your default is us-east-1
aws agent-toolkit list-installed-skills
aws agent-toolkit list-available-skills --category-filter aws-core --region us-east-1
aws agent-toolkit search-skills --search-query "dynamodb" --region us-east-1
aws agent-toolkit update-skill --skill-name aws-cdk --region us-east-1
aws agent-toolkit update-skill --skill-name aws-cdk --agent kiro --region us-east-1
aws agent-toolkit add-skill --skill-name amazon-dynamodb --region us-east-1
aws agent-toolkit remove-skill --skill-name aws-cdk --region us-east-1
aws agent-toolkit get-skill-metadata --skill-name aws-serverless --region us-east-1

# local versions at a glance
for s in ~/.claude/skills/*/; do
  printf "%-34s %s\n" "$(basename "$s")" "$(cat "$s/.aws-skill-metadata")"
done

list-installed-skills is the one subcommand that works without --region — it only reads local disk.

Verified on

Component	Version
macOS	Darwin 25.6.0 (arm64)
AWS CLI	2.36.40
Node.js	v22.23.2
uv	0.8.18
Claude Code	2.1.261 (via Amazon Bedrock)
AWS skills	23 (`aws-core`)

Part 2 runs the same walkthrough on Codex — where the config format is TOML rather than JSON, the skills land in a directory shared with three other agents, and the approval model works differently. It also covers what the aws-core plugin installs that the CLI path doesn't.

Whatever your setup looks like, verify it the way this post did: one read, one write, both confirmed from a second terminal. An agent's account of what it did is not evidence that it did it.

References

Agent Toolkit for AWS

Product page — overview, features, per-agent getting started
User guide — setup and reference documentation
AWS CLI integration guide — the configure agent-toolkit wizard and every agent-toolkit subcommand, including update-skill
AWS MCP Server tools reference — the eight tools, authentication, supported regions
Getting started with the AWS MCP Server — configuring the server with agents other than Claude Code, Codex and Cursor

Source and skill contents (Apache-2.0)

aws/agent-toolkit-for-aws — repository
skills/ — every skill's SKILL.md and reference files, readable before you install
rules/ — the recommended project-level rules file, not covered in this post

Prerequisites and related

uv installation — required; the MCP proxy runs through uvx
Installing or updating the AWS CLI — 2.35.0 or later needed
Model Context Protocol — the open standard behind the MCP server, including tool annotations
Claude Code MCP documentation — the /mcp command and server management

Referenced APIs

GetCostAndUsage — Cost Explorer; note the canonical PascalCase operation name expected by call_boto3

A note on method: official documentation and skill contents are paraphrased rather than quoted. Every command and output in this post is from a real run on the environment listed above, and the agent's actions were verified from a separate shell rather than taken from its own reporting.

Get Started with GPT-5.6 on Amazon Bedrock in 15 Minutes

Haowen Huang — Sat, 01 Aug 2026 06:13:15 +0000

OpenAI's GPT-5.6 comes in three tiers — Sol, Terra and Luna — and you can now call them on Amazon Bedrock through your own AWS account, with no OpenAI API key.

This takes the shortest path: clone, run, understand the output. Every command is copy-pasteable, every number below came from a real run, and you should see the same order of magnitude on your own account.

Background: two things worth knowing first

GPT-5.6 became generally available on Amazon Bedrock in July 2026. Two things are worth understanding before you start.

First, Sol / Terra / Luna are not version numbers. The 5.6 identifies the generation; Sol, Terra and Luna are three capability tiers that can each advance on their own cadence. So the question when choosing is "how much reasoning does this task need", not "which one is newer". Per OpenAI's published evaluations, Sol is their strongest reasoning model to date, clearly ahead of the previous generation on coding-agent and security-research work while spending fewer output tokens; Terra beats the previous generation at lower cost; Luna targets high volume and low latency. Sol also gets one extra reasoning level, max.

Second, why run this on Bedrock instead of calling OpenAI directly. All three
points below come from the AWS GA announcement (linked in the appendix):

Inference stays in the AWS Region you specify, which helps with data residency
Every call goes through your own IAM policies, inside your VPC, and lands in CloudTrail
Pricing matches OpenAI's first-party rates, and usage counts toward your existing AWS commitments

Now let's build.

What you need

Python 3.10 or newer
An AWS account with working credentials (~/.aws/credentials or AWS_PROFILE)
GPT-5.6 available in your target Region, and an IAM identity permitted to call Bedrock

Confirm your credentials resolve. If you have the AWS CLI:

aws sts get-caller-identity

If it prints your account and identity, you're good. The AWS CLI is not
required — the examples never call it, and credentials are read through the
Python SDK. Without it, run this equivalent check after step 1 installs the
dependencies:

python -c "import botocore.session as s; print('credentials found' if s.get_session().get_credentials() else 'NO credentials')"

Step 1: Set up

git clone https://github.com/hanyun2019/openai-bedrock-samples.git
cd openai-bedrock-samples

python -m venv .venv
source .venv/bin/activate          # Windows: .venv\Scripts\activate
pip install -r requirements.txt

You don't set an API key. That's the biggest difference from calling OpenAI
directly: the code uses your AWS credentials to mint a short-lived Bedrock token
before every request.

openai>=2.45.0 is a hard requirement, because that's where the BedrockOpenAI
client lives.

Step 2: First call

python -m src.gpt56.hello

============================================================
Tier      : terra
Model ID  : openai.gpt-5.6-terra
Region    : us-east-1
Usage     : in=20 out=36 total=56
            reasoning=0
============================================================
I'm best suited for understanding and generating text, answering
questions, summarizing and analyzing information, ...
============================================================

Working. Only one thing here is worth memorizing: run with -m, not a file
path.

python -m src.gpt56.hello              # correct
python src/gpt56/hello.py              # ImportError

The example modules use relative imports, and running a file directly leaves Python
with no idea which package it belongs to.

The whole project has exactly one essential file, src/gpt56/client.py. It does two
things: validate the tier/Region combination, and build a client whose token renews
itself. Everything else imports it.

Step 3: Which tier?

The short version:

Tier	Model ID	When to use it
Sol	`openai.gpt-5.6-sol`	Complex refactoring, long reasoning chains, security research
Terra	`openai.gpt-5.6-terra`	Everyday production. Start here
Luna	`openai.gpt-5.6-luna`	Classification, summarization, routing — high volume, low latency

Here's the problem it uses:

It deliberately splits the information in two: the vertex form hides "the maximum is
at x=3", and g(3) has to be looked up in the table. The model has to combine both
rather than pattern match its way to an answer. The answer is B.

Same problem, all three tiers:

python -m src.gpt56.compare_tiers

built-in text problem · effort=low · region=us-east-1
Correct answer: B (k=3, g(3)=6)
==============================================================================
tier         sec     in    out  reasoning  answer
sol          2.4    133     79          0       B
terra        1.5    133     67          0       B
luna         1.5    133     95         25       B

All three got it right, and that's the point: on an easy task, the expensive tier
does not buy you a better answer. On this run Terra was also faster than Sol and
spent fewer output tokens. Tier differences only show up on hard problems.

The exact numbers drift run to run (a rerun gave me 87 output tokens for sol and 85
for terra, with the timings reordered), so don't anchor on any single figure. The
conclusion is what matters: all three got it right, so paying more bought nothing
here.

So work upward: start on Terra, move to Sol when Terra isn't enough — not the other
way around.

One gotcha that will actually raise an error: Sol exists only in us-east-1 and
us-east-2, while Terra and Luna add us-west-2. client.py catches this before
any request goes out:

ValueError: GPT-5.6 sol is not available in us-west-2.
Available Regions: us-east-1, us-east-2

Step 4: Reasoning effort

GPT-5.6 reasons before it answers, and reasoning.effort controls how hard. Six
levels: none, low, medium, high, xhigh, max.

This step switches to an algebra problem:

It needs exactly one exponent-rule transformation (dividing powers subtracts the
exponents, so 3x - y substitutes straight in). That looks trivial, but the single
transformation is the reasoning step — which makes it a good probe for whether
effort is doing anything. D is the trap: x and y really are individually
undetermined, but the expression only depends on the combination 3x - y, so there is
a unique answer. The correct answer is A.

Sweep them:

python -m src.gpt56.effort_sweep terra

Model: openai.gpt-5.6-terra @ us-east-1
Correct answer: A   1 run(s) per level

effort       sec     in    out  reasoning    answer
none         3.1     83     79          0      A OK
low          1.2     83     73          0      A OK
medium       2.9     83    115         30      A OK
high         1.1     83    116         32      A OK
xhigh        1.7     83    121         43      A OK
max          1.7     83    126         46      A OK

Two columns tell the story.

The reasoning column climbs from 0 to 46. That is what effort buys: an amount
of thinking.

The in column is flat at 83. The prompt didn't change, so input doesn't
either — effort only affects the output side. Which means raising effort only
raises output cost.

Meanwhile sec is all over the place (3.1 → 1.2 → 2.9 → 1.1). Don't read "higher
effort is slower" out of a single run. Network jitter alone swamps the difference,
and per the AWS docs the bedrock-mantle endpoint may briefly queue a request
while in-flight work completes and throughput frees up. That's by design — it trades
queueing for higher initial throughput limits — not a fault, but it makes a single
timing measurement even less meaningful.

⚠️ The reasoning column also comes out unordered in a single run. Another run
gave me 0, 0, 33, 28, 31, 40 — high spent less than medium. The upward trend
is real, but one sample doesn't clear the noise. Average a few runs per level to see
it:

python -m src.gpt56.effort_sweep terra 3

effort       sec     in    out  reasoning  accuracy  answers
none         1.5     83     80          0       3/3  A, A, A
low          1.3     83     77          0       3/3  A, A, A
medium       1.4     83    103         22       3/3  A, A, A
high         1.4     83    111         31       3/3  A, A, A
xhigh        1.5     83    117         33       3/3  A, A, A
max          1.6     83    121         49       3/3  A, A, A

Averaged, it's monotonic: 0, 0, 22, 31, 33, 49. This problem isn't hard — 18 out
of 18 correct — so what you're seeing is the cost gradient, not an accuracy
difference.

One thing you do need to know: reasoning tokens are billed as output tokens, and
they draw down your max_output_tokens budget. Set that budget too low and
reasoning can consume all of it, leaving you a status="incomplete" response with
empty text. The examples default to 32000 to stay clear of this.

Practical advice: start at low. none gets a reasoning budget of zero, which
is fine for extraction and formatting, but anything needing even one inference step
belongs at low or above.

Step 5: Saving money with prompt caching

If you ask repeated questions against the same long document — the shape of RAG and
document Q&A — caching pays off.

python -m src.gpt56.prompt_cache

The script uses the opening of Moby-Dick (1851, public domain) as a reference
document and asks two different questions against the same prefix:

Q1: In two sentences, what is the narrator's stated reason for going to sea?
Q2: In two sentences, describe the mood of the opening chapter.

One asks for a fact, the other for atmosphere, but both are scoped to that document.
This is exactly the shape where caching pays off most: the document stays fixed,
the questions change.

Reference doc: first 12000 chars of Moby-Dick (public domain)

[call 1 (cache write)] input=3002 cached=0    written=2980 hit_rate=0.0%
[call 2 (cache read) ] input=2998 cached=2980 written=0    hit_rate=99.4%

The second call hit cache on 99.4% of its input. Cached input bills at 10% of
the uncached rate (writes bill at 1.25x) and doesn't count against your input TPM
quota — that's where the savings come from, so write-once, read-many wins.

(The first run downloads the full text from Project Gutenberg; a few IncompleteRead
retries are normal.)

The trap that catches everyone: the cached prefix must be at least 1,024
tokens. Below that nothing is cached and no error is raised — cached just
stays 0 forever. You'll assume your code is wrong when the prefix is simply too
short.

One more thing that looks wrong but isn't: run that same
python -m src.gpt56.prompt_cache again right away, and this time call 1 reports a
hit too:

[call 1 (cache write)] input=3002 cached=2980 written=0 hit_rate=99.3%

Labelled cache write, yet 99.3% cached. That's correct — the cache written by the
previous run is still inside its retention window (at least 30 minutes), so this
run's first call reads it. The label describes which call it is in the script, not a
guarantee that this particular call writes the cache.

Step 6 (optional): Function calling and MCP

The first five steps are all ask-once, answer-once. This step lets the model call
external tools, which is where agents start. Skip it if you're not building one.

The repo has two versions. The protocol is identical; only the source of the tools
differs.

Version one: a stub function, to see the protocol clearly

python -m src.gpt56.tool_calling

Model: openai.gpt-5.6-terra @ us-east-1

-> model requested get_weather({'location': 'Seattle, US', 'unit': 'fahrenheit'}) -> returned {'location': 'Seattle, US', 'temperature': 18, 'condition': 'Partly cloudy'}

Final answer:
Seattle is currently **18°F** and **partly cloudy**.

One full round trip is three steps: send your tool definitions in tools= → the model
replies with a function_call naming the tool and its arguments → you execute it
locally and send the result back as a function_call_output, paired to that call via
call_id. Your code always executes the tool; the model only decides whether to
call it and with what arguments.

Version two: a real MCP server, returning real data

MCP (Model Context Protocol) is an open protocol that connects AI models to external tools and data sources. This example uses AWS documentation MCP server:

Read-only access to public docs - no AWS permissions needed
Requires uv/uvx (install first)
First run downloads the server automatically

python -m src.gpt56.mcp_tools

Starting MCP server: awslabs.aws-documentation-mcp-server ...
MCP offers 5 tools; bridging 2 to the model: ['read_documentation', 'search_documentation']

Model: openai.gpt-5.6-terra @ us-east-1
Question: Using the AWS documentation tools, find the model ID and the AWS Regions for GPT-5.6 Sol on Amazon Bedrock. ...

[turn 1] model called MCP tool search_documentation
[turn 2] model called MCP tool read_documentation

Final answer (turn 3):
The Amazon Bedrock model ID for GPT-5.6 Sol is `openai.gpt-5.6-sol`.
It is available for in-Region inference in `us-east-1` (N. Virginia) and `us-east-2` (Ohio).
Source: [AWS documentation—GPT-5.6 Sol](https://docs.aws.amazon.com/bedrock/latest/userguide/model-card-openai-gpt-56-sol.html).

The model planned two steps on its own: search first, then read the specific page,
and only answered on turn 3 — with a citation to the official URL, genuinely read out
of the docs rather than invented.

In code, the only difference from version one is where the tools come from: instead of
hand-written definitions, they're translated from the MCP server's list_tools() into
the Responses API function format, and execution forwards to session.call_tool()
instead of a local function. The protocol part is unchanged.

Two things worth knowing:

Don't hand the model every tool an MCP server offers. This one exposes 5; the example allows 2. Tool definitions cost input tokens and raise the chance the model picks the wrong one
Set a turn limit. My first attempt asked something too broad ("which reasoning levels are supported") and the model kept searching without converging. Asking a specific question and telling it to stop once it had the two facts got it done on turn 3

Error cheat sheet

Errors you might hit at any of the steps above, listed by the message you see.

What you see	Why
`ImportError: attempted relative import...`	You ran a file path; use `python -m`
`ValueError: GPT-5.6 sol is not available in...`	Sol has no `us-west-2`
`status="incomplete"` with empty text	Reasoning ate `max_output_tokens`; raise it or lower effort
`cached` stuck at 0	Cached prefix is under 1,024 tokens
HTTP 429	Throttled. The client already sets `max_retries=6`; or spread the work out
`AccessDeniedException`	Missing permissions. Check that IAM allows calling Bedrock and that no SCP explicitly denies it
`401 Unauthorized: Signature expired`	The short-lived Bedrock token expired (12 hours max). The examples renew it automatically; you'll normally only see this with Codex
`command not found: aws`	No AWS CLI. It's optional — use the `botocore` check above instead

Wrapping up

At this point you've run GPT-5.6 end to end on your own AWS account: environment set
up, first call out, all three tiers compared side by side, all six effort levels
swept, caching cutting repeated input to a tenth of the price, and the model calling a
real external tool. None of it is a mock-up — it's code you can lift into a project.

Two directions from here. Point the Codex CLI at Bedrock so your coding agent's
reasoning also runs through your own account — that works quite differently from the
calls above, and the repo README covers it end to end. Or take the two examples from
Step 6 as a skeleton and swap in your own tools to build an agent.

Full code | github.com/hanyun2019/openai-bedrock-samples

Happy agentic AI coding!

Appendix: References

AWS documentation

GPT-5.6 Sol, Terra, and Luna are now generally available on Amazon Bedrock — the GA announcement and the source for the background section above: tier positioning, benchmark results, the inference engine, and the security model
GPT-5.6 Sol model card — authoritative source for model IDs and Regions
Endpoints supported by Amazon Bedrock — explains the split between the bedrock-mantle and bedrock-runtime endpoints, and the different throughput and quota model each uses. This post uses the former throughout (the OpenAI-compatible Responses API), which AWS also recommends for new applications; the latter serves the native InvokeModel / Converse APIs. Worth noting: because we're on mantle, none of this needs boto3 for inference
Amazon Bedrock pricing — current rates. GPT-5.6 Terra and Luna pricing changed in late July 2026, so treat this page as the source of truth
Bedrock API keys permissions — calling the Responses API needs the bedrock-mantle:CallWithBearerToken action. Note it is not bedrock:CallWithBearerToken; the names are close enough that getting it wrong yields a confusing denial
Request access to models — how model access permissions work. One easy point of confusion: the Marketplace subscription flow described there applies to third-party models that have a product ID, and OpenAI models are not sold through AWS Marketplace and have no product ID, so that flow and the aws-marketplace:* permissions don't apply to GPT-5.6

OpenAI documentation

Getting Started with OpenAI Models on Amazon Bedrock — the official OpenAI Cookbook guide. Covers the advanced surface this post skips: structured outputs, JSON mode, server-side state, encrypted reasoning context, background work, direct PDF input, custom tools, and compaction. ⚠️ It defaults to us-west-2, where Sol is unavailable, so don't copy its model and Region configuration
Reasoning models — the official reference for reasoning.effort

Tools and dependencies

Installing uv / uvx — required by mcp_tools.py
awslabs/mcp — AWS's collection of MCP servers; the AWS Documentation MCP Server used here comes from it
Codex on Amazon Bedrock — pointing Codex at Bedrock

Material used in the examples

Moby-Dick, Project Gutenberg #2701 — the reference document in prompt_cache.py; published 1851, public domain

Code

openai-bedrock-samples — every example in this post

Building a Multi-Agent Quant Backtesting System: Amazon Bedrock AgentCore + Strands Agents

Haowen Huang — Sat, 18 Jul 2026 23:24:20 +0000

A hands-on walkthrough of building a multi-agent quantitative backtesting system on Amazon Bedrock AgentCore and the Strands Agents SDK. Three specialized AI agents collaborate to turn a plain-English trading strategy into a full performance report. This post is the introduction to an eight-lab, 90-minute workshop and the first in a multi-part series. It covers the architecture, the three foundation models, and the lab progression—and kicks off follow-up posts on collaboration (A2A), safe execution (sandboxing), governed actions (guardrails), and compounding memory.

The Problem

The success or failure of quantitative trading depends, to a large degree, on backtesting. Before any real money goes into the market, a strategy has to prove itself on historical data: Does it make money? What's the worst-case loss? Is this much return worth that much risk?

The hard part is that going from a trading idea to a credible backtest report spans several domains at once: trading domain knowledge, data engineering, Python coding, and statistical analysis. That is precisely the kind of multi-step, multi-skill problem where AI agents shine. The hands-on workshop explored in this post builds exactly such a system: multiple specialized agents collaborating to go from a one-sentence strategy description to a full performance analysis—automatically.

This post gives you a quick tour of what the workshop covers and why its design decisions are worth adopting in your own projects.

Disclaimer: This content is for learning and discussion purposes only. It does not constitute investment advice, recommendations, or solicitation. Any investment decisions and resulting gains or losses are solely the responsibility of the individual.

About This Series

This post is the opener of a multi-part series. It gives you the big picture; the follow-up posts each zoom into one design decision that turns this system from a demo into something production-ready:

Part 1 (this post) — The big picture: the architecture, the models, and the eight-lab progression.
Part 2 — Collaboration (A2A protocol): how agents discover and invoke each other across accounts, clouds, and frameworks using an open standard rather than a proprietary API.
Part 3 — Safe execution (Code Interpreter sandbox): why you should not run LLM-generated code directly, and how a sandbox contains it.
Part 4 — Governed actions (Cedar guardrails): how to impose a deterministic guardrail on a probabilistic agent—a boundary it can never cross, no matter what it decides.
Part 5 — Compounding memory: how giving the agent memory turns one-off backtests into a research companion that accumulates context and converses.

The through-line: big picture → collaboration → safety → accumulation. If any of those resonate, follow along.

What You'll Build

This is a hands-on workshop—roughly 90 minutes—at an intermediate (300) level. By the end you will have:

Three specialized AI agents deployed to Amazon Bedrock AgentCore
The ability to connect agents to external market data through an AgentCore MCP Gateway
A full-stack backtesting application that runs all the way from strategy input to performance analysis
An understanding of multi-agent orchestration patterns for complex financial workflows.

The bar is not high: basic Python and command-line familiarity, plus a general grasp of trading concepts such as buy, sell, and technical indicators. No prior experience with AI agents or backtesting frameworks is required. The workshop environment ships with a browser-based code editor (Code-OSS/VS Code Open Source), so there is nothing to install locally.

Three Foundation Models

A core idea of the workshop is matching the right model to the task. Rather than having one large model do everything, each agent uses the model best suited to its job:

Model	Role	Responsibility
Amazon Nova Lite 2.0	Result summarizer	Analyze performance metrics and write a professional report
Anthropic Claude Sonnet 4	Quant agent (orchestrator)	Coordinate the entire workflow and all sub-agents
Anthropic Claude Opus 4	Strategy generator	Turn natural-language strategy into executable Backtrader Python code

Using a powerful model for code generation and a lighter, faster model for summarization is, in itself, a practical lesson in cost-and-latency optimization.

Why Backtesting, and Why Agents

Backtesting answers the questions that matter most before real capital is deployed: total and annualized return, maximum drawdown, Sharpe and Sortino ratios, win rate, profit/loss ratio, and how a strategy behaves in bull, bear, and sideways markets.

The traditional flow has five steps: define the strategy, gather historical data (OHLCV), implement it in code, run the simulation, and analyze the results. The problem is that each step demands a different skill.

The workshop uses Backtrader, a popular open-source Python backtesting framework with an event-driven engine, built-in technical indicators (SMA, EMA, RSI, MACD), order management, and performance analytics. In this system, the strategy generator writes the Backtrader code and the quant agent runs it against real market data—leaving the human free to focus on the strategy itself.

Why Multiple Agents Instead of One Big Agent

A single "do-everything" agent tends to struggle with complex, multi-step tasks. The workshop argues for a multi-agent architecture along four axes:

Specialization — each agent has a single responsibility, improving accuracy
Scalability — distributed processing scales elastically and independently
Cost efficiency — provision resources per agent, on demand
Maintainability — fine-grained control, independent health monitoring, isolated testing

Strands Agents supports four collaboration patterns:

Agent-as-Tool (the orchestrator invokes specialized agents as callable tools)
Swarm (agents collaborate through shared memory)
Graph (agents as nodes connected by explicit edges)
Workflow (structured, sequential collaboration)

Use Cases:

Loan approval processes — Sequential steps: identity verification → credit check → risk assessment → approval decision
CI/CD pipelines — Build → test → security scan → deploy, with defined dependencies between stages
Insurance claims — Document collection → damage assessment → policy validation → settlement calculation

The diagram below illustrates sample use cases for each pattern.

This workshop uses the Agent-as-Tool pattern, because a backtesting flow is naturally hierarchical:

User Request
↓
Quant Agent (Orchestrator)
├── invoke → Strategy Generator Agent → Backtrader code
├── invoke → Market Data MCP Tool → Historical OHLCV data
├── execute → Backtest (Backtrader engine)
└── invoke → Result Summarizer Agent → Performance analysis
↓
Consolidated Response → User

Because each specialized agent runs independently, it can use a different model and its own configuration, and it can be tested, scaled, and updated in isolation.

What AgentCore Brings

Amazon Bedrock AgentCore provides managed infrastructure for deploying, running, and scaling agents in production. The workshop uses five of its services:

Runtime — a serverless compute environment that hosts each agent. No servers or containers to manage; it auto-scales with invocation load, supports secure environment variables, and enables agent-to-agent invocation. All three agents are deployed here.
Gateway — wraps a market-data Lambda function into a get_market_data MCP tool that any agent can invoke, with semantic routing and Cognito-based OAuth.
Identity — secure authentication integrated with an existing identity provider (in this case, Amazon Cognito), ensuring that only authorized agents can access the market-data tool.
Memory — short-term and long-term context storage, enabling the quant agent to handle follow-ups and iterative strategy refinement.
Observability — OpenTelemetry-compatible tracing of the full execution path—from orchestrator to sub-agents to Gateway tool calls—flowing into Amazon CloudWatch.

Deployment is straightforward: point the AgentCore CLI at your Python entry file, and it handles packaging, dependencies, container management, and scaling:

agentcore configure --entrypoint quant_agent.py --name quant_agent \
  --requirements-file requirements.txt --idle-timeout 900

agentcore launch --auto-update-on-conflict \
  --env AWS_REGION=$WORKSHOP_REGION \
  --env STRATEGY_GENERATOR_RUNTIME_ARN=arn:... \
  --env AGENTCORE_GATEWAY_URL=https://...

System Architecture

Overall system architecture. Source: the "Agentic Backtesting for Quants" workshop (AWS).

The system has three layers:

Frontend (Next.js) — a strategy-input form, real-time workflow progress indicators, and a results dashboard with metrics and AI-generated analysis.
Orchestration layer (Bedrock AgentCore) — the quant agent receives the request, invokes the strategy generator for code, fetches data through the market-data Gateway, runs the Backtrader simulation locally, and then invokes the result summarizer.
Data layer — S3 Tables (in Apache Iceberg format) store historical daily OHLCV data sourced from Yahoo Finance (for educational use only); a Lambda function queries the data via PyIceberg; and the Gateway exposes that Lambda function as the get_market_data tool.

The Hands-On Labs

The labs build progressively, each adding one new AgentCore capability on top of the last. You start with a prompt-only agent and evolve it, step by step, into a full multi-agent system with observability and guardrails:

Lab 1 — Deploy the strategy generator (AgentCore Runtime): get a simple, prompt-only agent up and running.
Lab 2 — Build the quant agent with market data (AgentCore Gateway & Identity): connect the agent to external tools.
Lab 3 — Multi-agent orchestration (Agent-as-Tool): transition from a single agent to an "orchestrator + experts" structure.
Lab 4 — Run your first backtest (AgentCore Observability): make the black box transparent with traces and spans.
Lab 5 — Backtest memory and chat (AgentCore Memory): transition from stateless to stateful, enabling the agent to remember context.
Lab 6 (bonus) — Add guardrails (AgentCore Policy): transition from unconstrained to governed execution.
Lab 7 (bonus) — Sandboxed execution (AgentCore Code Interpreter): run code in a secure sandbox rather than locally.
Lab 8 (bonus) — A2A protocol (Agent-to-Agent): replace a proprietary API with an open, interoperable standard.

This evolution path is itself the payoff: each lab corresponds to a real capability gap you will encounter when pushing an agent from "toy" toward "production."

What You've Built

Component	Technology	Purpose
Strategy Generator	Claude Opus 4 + AgentCore	Converts natural language to Backtrader code
Quant Agent	Claude Sonnet 4 + AgentCore	Orchestrates the four-step workflow
Results Summarizer	Nova Lite 2.0 + AgentCore	Analyzes performance metrics
Market Data MCP	Lambda + S3 Tables + AgentCore Gateway	Serves historical OHLCV data
Frontend	Next.js + TypeScript	User interface for strategy input and results

Who It's For

This workshop is aimed at quant developers, data scientists, engineers, and engineering managers who are curious about how agentic AI can accelerate quantitative trading workflows. If you have been looking for a concrete demonstration of how multi-agent orchestration, MCP, and managed agent infrastructure fit together in an end-to-end project, this is a well-scoped place to start. It is free at AWS events; running it in your own account requires you to cover the cloud resource costs.

Finally, to repeat a reminder from the workshop itself: the market data here comes from Yahoo Finance, for educational use only, and is not investment advice. What is truly worth taking away is the overall architecture of this quant backtesting system and the multi-agent design patterns you can internalize and apply to your own systems.

References

Agentic Backtesting for Quants with Bedrock AgentCore and Strands Agents: https://catalog.us-east-1.prod.workshops.aws/workshops/dcf31eb4-6479-48ed-acc5-e58fe1f53656/en-US?trk=7b33727f-f84b-453c-8f31-3d32f7b2a4e7&sc_channel=el
Backtrader open-source backtesting framework: https://www.backtrader.com/
Amazon Bedrock AgentCore docs: https://docs.aws.amazon.com/bedrock-agentcore/?trk=7b33727f-f84b-453c-8f31-3d32f7b2a4e7&sc_channel=el
Strands Agents docs: https://strandsagents.com/?trk=7b33727f-f84b-453c-8f31-3d32f7b2a4e7&sc_channel=el

Running Claude Code and Claude Desktop on Amazon Bedrock

Haowen Huang — Mon, 04 May 2026 06:35:23 +0000

Abstract: This article walks through configuring both Claude Code (terminal CLI) and Claude Desktop (Cowork) to use Amazon Bedrock as the inference backend — no Anthropic API key or subscription required. Claude Code needs two environment variables in ~/.claude/settings.json. Claude Desktop needs a few fields in the built-in Setup UI. Both share the same AWS credentials and Bedrock model access. The entire setup, including troubleshooting, was done through AI-assisted development with Kiro.

In a previous post, we covered how to run the Claude Agent SDK (Python) on Amazon Bedrock with just two environment variables. This post continues the series, covering the other two main ways developers interact with Claude daily: the terminal CLI and the desktop app.

If you're already in the AWS ecosystem, routing Claude through Amazon Bedrock keeps your data in your own account, bills through your existing AWS agreement, and eliminates the need for a separate Anthropic subscription. This post covers two scenarios:

Scenario A: Claude Code CLI — the terminal-based coding tool
Scenario B: Claude Desktop (Cowork 3P) — the GUI desktop app

Both use the same AWS IAM user and Bedrock model access.

Prerequisites (Shared)

Before either scenario, make sure you have:

AWS CLI installed and credentials configured

aws --version
aws sts get-caller-identity

Bedrock model access enabled — Serverless foundation models on Amazon Bedrock are now automatically enabled when first invoked. However, for Anthropic models, first-time users may need to submit use case details before access is granted. Simply select a model from the Model catalog and try invoking it — you'll be prompted if any additional steps are needed.
IAM permissions — Your IAM user or role needs:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "bedrock:InvokeModel",
        "bedrock:InvokeModelWithResponseStream",
        "bedrock:ListInferenceProfiles",
        "bedrock:GetInferenceProfile"
      ],
      "Resource": [
        "arn:aws:bedrock:*:*:inference-profile/*",
        "arn:aws:bedrock:*:*:application-inference-profile/*",
        "arn:aws:bedrock:*:*:foundation-model/*"
      ]
    }
  ]
}

Know your inference profile IDs — Bedrock requires cross-region inference profile IDs (with a region prefix like us.), not bare model IDs. The ones used in this post:

Model	Inference Profile ID
Claude Opus 4.7	`us.anthropic.claude-opus-4-7`
Claude Opus 4.6	`us.anthropic.claude-opus-4-6-v1`

Scenario A: Claude Code CLI

Claude Code is Anthropic's terminal-based AI coding tool. Install it via npm:

npm install -g @anthropic-ai/claude-code

Step 1: Edit settings.json

The cleanest approach is writing the Bedrock configuration into Claude Code's settings file, so you don't need to export environment variables every time.

Edit ~/.claude/settings.json:

{
  "model": "us.anthropic.claude-opus-4-6-v1",
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "us-east-1"
  }
}

Two key fields:

CLAUDE_CODE_USE_BEDROCK: Tells Claude Code to use Bedrock instead of the Anthropic API.
AWS_REGION: Required. Claude Code does not read this from ~/.aws/config.

The model field uses the Bedrock inference profile ID. Without it, Claude Code picks its own default.

Step 2: Run and Verify

claude

Inside Claude Code, run /status. You should see:

API provider: Amazon Bedrock
AWS region: us-east-1
Model: us.anthropic.claude-opus-4-6-v1

That's it. Claude Code picks up your AWS credentials through the standard SDK credential chain (~/.aws/credentials, environment variables, IAM role, SSO profile).

Switching Models

There are two ways to switch models:

At runtime — Inside Claude Code, use the /model command:

/model us.anthropic.claude-opus-4-7

This switches immediately without restarting. Use /model us.anthropic.claude-opus-4-6-v1 to switch back.

Permanently — Change the model field in ~/.claude/settings.json:

{
  "model": "us.anthropic.claude-opus-4-7",
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "us-east-1"
  }
}

Restart Claude Code (/exit, then claude) for the change to take effect.

Optional: Install Skills

Claude Code supports Skills — packaged instructions that extend Claude's capabilities. Anthropic publishes an official set at github.com/anthropics/skills.

To install them, run inside Claude Code:

/plugin marketplace add anthropics/skills
/plugin install document-skills@anthropic-agent-skills
/plugin install example-skills@anthropic-agent-skills
/reload-plugins

This gives you skills like mcp-builder, webapp-testing, claude-api, document generation (docx/pdf/pptx/xlsx), and more.

After installation, your ~/.claude/settings.json will be updated automatically with the new plugin entries:

{
  "model": "us.anthropic.claude-opus-4-6-v1",
  "env": {
    "CLAUDE_CODE_USE_BEDROCK": "1",
    "AWS_REGION": "us-east-1"
  },
  "enabledPlugins": {
    "document-skills@anthropic-agent-skills": true,
    "example-skills@anthropic-agent-skills": true
  },
  "extraKnownMarketplaces": {
    "anthropic-agent-skills": {
      "source": {
        "source": "github",
        "repo": "anthropics/skills"
      }
    }
  }
}

Compared to the base configuration in Step 1, two new sections are added:

enabledPlugins: Tracks which Skills are active.
extraKnownMarketplaces: Records the GitHub source for the Skills marketplace.

Example: Turning a Blog Post into a Slide Deck

Once Skills are installed, you can use them directly in Claude Code. For example, I previously wrote a blog post "Deploying OpenClaw on Amazon EC2 - A Developer's Perspective", covering one-click CloudFormation deployment, VPC Endpoints security architecture, and multi-region inference profile configuration. It's a detailed post. If I needed to present this topic at a developer conference the next day, building slides manually would take too long. With the pptx skill, it takes one command:

❯ /example-skills:pptx
⏺ PPTX skill loaded. What presentation would you like me to create?

❯ Turn the following blog post into a slide deck:
  https://builder.aws.com/content/3CQFzc91nM9sGkfHRbpjo4eXojf/deploying-openclaw-on-amazon-ec2-a-developers-perspective

Claude Code reads the blog, extracts the architecture descriptions, deployment steps, and key configurations, organizes them into well-structured slides, and generates a .pptx file — all within the terminal, powered by Amazon Bedrock. From blog post to presentation-ready slides in a single command.

Scenario B: Claude Desktop (Cowork 3P)

Claude Desktop can run in "third-party platform" mode, using Bedrock for inference instead of Anthropic's own servers. This is called Cowork 3P.

Step 1: Open the Setup UI

Open Claude Desktop (you don't need to log in)
Go to Help → Troubleshooting → Enable Developer mode
Go to Developer → Configure third-party inference

This opens the built-in configuration UI.

Step 2: Configure Bedrock

Fill in the following fields:

Field	Value
Inference provider	Bedrock (select the radio button)
AWS region	`us-east-1`
AWS bearer token	Leave empty
Bedrock base URL	Leave empty
AWS profile name	`default`
AWS config directory	Leave empty (uses `~/.aws` by default)

Under IDENTITY & MODELS:

Field	Value
Model list	`us.anthropic.claude-opus-4-6-v1`

The model list uses Bedrock inference profile IDs. You can add multiple models — click + Add for each one. The first entry becomes the default.

Step 3: Apply and Relaunch

Click Apply locally at the bottom of the Setup UI
Fully quit Claude Desktop (Cmd+Q on macOS)
Reopen Claude Desktop

After relaunch, Claude Desktop shows the Bedrock login screen — no Anthropic account needed, just your AWS credentials:

Step 4: Verify

After relaunch, you should see:

Bottom-left corner shows Cowork 3P | Bedrock
The model picker shows us.anthropic.claude-opus-4-6-v1
Claude responds and identifies itself as running on the Bedrock model

Send a test message like "What version of the model are you currently using?" — Claude should confirm it's powered by claude-opus-4-6-v1 in Cowork mode.

Adding More Models Later

To add models (e.g., Opus 4.7) after initial setup:

In the macOS menu bar, go to Help → Troubleshooting → Enable Developer mode
A Developer menu appears in the menu bar — click Developer → Configure third-party inference
Under Model list, click + Add and enter us.anthropic.claude-opus-4-7
Click Apply locally, then Cmd+Q and reopen Claude Desktop

The model picker at the bottom of the chat window will now show all configured models.

How It Works Under the Hood

When you set AWS profile name to default, Claude Desktop reads your ~/.aws/credentials and ~/.aws/config files to authenticate with Bedrock. The three authentication methods are:

Method	When to use
AWS bearer token	If you have a Bedrock API key
AWS profile name	If you have standard AWS credentials (this is what we used)
Credential helper	For enterprise SSO setups with rotating credentials

You only need one of the three. The Setup UI validates the configuration and writes it to ~/Library/Application Support/Claude-3p/claude_desktop_config.json on macOS.

Important: Use the Setup UI

During this setup, I first tried manually editing the claude_desktop_config.json file. This resulted in a persistent "Your provider setup needs a fix" error. The Setup UI handles the correct format and field validation automatically — use it instead of hand-editing the JSON.

Troubleshooting

"on-demand throughput isn't supported" — You're using a bare model ID instead of an inference profile ID. Use the us. prefixed IDs (e.g., us.anthropic.claude-opus-4-6-v1).

"Your provider setup needs a fix" in Claude Desktop — Don't hand-edit the config JSON. Use the Setup UI (Developer → Configure third-party inference) and click Apply locally.

Claude Code /status doesn't show Bedrock — Make sure CLAUDE_CODE_USE_BEDROCK is set to "1" in ~/.claude/settings.json under the env key. Restart Claude Code after changing settings.

AWS credentials not found — Claude Code uses the standard AWS SDK credential chain. Verify with aws sts get-caller-identity. For Claude Desktop, make sure the AWS profile name matches a profile in ~/.aws/credentials.

Summary

	Claude Code CLI	Claude Desktop (Cowork 3P)
Config location	`~/.claude/settings.json`	Setup UI → Apply locally
Key setting	`CLAUDE_CODE_USE_BEDROCK=1`	`inferenceProvider: bedrock`
Auth method	AWS SDK credential chain	AWS profile name
Model format	Inference profile ID	Inference profile ID
Verify	`/status` in Claude Code	Bottom-left shows "Cowork 3P \| Bedrock"

Both scenarios use the same AWS credentials and Bedrock model access. Once you have one working, the other is straightforward.

A Note on the Setup Process

This entire configuration — both scenarios, including troubleshooting the Claude Desktop JSON format issue — was completed through conversation with Kiro, an AI-powered IDE. Kiro checked the AWS environment, verified IAM permissions, wrote the settings files, researched the official documentation, and diagnosed the Setup UI requirement for Claude Desktop — all without leaving the IDE.

Tested with Claude Code 2.1.123, Claude Desktop (Cowork 3P), Claude Opus 4.6 & 4.7 on Amazon Bedrock, us-east-1

Deploying OpenClaw on Amazon EC2 - A Developer's Perspective

Haowen Huang — Thu, 16 Apr 2026 04:10:44 +0000

What is OpenClaw?

OpenClaw is a personal AI assistant that you can deploy on your own infrastructure. It can respond to you through channels you already use — WhatsApp, Telegram, Slack, Discord, Google Chat, Signal, iMessage, WeChat, Lark, and 20+ other platforms. It can have voice conversations on macOS/iOS/Android, and render a real-time Canvas you can control. The Gateway is just the control plane — the product itself is the assistant.

If you want a self-hosted, fast, always-on single-user personal assistant, OpenClaw is it.

Why Run Your Own AI Assistant on AWS?

Most people interact with AI through hosted services. That works — until you care about:

Privacy: Your conversations, code, and data stay in your AWS account
Cost control: Pay only for Bedrock API usage, no per-seat SaaS fees
Customization: Full control over models, plugins, and integrations
Security: No open ports, no public endpoints, SSM-only access

By deploying OpenClaw on AWS with Amazon Bedrock, you can use the latest Claude models (Opus 4.6, Sonnet 4.6) as your personal AI assistant — not just for coding, but for automation, messaging, device control, and more.

I decided to try it out myself. Here's how it went.

Architecture: What You're Deploying

🚀 Quick Start: If you're an experienced developer, you can use the deployment template directly:
curl -O https://raw.githubusercontent.com/hanyun2019/openclaw-on-aws/main/openclaw-deployment.yaml

aws cloudformation create-stack \
  --stack-name openclaw \
  --template-body file://openclaw-deployment.yaml \
  --capabilities CAPABILITY_IAM \
  --region us-east-1
📦 Template URL: github.com/hanyun2019/openclaw-on-aws

⚠️ Non-US Region Users: Additional configuration is required after deployment. See the Non-US Region Deployment Guide below.

Before we dive in, here's what the CloudFormation template sets up:

User Access: Connect via SSM Session Manager to establish a secure tunnel, forwarding local localhost:18789 to the EC2 instance — no inbound ports required.

Key design decisions:

EC2 in the public subnet — for initial setup (package downloads via Internet Gateway)
VPC Endpoints in the private subnet — ensures Bedrock API calls never leave the AWS network
No inbound ports open — all access through SSM port forwarding
Graviton (ARM) instances — better price-performance ratio

Prerequisites

Before you start, make sure you have:

An AWS account with billing enabled
IAM permissions: Ability to create CloudFormation, EC2, IAM, and VPC resources
Local tools installed:
- AWS CLI v2
- SSM Session Manager Plugin

US Region Deployment Guide

If you're deploying in us-east-1 or us-west-2, it's genuinely a one-click experience.

Step 1: Download the Template

curl -O https://raw.githubusercontent.com/hanyun2019/openclaw-on-aws/main/openclaw-deployment.yaml

Step 2: Deploy the Stack

aws cloudformation create-stack \
  --stack-name openclaw \
  --template-body file://openclaw-deployment.yaml \
  --capabilities CAPABILITY_IAM \
  --region us-east-1

Optional parameters:

Parameter	Default	Description
`InstanceType`	`t4g.large`	Graviton instance type (2 vCPU, 8GB RAM)
`KeyPairName`	(none)	EC2 key pair for SSH access (optional)
`CreateVPCEndpoints`	`true`	Create VPC endpoints for private Bedrock access
`AllowedSSHCIDR`	(empty)	CIDR block for SSH access (optional)

For example, to use a larger instance:

aws cloudformation create-stack \
  --stack-name openclaw \
  --template-body file://openclaw-deployment.yaml \
  --capabilities CAPABILITY_IAM \
  --region us-east-1 \
  --parameters ParameterKey=InstanceType,ParameterValue=t4g.xlarge

Step 3: Wait (~10-15 minutes)

aws cloudformation wait stack-create-complete \
  --stack-name openclaw --region us-east-1

Go grab a coffee. ☕

Step 4: Get Your Access Info

aws cloudformation describe-stacks \
  --stack-name openclaw \
  --query 'Stacks[0].Outputs' \
  --region us-east-1

This gives you the instance ID and access URL.

Step 5: Connect via SSM Port Forwarding

# Get Instance ID
INSTANCE_ID=$(aws cloudformation describe-stacks \
  --stack-name openclaw \
  --query 'Stacks[0].Outputs[?OutputKey==`InstanceId`].OutputValue' \
  --output text --region us-east-1)

# Start the tunnel
aws ssm start-session \
  --target $INSTANCE_ID \
  --region us-east-1 \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["18789"],"localPortNumber":["18789"]}'

Step 6: Open OpenClaw

Navigate to the Step3AccessURL from the stack outputs:

http://localhost:18789/?token=<your-token>

That's it. You're in. 🎉

Non-US Region Deployment Guide

If you're deploying outside the US (e.g., Sydney ap-southeast-2), you need to modify the model IDs.

Note: If you're deploying in us-east-1 or us-west-2, you can skip this section. The template's default us. prefixed model IDs work out of the box in US regions.

The Issue

The template defaults to us.anthropic.claude-opus-4-6-v1 — this is the US region Inference Profile. In other regions, you need to use the corresponding regional prefix.

Solution Steps

1. Connect to the Instance via SSM

aws ssm start-session --target <instance-id> --region ap-southeast-2

2. Query Available Inference Profiles (Optional)

aws bedrock list-inference-profiles --region ap-southeast-2 \
  --query 'inferenceProfileSummaries[*].inferenceProfileId' \
  --output table

3. Update OpenClaw Configuration

nano /home/ubuntu/.openclaw/openclaw.json

Replace the us. prefix in model IDs with your region's prefix:

{
  "models": {
    "providers": {
      "amazon-bedrock": {
        "models": [
          {
            "id": "au.anthropic.claude-opus-4-6-v1",
            "name": "Claude Opus 4.6"
          },
          {
            "id": "au.anthropic.claude-sonnet-4-6",
            "name": "Claude Sonnet 4.6"
          }
        ]
      }
    }
  },
  "agents": {
    "defaults": {
      "model": {
        "primary": "amazon-bedrock/au.anthropic.claude-opus-4-6-v1"
      }
    }
  }
}

nano save: Ctrl+O → Enter to confirm → Ctrl+X to exit

4. Restart the Gateway

systemctl --user restart openclaw-gateway.service

Done! 🎉

Understanding Inference Profile Prefixes

Here's a quick reference:

Prefix	Scope	Example Regions
`us.`	US cross-region	us-east-1, us-east-2, us-west-2, ca-central-1
`eu.`	Europe cross-region	eu-central-1, eu-west-1, eu-west-3, eu-north-1
`apac.`	Asia-Pacific cross-region	ap-northeast-1, ap-southeast-1, ap-southeast-2, ap-south-1
`au.`	Australia	ap-southeast-2, ap-southeast-4
`jp.`	Japan	ap-northeast-1, ap-northeast-3
`global.`	Global cross-region (routes to optimal commercial region)	Can be called from all commercial regions

Rule of thumb: Use the most specific prefix for your deployment region.

Deploying in us-east-1 or us-west-2? The default us.anthropic.claude-opus-4-6-v1 just works. No changes needed.
Deploying in ap-southeast-2 (Sydney)? Use au.anthropic.claude-opus-4-6-v1.
Deploying in ap-northeast-1 (Tokyo)? Use jp.anthropic.claude-sonnet-4-6 or apac. prefix.
Deploying in eu-west-1 (Ireland)? Use eu.anthropic.claude-opus-4-6-v1.
Not sure? Query aws bedrock list-inference-profiles in your region to see what's available.

Note: Model availability varies by region. For example, Claude Opus 4.6 in Japan may only be available with the global. prefix, while Sonnet 4.6 has a jp. prefix. Use aws bedrock list-inference-profiles to check actual available profiles in your region.

Cost Estimate

Resource	Spec	Est. Monthly Cost	Calculation
EC2 (`t4g.large`)	2 vCPU, 8GB RAM	~$49	$0.0672/hr × 730 hrs
EBS (`gp3`)	50GB	~$4	$0.08/GB-mo × 50GB
VPC Endpoints (×4)	Interface type	~$29	$0.01/hr × 730 hrs × 4 endpoints
Bedrock API	Usage-based	Variable	—
Total (excl. API)	—	~$82	—

Pricing References (us-east-1 region, 2024):

EC2 pricing: AWS EC2 T4g Instances

EBS pricing: AWS EBS Pricing

VPC Endpoint pricing: AWS PrivateLink Pricing

Note: Actual prices may vary by region and time. Please refer to official AWS pricing pages for current rates.

Cost-saving tip: Set CreateVPCEndpoints=false to save ~$29/month. In this case, Bedrock API calls will route through the Internet Gateway to Bedrock's public endpoints. Traffic is still encrypted via TLS, but traverses the public internet rather than staying within the AWS backbone. For scenarios with strict security or compliance requirements, keep VPC endpoints enabled to ensure traffic never leaves the AWS network.

FAQ

How do I access EC2 via SSM and use OpenClaw TUI?

Option 1: Via AWS Console

Open the EC2 Console
Select your OpenClaw instance
Click Connect → Select Session Manager → Click Connect

Option 2: Via AWS CLI

aws ssm start-session --target <instance-id> --region <your-region>

After connecting, switch to the ubuntu user and launch TUI:

sudo su - ubuntu
openclaw tui

How do I configure OpenClaw and switch Bedrock models?

Use the openclaw config command for configuration management, including switching models on Amazon Bedrock:

openclaw config

Stack deployment timed out (WaitCondition failure)?

Connect to the instance via SSM and check the setup log:

cat /var/log/openclaw-setup.log

Common causes:

Network issues during package downloads
Bedrock model access not yet approved (it can take a few minutes after requesting)

How do I retrieve my Gateway token?

# Replace <stack-name> with your stack name
aws ssm get-parameter \
  --name "/openclaw/<stack-name>/gateway-token" \
  --with-decryption \
  --query 'Parameter.Value' \
  --output text

How do I switch models?

Edit agents.defaults.model.primary in /home/ubuntu/.openclaw/openclaw.json, then restart:

systemctl --user restart openclaw-gateway.service

How do I update OpenClaw?

SSH or SSM into the instance and run:

npm update -g openclaw
systemctl --user restart openclaw-gateway.service

How do I tear it all down?

aws cloudformation delete-stack --stack-name openclaw --region us-east-1

This removes everything — EC2 instance, VPC, IAM roles, all of it. Clean.

Wrapping Up

Deploying OpenClaw on AWS is straightforward — with one note about region selection:

US regions (us-east-1, us-west-2): Truly one-click. The template works out of the box.
Other regions: You need to replace the model IDs with the corresponding regional inference profiles.

Either way, the CloudFormation template handles 90% of the work. What you get at the end is a private, secure AI assistant running on your own infrastructure — no data leaving your AWS account, no third-party services in the loop, and the full power of Claude at your fingertips.

Resources:

📦 Deployment Template (GitHub)

Series Preview: Four Ways to Deploy OpenClaw on AWS

This post is the first in the OpenClaw on AWS series. There are four ways to deploy OpenClaw on AWS, each suited for different scenarios:

Deployment Method	Use Case	Status
EC2 Deployment	Full control, custom configuration, persistent runtime	✅ This post
Lightsail Deployment	Simple and fast, fixed monthly cost, beginner-friendly	📝 Coming soon
AgentCore Deployment	Managed service, no infrastructure management	📝 Coming soon
EKS Deployment	Containerized, scalable, enterprise-grade	📝 Coming soon

Stay tuned for upcoming posts!

Industry Trends: The Rise of AI Agents

Beyond OpenClaw, the AI Agent space is evolving rapidly. More developers are exploring how to build autonomous, controllable AI agent systems.

One project worth watching is Hermes Agent — an open-source AI Agent framework developed by Nous Research that has been gaining increasing attention in the developer community. It offers a different approach to building and deploying AI agents.

I'll share hands-on experience with Hermes Agent in upcoming blog posts — stay tuned.

Happy Deploying! 🦞

References

Running Claude Agent SDK with Skills on Amazon Bedrock

Haowen Huang — Wed, 11 Mar 2026 08:56:47 +0000

by Haowen Huang (LinkedIn)

The Claude Agent SDK enables building multi-agent systems with Skills, MCP servers, and subagents. By default, it requires an Anthropic API key. This post shows how to run it entirely on Amazon Bedrock instead—no Anthropic API key needed.

The Problem

The DeepLearning.AI course "Agent Skills with Anthropic" assumes you have an ANTHROPIC_API_KEY. But what if you're already using AWS and want to leverage your existing Amazon Bedrock access?

The Solution: Two Lines of Code

The Claude Agent SDK uses Claude Code under the hood, which supports Amazon Bedrock via environment variables. The key configuration is surprisingly simple:

import os

# Configure Claude Code to use Amazon Bedrock
os.environ["CLAUDE_CODE_USE_BEDROCK"] = "1"
os.environ["AWS_REGION"] = "us-west-2"  # Your preferred region

That's it. Set these before creating ClaudeSDKClient, and the SDK will use your AWS credentials instead of an Anthropic API key.

Prerequisites

Before running, verify your AWS setup:

# Check AWS CLI
aws --version

# Verify credentials
aws configure get aws_access_key_id

# Test Bedrock access
aws bedrock list-foundation-models --query "modelSummaries[?contains(modelId, 'claude')]" --output table

You need:

AWS credentials configured (~/.aws/credentials or environment variables)
Amazon Bedrock model access enabled in your AWS console
IAM permissions for bedrock:InvokeModel

Complete Example

Here's the modified agent.py for Amazon Bedrock:

import asyncio
import os
from dotenv import load_dotenv
from claude_agent_sdk import (
    AgentDefinition, ClaudeSDKClient, ClaudeAgentOptions, AssistantMessage,
)

load_dotenv()
AWS_REGION = os.environ.get("AWS_REGION", "us-west-2")

# Key configuration for Bedrock
os.environ["CLAUDE_CODE_USE_BEDROCK"] = "1"
os.environ["AWS_REGION"] = AWS_REGION

async def main():
    agents = {
        "docs_researcher": AgentDefinition(
            description="Finds information from official documentation.",
            prompt="You research official docs.",
            tools=["WebSearch", "WebFetch"],
            model="haiku"
        ),
    }

    options = ClaudeAgentOptions(
        system_prompt="You are a helpful assistant.",
        allowed_tools=["Skill", "Task", "Write", "Bash", "WebSearch", "WebFetch"],
        model="sonnet",
        agents=agents
    )

    async with ClaudeSDKClient(options=options) as client:
        await client.query("Hello!")
        async for message in client.receive_response():
            if isinstance(message, AssistantMessage):
                print(message.content)

asyncio.run(main())

Adding MCP Servers (Optional)

MCP servers like Notion work the same way. Just ensure the token exists before adding the config:

NOTION_TOKEN = os.environ.get("NOTION_TOKEN")

mcp_servers = {}
if NOTION_TOKEN:
    mcp_servers["notion"] = {
        "command": "npx",
        "args": ["-y", "@notionhq/notion-mcp-server"],
        "env": {"NOTION_TOKEN": NOTION_TOKEN},
    }

options = ClaudeAgentOptions(
    mcp_servers=mcp_servers,
    # ... other options
)

What Works on Amazon Bedrock

Everything from the original SDK works:

Skills (e.g., learning-a-tool)
Subagents with parallel execution
MCP servers (Notion, etc.)
All built-in tools (WebSearch, Bash, Write, etc.)

A Note on the Debugging Process

This entire migration—from identifying the Bedrock configuration, fixing MCP server issues, to successfully running Skills with subagents—was completed through conversation with Kiro, an AI-powered IDE. No external documentation was consulted. Kiro diagnosed issues in real-time, suggested fixes, and validated the setup by running test scripts directly.

The workflow:

Asked Kiro how to use Bedrock instead of Anthropic API
Kiro checked the environment, identified missing dependencies
Kiro found the correct configuration (environment variables, not client parameters)
Fixed runtime errors (MCP config validation when token was missing)
Verified everything worked end-to-end

This demonstrates how AI-assisted development can accelerate debugging unfamiliar SDKs without documentation diving.

Conclusion

Running Claude Agent SDK on Amazon Bedrock requires just two environment variables. Your existing AWS credentials handle authentication, and all SDK features—Skills, subagents, MCP servers—work unchanged.

If you're already in the AWS ecosystem, this is the simplest path to using Claude Agent SDK without managing a separate Anthropic API key.