Cross-platform decision guide · kept current

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

The decision in one table

Prices change. Each figure carries its own verification date in Sources & provenance below — re-check 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 when you call Bedrock's global endpoints — Bedrock's regional endpoints add a 10% premium, as does pinning the first-party API to a geography — so the decision is usually 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 — AWS's condition is that I/O wait and idle time are free if no other background process is running, so a session that's mostly waiting on a tool or the model costs little — read the condition before you assume an idle session is free. That 8-hour ceiling belongs to the default microVM path. Since runtime instances went GA on 6 Aug 2026 you can instead attach an agent to an EC2 capacity provider and hold a session for up to 14 days — AgentCore still handles provisioning and patching, but you are charged a management fee on top of your EC2 costs — 12% of the On-Demand rate, or 7.8% for G-series families including Graviton-based gr6 — so it is the not-serverless half of the runtime.

Token price is rarely the variable

Because Claude's per-token pricing is the same on the Anthropic API and on Bedrock's global endpoints, the platform choice rarely turns on the model bill. The one case where it does is data residency, and it is a wash: Bedrock's regional endpoints, which resolve to the single AWS region you name, carry a 10% premium over global, and so do its geo inference profiles (US, EU, JP, AU) — while Anthropic's own API applies the same 1.1x multiplier when you pin inference_geo: "us" on Claude 4.6 and later. Pinning a geography costs 10% wherever you run, so it is not a reason to prefer one platform. Otherwise the choice 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