AgentCore Pricing: Bedrock AgentCore Pricing, Cost per Component and the Line Nobody Budgets

Most AgentCore cost estimates are wrong in the same direction. Someone reads that Runtime is 0.0895 dollars per vCPU-hour, multiplies by an expected number of agent-hours, adds a margin, and takes that number into the planning meeting. Then the first real invoice arrives with twelve other line items on it, because AgentCore is not one service with one meter. It is thirteen capabilities that each bill on their own unit, and the ones that surprise people are almost never Runtime.

This is the component-by-component breakdown, at US list prices verified on 9 September 2026, plus one number that will not be on your AWS bill at all and is usually larger than everything above it.

What AgentCore actually charges for

There is no subscription, no minimum and no commitment. Every capability meters independently, which is genuinely good news for a pilot and mildly bad news for forecasting, because there are five different billing patterns in play at once: active compute consumption, per request, per record, pass-through, and free during preview.

Why Runtime is rarely the line that hurts

Runtime bills active CPU consumption and peak memory per second, with a one-second minimum, and this is the part AWS got right in a way that matters commercially. Agent workloads sit in I/O wait for most of their wall-clock life, waiting on a model, a tool call or a database. If nothing is consuming CPU during that wait, that wait is not billed. Estimates that assume you pay for elapsed agent time will therefore come out high, often by a factor of two or three.

The lines that actually blow past the forecast tend to be Web Search and Memory. Web Search at 7 dollars per 1,000 queries is roughly 1,400 times the unit price of a Gateway invocation, so an agent that reflexively searches before answering is expensive in a way that never shows up in a compute model. Memory compounds differently: you pay to write events, again to store records every month, and again to retrieve them. A chatty agent with long retention builds a bill that grows even in a month when usage is flat, because storage is a recurring per-record charge.

Browser deserves a second look for the same reason. It bills at Runtime rates on vCPU-hours, which is reasonable for a genuine agentic browsing task where the model reasons about what it sees. It is poor value when the job is really just fetching structured data off a known set of pages on a schedule. For that shape of work a dedicated service that browses the page and returns the fields you asked for costs a fraction of paying an LLM to drive a headless browser by the vCPU-hour. Split the workload before you commit the budget: reasoning tasks to Browser, extraction tasks to something metered per page.

Identity is free more often than people assume

AgentCore Identity lists at 0.010 dollars per 1,000 token or API key requests, and that rate is the one most calculators quote. It is also waived when Identity is used through Runtime or Gateway, which is how the large majority of real deployments use it. If your agents run on AgentCore Runtime and reach third-party systems through Gateway tools, the practical Identity cost is usually zero, and a forecast that lines it up as a growth-linked cost is modelling a charge you will not receive.

Policy is the other line worth understanding rather than just adding up. At 0.000025 dollars per authorization request you would need forty million authorization decisions to spend a thousand dollars, so as a cost item it is noise. Its significance is architectural, not financial: Policy is where authorization decisions live, and it is worth knowing what kinds of decision it can and cannot express before you rely on it. We went through that in detail on our AWS AgentCore spend controls page.

The fourteenth number: what your agents spend

Now the line that is not in the table above, because AWS does not bill it.

Bedrock AgentCore Payments went generally available on 18 August 2026 and is the only component on the AWS pricing page with pass-through pricing. AWS adds nothing of its own for creating an instrument or processing a payment. You pay whatever Coinbase CDP or Stripe Privy charges, and the money your agents actually spend settles in USDC on Base, Ethereum or Solana, in a wallet provider ledger that is not your AWS invoice.

So there are two different costs with the same word attached to them, and confusing them is how budgets go wrong. The first is what it costs to run the agent, and everything above prices that. The second is what the agent buys, and nothing above prices that at all, because it is not AWS revenue. On the pilot they look similar. At scale the second one is the one that ends up in front of the CFO.

Which raises the practical question a finance partner will ask in the review: what caps the second number? We read the published AgentCore API model on 9 September 2026 to answer it precisely, rather than guessing. The entire spend ceiling in AgentCore Payments is one property, SessionLimits.maxSpendAmount, a value plus a currency, and the currency enum contains exactly one member, USD. That ceiling is optional on the call that creates a payment session, so a session can be opened with no maximum at all. Sessions are required to expire, between 15 and 480 minutes.

The consequence follows from the schema rather than from opinion. Because the limit is scoped to a session, and a session cannot outlive eight hours, and no cumulative, daily or monthly property exists anywhere in either the data-plane or control-plane model, every new session starts again at the full maximum. An agent with a 500 dollar session ceiling that runs continuously for a month does not have a 500 dollar budget. It has a 500 dollar ceiling on each of however many sessions it opens.

How to model AgentCore for a real budget

A forecast that survives contact with the first invoice usually has four parts rather than one.

Model compute on active seconds, not elapsed time. Take your expected agent-minutes, cut them by the share spent in I/O wait, and apply the vCPU-hour and GB-hour rates to what remains. Then add the 12 percent Runtime Instances management fee separately if you are using dedicated instances, because that sits on top of EC2 On-Demand rather than replacing it.

Model the per-call units on behaviour, not on headcount. Gateway invocations, Memory events and retrievals, and Web Search queries all scale with how the agent thinks, not with how many users you have. One design that searches before every answer and one that searches when uncertain can differ by an order of magnitude on identical traffic. This is the single highest-leverage thing to measure in the pilot.

Treat storage as a floor. Memory long-term records bill monthly, so retention policy is a cost decision. Decide how long an agent needs to remember something before you switch it on, not after twelve months of accumulation.

Budget agent spend separately, and cap it somewhere that aggregates. This is the part the calculators cannot help with, because it is not an AWS number. If your agents pay for metered APIs or MCP servers, forecast that as its own line with its own owner, and put a policy in front of it that can express a monthly total rather than a session ceiling.

How much does Bedrock AgentCore cost for a small production agent?

Take a support agent handling 10,000 conversations a month, roughly 90 seconds of wall-clock each with two thirds of that in I/O wait, on 1 vCPU and 2 GB. That is about 83 billable vCPU-hours and 167 GB-hours, so around 9 dollars of Runtime. Say six Gateway tool calls per conversation, 60,000 invocations, 30 cents. Twenty memory events written and ten retrieved per conversation, so 200,000 events at 0.25 per thousand is 50 dollars, and 100,000 retrievals at 0.50 per thousand is another 50. One authorization per tool call is under a dollar. No Web Search.

That is roughly 110 dollars a month, and Memory is 90 percent of it while the compute everyone models is under 10 percent. Turn on Web Search at one query per conversation and you add 70 dollars, which is eight times the Runtime bill. The lesson is not that AgentCore is expensive. It is that the cheap-looking components are the ones that scale with agent behaviour, and behaviour is the thing nobody forecasts.

Is AgentCore cheaper than self-hosting?

For intermittent traffic and stateful sessions, usually yes, because you are not paying for idle capacity and you are not building session isolation, credential vaulting and observability yourself. The case flips when your agent is stateless within a session, your tools are already idempotent, and traffic is steady enough that a plain Lambda calling the model API directly does the same job. At that point the per-invocation Runtime price is buying you infrastructure you do not need.

The comparison people get wrong is the middle case, where they price only compute on both sides. Self-hosting does not charge you 7 dollars per 1,000 searches or 0.75 per 1,000 stored records, but it also does not give you those things. Compare complete stacks or the answer is meaningless.

What AgentCore pricing does not buy you

Nothing in the price list is a spend policy. Gateway rate limits cap how many times a tool is called, which is not the same as capping what a call is worth: ten calls that each commit 50,000 dollars pass a hundred-calls-per-minute limit without complaint. Agent Registry has an approval configuration, but it governs whether an agent is approved for reuse, not whether a payment is approved. AgentCore Payments has its one optional session amount, in USD, for at most eight hours.

If the total across a month matters more than the total across a session, if some counterparties are allowed and others are not, if a human has to sign off above a threshold, or if finance has to reconcile agent purchases to the general ledger in dollars rather than to a chain explorer, that is a policy layer sitting above AgentCore rather than a line on the AWS bill. Our agent spend controls do that part: budgets that aggregate per agent and per cost center, counterparty allow lists, approval thresholds that hold a payment pending instead of declining it, and an audit trail that reconciles to your books. The mechanics of how AgentCore pays for things over x402 are covered in our walkthrough of AgentCore Payments, and the broader pattern of paying per tool call in MCP payments.

Price the runtime carefully. Then price the spend separately, and give it a ceiling that actually holds.