Amazon Bedrock AgentCore pricing (2026)

Amazon Bedrock AgentCore pricing is sold on one promise: agents spend most of their time waiting on a model, so you should not pay for the wait. For CPU that is true. For memory it is not, and memory keeps billing for fifteen minutes after the last request by default. Price a short chat session at AWS's own rates and the idle tail is two thirds of the Runtime bill. AWS's worked example also gets its memory arithmetic wrong, in the direction that makes memory look cheaper.

What does Amazon Bedrock AgentCore charge for?

Each AgentCore service has its own meter, and none of them has a monthly base fee. The Amazon Bedrock AgentCore pricing page lists these rates:

Runtime also has an Instances compute type, which bills the EC2 instance plus a management fee. The page's example uses a 12% fee on a c7g.2xlarge, and notes that Savings Plans and Reserved Instances apply to the compute but not to the fee: "The management fee is always calculated on the On-Demand rate." The rest of this post is about microVMs, the consumption-priced default.

Is AgentCore Runtime idle time really free?

Only the CPU half of it. The pricing page says "I/O wait and idle time is free, if no other background process is running", and then defines the two meters differently: "For CPU resources, you are charged based on actual consumption - if your agent consumes no CPU during I/O wait, there are no CPU charges. For memory resources, you're charged for the peak memory consumed up to that second."

Memory is billed across the whole session, and the pricing page defines the session as the span "from microVM boot, initialization, active processing, idle periods, until session termination (microVM shutdown)". The AgentCore cost controls page says it without the marketing: "Memory remains billable while the session runs."

What ends a session is a timer. The lifecycle settings page gives idleRuntimeSessionTimeout a range of 60 to 28,800 seconds on microVMs, with "Default: 900 seconds (15 minutes)", and maxLifetime a default of 28,800 seconds. The timer resets on every invocation to the same session. So a conversation that ends with the user closing the tab keeps its microVM, and its memory meter, for another fifteen minutes. The lifecycle page says only that shorter timeouts save costs in development environments; the memory trade-off is spelled out on the cost controls page: "A shorter idleRuntimeSessionTimeout can reduce how long memory remains billable after the last invocation, at the cost of more frequent cold starts."

How much of an AgentCore Runtime session is idle memory?

In a hypothetical chat session with the default timeout, most of it. AWS does not publish a chat-shaped example, so here is a hypothetical one priced at the published microVM rates. The inputs are assumptions, not measurements: a user sends four messages and the last reply finishes three minutes after the first request, the agent uses 1 vCPU for a total of 40 seconds across them and holds a steady 1.5 GB, and nobody calls StopRuntimeSession, so the session ends when the idle timeout fires.

The shorter timeout cuts this session's Runtime cost by 63.0%, and CPU does not move at all. At a million sessions a month that is $5,246.94 against $1,939.44. The cost is a cold start for any user who replies after more than a minute, which is the trade-off the cost controls page names.

The ratio follows from the rates. A vCPU-hour costs 9.47 times a GB-hour, so any session that holds more than about 9.5 GB-seconds of memory for each vCPU-second it uses will bill more for memory than for CPU. Waiting is cheap for CPU and expensive for memory, and agents mostly wait. Memory per session is capped: the AgentCore quotas page sets a "Maximum hardware allocation per session" of 2vCPU/8GB.

To see your own session shape, AgentCore publishes CPUUsed-vCPUHours and MemoryUsed-GBHours to CloudWatch, which the runtime metrics page describes as "Useful for resource tracking and estimated billing visibility."

Does the AgentCore Runtime pricing example add up?

Not quite. The pricing page's Runtime example is a customer support agent whose session runs 60 seconds, with memory at 1 GB for 10 seconds, 2 GB for 20 seconds and 2.5 GB for 30 seconds. The page computes:

"Memory cost per session: 10 seconds × 1GB × ($0.00945/3600) + 20 seconds × 2GB × ($0.00945/3600) + 30 seconds × 2.5GB × ($0.00945/3600) = $0.000026 + $0.000053 + $0.000197 = $0.000276"

The middle term is 20 seconds at 1 GB, not 2 GB. Twenty seconds at 2 GB is $0.000105, which makes memory $0.000328 per session, 18.9% more than stated. Carried through the example's 10 million sessions, the monthly total is $7,756.25 rather than the page's "$7,235". The derived claims move too: CPU is 57.7% of the corrected cost rather than 62%, and the pre-allocated memory comparison drops from the page's "up to 1.4x higher memory costs" to 1.2x (150 GB-seconds provisioned against 125 used).

The Browser example has a different gap. Its inputs say that "during I/O it is utilizing 0.4vCPU and 5GB memory", but the calculation bills only the active 120 seconds of CPU and 4 GB of memory for 600 seconds. Priced by the page's own rules, that session costs $0.0183 rather than $0.012267, and the 100,000-session month is $1,830.00 rather than $1,226.67. The Policy example says a team "used 10,000 tokens" and then bills 20K of them.

None of this changes a rate. It does mean the worked examples understate memory, which is the meter that grows with idle time.

How much do AgentCore Memory, Gateway and Identity cost?

These are billed per request or per stored record rather than per second, so an idle session adds nothing to them, though stored long-term memory records bill hourly regardless of session activity. From the pricing page's examples:

• Memory. 100,000 short-term events, 10,000 stored long-term records and 20,000 retrievals come to $25, $7.50 and $10, for "Monthly total: $42.50". Long-term storage is "Billed hourly assuming a 31 day month".
• Gateway. 50 million interactions with one search and four tool calls each cost $1,250 in search and $1,000 in invocations. Search is five times the per-call price of an invocation, so semantic tool search is the Gateway meter to watch. A gateway created from the console or the AgentCore CLI can use a default Amazon Cognito configuration, which bills separately under Amazon Cognito pricing.
• Identity. Usually free: "Customers who use AgentCore Identity through either AgentCore Runtime or AgentCore Gateway, do not incur any additional charges for their use of AgentCore Identity."
• Observability. Billed by CloudWatch. The example ingests 10 GB of spans at $0.35/GB and 6 GB of event logs at $0.50/GB for $6.50 a month. Log storage and queries follow the rates in what CloudWatch Logs actually cost.

For scale: at $0.25 per 1,000 events, a conversation that writes four questions and four answers to short-term memory as eight events costs $0.002, 38.1% of the hypothetical session's Runtime cost at the default timeout.

Is model inference included in Bedrock AgentCore pricing?

No. The AgentCore pricing table has no token line for the agent's own model calls, and the cost controls page lists inference as its own charge: "The model provider bills each time the agent calls the configured model. One harness invocation can make multiple model calls." The pricing page's Runtime example counts the time spent waiting for LLM responses as I/O wait, and prices none of the tokens.

The exception is Evaluations: "Model usage costs are included for built-in evaluators". For the agent's own calls, the levers (batch, prompt caching, Provisioned Throughput) are covered in how to cut Amazon Bedrock inference cost. Splitting that spend by tenant or team is its own problem: Bedrock cost per team.

How do you lower an AgentCore Runtime bill?

• End sessions you know are over. When a user closes a chat, call StopRuntimeSession, which AWS describes as a way to "immediately terminate active agent AgentCore Runtime sessions". In the hypothetical above, the default tail alone is $0.003544 of a $0.005247 session.
• Tune the idle timeout to how users return. AWS's own lifecycle table suggests 10 to 15 minutes for interactive chat. Shorter saves memory and costs a cold start on the next message.
• Shrink what the container keeps resident. Memory is billed at the peak of each second, so long-lived subprocesses and loaded libraries bill through every idle minute. Loading rarely used components on demand keeps them off the meter.
• Check CPU and memory separately, not the total. CloudWatch shows the shape per minute. For billed figures the cost controls page is explicit: "Observability explains activity but is not a billing report."
• Consider Instances for long, heavy sessions. Sessions there run up to 14 days on an EC2 instance your commitments can cover, which suits workloads that are busy rather than waiting.

Boot time is on the meter too, which is the same question Lambda users face with INIT: see whether Lambda cold starts cost money.