Cross-platform decision guide · kept current

Where to run your Claude agent: API vs Bedrock vs Cloudflare

The decision in one table

Prices change. These reflect public pricing as of June 2026 and must be re-checked against each provider's pricing page before you rely on them.

Claude API vs Bedrock: which should you pick?

Pick the Anthropic API for the fastest path and the newest models first; pick AWS Bedrock when you already run on AWS and want Claude inside your existing IAM, VPC, CloudWatch, and consolidated billing. Claude's per-token price is the same on both, so the decision is governance and operational fit, not cost. New models and features usually land on the direct API first and reach Bedrock within weeks — if being first matters, that favors the API; if single-pane AWS governance matters more, that favors Bedrock.

Two recent additions worth knowing (June 2026)

AWS Lambda MicroVMs. If you run on AWS, this gives each agent session its own Firecracker-isolated micro-VM — snapshot-based fast resume with state preserved across a session — purpose-built to run untrusted or model-generated code. AWS documents it explicitly as a sandbox for Claude Managed Agents: Anthropic still hosts the agent loop and the model, and the MicroVM is where the agent's bash/file tool calls actually execute. It's the cleanest answer to "where do my agent's tools run" when you want hard per-session isolation inside your own AWS account.

Claude in Microsoft Foundry. Claude is now also reachable through Microsoft Foundry on Azure — Azure-native endpoints and billing, with inference still running on Anthropic's own infrastructure. It is in public preview. This sits outside the AWS + Cloudflare scope this guide compares; it's noted here only so the picture is complete.

Claude Platform on AWS. A third way to reach Claude from an AWS account, distinct from Bedrock: Claude Platform on AWS has Anthropic — not AWS — operate the inference stack, while AWS handles authentication (SigV4 or API key), IAM-based access control, and billing through AWS Marketplace. Because Anthropic runs it, it carries the full platform surface (Agent Skills, code execution, beta features) with typically same-day feature access, closing the weeks-long lag Bedrock usually has behind the direct API. The tradeoff: inference may route outside AWS, so it doesn't fit if data residency inside AWS is a hard requirement — Bedrock keeps inference in-account.

Agent runtimes compared: Cloudflare vs AWS AgentCore

The tables above answer "whose token bill, whose IAM." The other half of the decision is where the agent process actually runs and keeps its state between turns — the runtime. Two managed answers dominate once you've left a plain request/response Lambda behind: Cloudflare's Durable Objects + Agents SDK at the edge, and AWS Bedrock AgentCore Runtime inside your account. They make opposite bets about locality and session length.

On Cloudflare, each agent is a Durable Object — a single-threaded, globally-unique instance with its own transactional SQL storage. The Agents SDK builds on that to give every agent persistent state and WebSocket connections, and WebSocket Hibernation lets an idle agent evict from memory between turns while its connections stay open — so you don't pay duration charges for the wait. (In-memory state is discarded on hibernation; persisted state survives, which is the whole point of the SQL store.) AgentCore Runtime is the opposite shape: a managed, serverless, framework- and model-agnostic runtime that isolates each session in its own microVM, supports sessions up to 8 hours, and bills active consumption per second — CPU is free during I/O wait, so a session that's mostly waiting on a tool or the model costs little.

Token price is not the variable

Because Claude's per-token pricing is identical on the Anthropic API and Bedrock, the platform choice rarely turns on the model bill. It turns on operational fit: where your identity, secrets, networking, logging, and billing already live, and how much of the agent runtime you want to operate yourself versus hand to the provider. That framing — the abstraction boundary — is the spine of the decision.

A note on lock-in

The cleanest hedge is to keep the agent logic and tool layer portable and put a routing layer (such as an AI Gateway) between your code and the provider, so switching where inference runs is a config change, not a rewrite. That's also good cost-observability hygiene. Don't over-engineer it before you have a reason to switch — but design the boundary so you can. Which layers you are actually placing when you pick a runtime — orchestration, memory, tools, retrieval, the operational plane — is laid out in agentic AI architecture, including the same three platforms mapped layer by layer.

Frequently asked