Amazon Bedrock AgentCore Pricing: Hidden Costs That Bill While Your Agent Idles
Your Bedrock AgentCore agent waits 90% of the time, so the runtime bill is tiny. The surprise is a NAT gateway charging about $33 a month while nothing runs. A line-by-line cost map of running an AI agent on AWS, rebuilt from AWS's own pricing.
Your Bedrock AgentCore agent idles 90% of the time. Amazon Bedrock AgentCore pricing already knows that: the microVM billing scales CPU to zero while the agent waits on the model. So the first bill from a tidy little support agent should be tiny.
Then on a dev account running a cheap model, it shows up at about $49 for a thousand tasks, and $33 of that was spent while the agent did nothing at all. Two-thirds of that small bill, gone to a gateway that charges whether or not the agent runs. Switch to a capable model and the shape flips completely: tokens swamp everything and that same $33 becomes a rounding error. Same stack, two totally different bills.
I run read-only AWS agents for a living, so I went through the AgentCore rate card line by line and rebuilt AWS's own worked example by hand. The runtime is cheap and honest. The money leaks in two places nobody points at, and almost every "what is AgentCore" tutorial skips both.
This is the cost map I wish I had before I deployed. Every number here comes from the AWS AgentCore pricing page or AWS VPC pricing, for us-east-1, in October 2026. AWS says the rates can change, so re-check your Region before you quote them to finance.
Who this is for
You have an agent working on your laptop. Bedrock Agents, Strands, LangGraph, CrewAI, does not matter. Now you want it in production on AgentCore Runtime, and someone is going to ask what it costs per month. This is for that conversation.
If you have not picked a framework yet, this still matters, because the costs below are about the infrastructure around the agent, not the agent code.
The three lines on an AgentCore bill
An agent on AgentCore Runtime bills on three independent things. They do not scale together, which is the whole trap.
- Model tokens. Every reasoning step calls a foundation model, billed per token at that model's rate. This is almost always the biggest line.
- Runtime compute. CPU and memory your session actually uses, per second.
- The stuff around the agent. The VPC, the NAT gateway, storage, logs. Fixed-ish, and billed whether or not the agent runs.
Most tutorials show you line 2 because it is the AgentCore-specific one. In practice line 1 dominates the bill and line 3 is the one that surprises you on a dev account. Let me take them in the order that actually bites.
Runtime: cheaper than it looks, and v1 vs v2 is a real decision
AgentCore Runtime microVMs bill per second, and here is the kind part: CPU scales to zero during I/O wait. An agent spends most of its wall-clock time waiting on the model, a tool call, or a human. During that wait you pay for memory, not CPU.
There are two generations, and the rates are not the same (us-east-1):
| Resource | v1 | v2 (consumption) |
|---|---|---|
| CPU | $0.0895 per vCPU-hour | $0.1276 per vCPU-hour |
| Memory | $0.00945 per GB-hour | $0.0169 per GB-hour |
Read that twice. v2 costs more per unit than v1. v2's trade is that it reclaims idle memory automatically after 120 seconds, so you stop paying for the 2.5 GB your agent grabbed during one tool call once that call is done. v1 holds the memory for the whole session.
So the right pick depends on your session shape:
- Short, bursty sessions that free memory between steps: v2's reclaim earns back the higher rate.
- Long sessions that hold a steady, large working set: v1's lower per-unit rate can win, because there is little idle memory for v2 to reclaim.
There is also a committed-baseline rate on v2 ($0.0997 CPU, $0.0132 memory) launching by October 2026 for predictable load. If your traffic is steady, that is the lever, not the generation.
The worked example, rebuilt by hand
AWS publishes a support-agent example on the pricing page. I rebuilt it so you can see where every cent goes, because the shape teaches you more than the total.
The setup: 1 million sessions a month. Each session is 10 minutes, 90% of it I/O wait. 1 vCPU during the 60 seconds of active processing. Memory climbs from 1 GB at init, to 2 GB during retrieval, peaking at 2.5 GB during tool calls, on v2 so idle memory is reclaimed.
CPU per session, only the 60 active seconds bill:
1
60 s x 1 vCPU x ($0.1276 / 3600) = $0.002127Memory per session, split across the three phases:
1
2
3
4
300 s x 1.0 GB x ($0.0169 / 3600) = $0.001408
150 s x 2.0 GB x ($0.0169 / 3600) = $0.001408
150 s x 2.5 GB x ($0.0169 / 3600) = $0.001760
total = $0.004576Per session: $0.002127 + $0.004576 = $0.006703.
A million of those is $6,703 a month, and that is runtime only. Not a single token is paid for yet.
Two things jump out. First, memory is more than two-thirds of the runtime cost here, not CPU, because CPU scaled to zero for nine of every ten minutes. Second, the whole runtime line is still small next to what the model will cost at a million sessions. Which brings us to the line everyone underestimates on a small account.
The NAT gateway that bills while the agent sleeps
AgentCore's GA release included VPC support, and the AWS sample stack puts your agent in private subnets with one NAT gateway so it can reach the internet for tool calls and model endpoints.
Standard VPC NAT gateway pricing in us-east-1: $0.045 per hour, plus $0.045 per GB processed. Partial hours bill as full hours. Do the month:
1
$0.045/hour x 730 hours = $32.85/monthThat is before your agent handles a single request. It bills at 3 AM on a Sunday when nobody is talking to it. It bills on the dev account where someone deployed the sample on a Friday to try it out and then forgot.
Watch what that fixed $33 does across scale. The token column below uses Amazon Nova Pro on Bedrock (first-party rate: $0.0008 per 1K input tokens, $0.0032 per 1K output), at 200K input and 20K output per task, with the verified $0.006703 runtime per session from above:
| Tasks/month | Tokens (Nova Pro) | Runtime | NAT gateway | Total | Per task |
|---|---|---|---|---|---|
| 1,000 | ~$224 | ~$7 | $33 | ~$264 | $0.264 |
| 10,000 | ~$2,240 | ~$67 | $33 | ~$2,340 | $0.234 |
| 100,000 | ~$22,400 | ~$670 | $33 | ~$23,103 | $0.231 |
Nova Pro is a capable mid-tier model, and look what it does to the shape: tokens are the bill now, at every scale. Drop to Nova Lite or Nova Micro and that token column falls by 10x or more, while the runtime and NAT lines do not move at all. That is the whole point, the model you choose moves the bill far more than the vCPUs do.
So the NAT gateway story depends entirely on which model you run:
- Cheap model, low volume (Nova Micro on a dev account): the fixed $33 NAT can be the single biggest line on the bill, bigger than tokens and runtime combined. At Nova Micro rates ($0.000035/1K in, $0.00014/1K out) those same 1,000 tasks cost about $10 in tokens and $7 in runtime, so the $33 NAT is roughly two-thirds of a ~$49 bill. Tear the sample stack down between tests. Route AWS-service traffic (Bedrock, S3) through VPC endpoints, and only pay for a NAT gateway if the agent genuinely needs public internet egress.
- Capable model or real volume (Nova Pro and up): the NAT is a rounding error against the token bill. Stop tuning it. Spend your effort on model choice and on caching repeated context, because that is where 85%+ of the money goes.
The general rule for any agent FinOps review still holds: find the costs that bill while idle first, because nobody is watching them. On a cheap-model dev stack, that idle NAT IS your bill. On a production stack, it just tells you whether anyone forgot to clean up.
The general rule for any agent FinOps review: find the costs that bill while idle first. They are the ones nobody is watching.
The lines that are easy to forget
The three big lines are not the whole rate card. These are the ones I have seen catch teams, all from the AgentCore pricing page:
- Memory, the AgentCore feature. Short-term memory moves to usage pricing on October 6, 2026 (that is tomorrow as I write this): $1.00 per GB ingested, $0.20 per GB retrieved, $0.10 per GB-month stored. Long-term memory is $0.75 per 1,000 records/month built-in. Cheap per unit, but it is a store that grows and never sleeps, so it compounds.
- Gateway invocations. $0.005 per 1,000 tool invocations, plus $0.02 per 100 tools indexed per month. A chatty multi-tool agent makes a lot of invocations.
- Context growth across turns. This is not an AgentCore line, it is physics. Every turn resends the whole conversation, so a 20-turn task costs far more than 20 times the first turn. Caching helps on models that support it. Watch it on long sessions.
- The 8-hour session you forgot. The default runtime idle timeout and max lifetime can be set as high as 28,800 seconds, eight hours. Idle memory gets reclaimed, but a session you never closed is still a live session. Set the timeout to match your real task length.
A pre-deploy cost checklist
Before you push an AgentCore agent to production, answer these:
- [ ] v1 or v2? Short bursty sessions lean v2 (memory reclaim). Long steady sessions lean v1 (lower rate). Do not default blindly.
- [ ] Who owns the NAT gateway? On low volume it is your biggest fixed line. Tear it down between tests, or avoid the managed NAT if your tools reach AWS services via endpoints.
- [ ] What is the session timeout? Match it to the real task, not the 8-hour default.
- [ ] Did you price the model, not the runtime? Runtime was two cents in the example. The model is the lever.
- [ ] Is memory growth budgeted? Short and long-term memory bill on volume and never idle to zero.
- [ ] Cleanup for dev accounts? Fixed infrastructure keeps billing after everyone has gone home. Have a teardown.
What I actually took away
The AgentCore runtime billing is genuinely good. Per-second, CPU-to-zero on I/O wait, idle memory reclaimed on v2. For an agent that waits as much as agents do, that is the right model, and the runtime was never the line that decided the bill in any scenario I ran.
The cost does not live where the tutorials point. It lives in the model you pick, which moves the bill more than anything else, and in the fixed infrastructure that bills while the agent sleeps. Price those two first. The vCPU math is the part you can mostly ignore.
If you are building agents on AWS, do this one thing before you deploy: open Cost Explorer after a day of idle and see what your agent costs when it is doing nothing. That number is the one that surprises people, and it is the one you can design away.
What is the sneakiest idle cost you have found on an AWS agent stack? I want to hear the ones that are not on this list.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article