On this page · 11 sections
Summary. AWS made Amazon Bedrock AgentCore runtime instances generally available on 6 August 2026 in nine Regions, including Asia Pacific (Mumbai). Agents run on EC2 instances in your own account, billed at standard EC2 rates plus a 12% management fee, reduced to 7.8% for G-series families including the Graviton-based gr6. Sessions persist up to 14 days against the 8-hour ceiling on the default serverless microVM runtime. AWS's own example prices 1,000 three-hour modernisation jobs a month on c7g.2xlarge at $971.04, being $867 of EC2 at $0.289 an hour plus $104.04 of management fee. Run AWS's published microVM rates of $0.0895 per vCPU-hour and $0.00945 per GB-hour against that same 8 vCPU, 16 GB shape and the arithmetic points somewhere specific: an always-busy agent costs $0.8672 an hour on microVMs against $0.32368 on an instance, and the crossover sits near 24% sustained CPU utilisation. One asymmetry decides the rest. Your EC2 Savings Plans, Reserved Instances and On-Demand Capacity Reservations apply to the compute, and the management fee is always calculated on the undiscounted On-Demand rate.
What runtime instances are, precisely
AgentCore Runtime already had a compute model: managed microVMs that run an invocation for up to 8 hours with managed session storage, scaling fast and billing per second. Runtime instances are a second, complementary option under the same APIs, not a replacement.
"Runtime instances handles all of that for you while integrating with the same AgentCore APIs, identity controls, and observability you already use with AgentCore Runtime microVMs," wrote Sébastien Stormacq, principal developer advocate at AWS, in the launch post on 6 August 2026.
The shape of the thing:
- You create a capacity provider that defines the EC2 infrastructure, choosing the operating system, allowed instance types, VPC, subnets, security groups and storage. Once created, only the description can be edited.
- Multiple agents deploy into a single runtime and can share a host, each with their own dependencies and artifact types.
- Agents on the same host collaborate through a shared session file system rather than by calling each other's APIs.
- Sessions persist for up to 14 days, with session stop and restart to cut cost during idle periods.
- Linux on ARM64 and x86_64 at launch, Python 3.11 through 3.14 with native code support, and container images.
- Packaging is an
@app.entrypointdecorator plus a zip file or container image, with CrewAI, LangGraph, LlamaIndex and Strands all supported.
Available Regions at GA are US East (N. Virginia), US East (Ohio), US West (Oregon), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Frankfurt) and Europe (Ireland).
The billing model has two halves that behave differently
This is the part that changes architecture decisions, and it is stated plainly on AWS's pricing page: "Because the instances run in your account, EC2 discounts such as Savings Plans, Reserved Instances, and On-Demand Capacity Reservations (ODCRs) apply to the EC2 compute portion. The management fee is always calculated on the On-Demand rate."
Read that twice if you run a heavily committed EC2 estate. The compute half of the bill lands inside your existing commitments and inherits whatever coverage you have already bought. The fee half does not, and it never will, because it is computed off the public On-Demand price regardless of what you actually pay for the instance. The better your Savings Plan coverage, the larger a share of the total that 12% becomes.
| Cost component | Runtime instances | Runtime microVMs |
|---|---|---|
| Compute rate | Standard EC2 rate for the instance type, in your account | $0.0895 per vCPU-hour and $0.00945 per GB-hour |
| Management fee | 12% of the EC2 On-Demand price, 7.8% for G-series including gr6 | None separately stated |
| Billing granularity | Per instance-hour from boot until stop or terminate, roughly a 1-minute minimum | Per second on actual CPU and peak memory, 1-second minimum, 128 MB memory floor |
| What idle costs | The full instance rate until you stop the session | Billing spans boot, initialisation, active processing and idle until session termination |
| Commitment discounts | Savings Plans, RIs and ODCRs apply to the EC2 portion only | Not applicable |
| Session ceiling | 14 days | 8 hours |
| Storage | EBS billed separately at standard rates, including while a session is stopped | Managed session storage |
Storage and network are not folded in. Persistent EBS volumes attached to sessions bill at standard EBS rates, and that includes while a session is stopped, so "hibernate Monday night and resume Wednesday morning" saves the compute line and not the disk. Network data transfer applies at standard EC2 rates.
Working the break-even
AWS publishes a worked example for each option, but not one that compares them. So here is the comparison, built only from AWS's published rates.
Take AWS's own instance shape from its runtime instances example: c7g.2xlarge, 8 vCPU and 16 GB, at $0.289 an hour On-Demand in US East (N. Virginia).
On an instance, that hour costs the same whether the agent is thinking hard or sitting still:
EC2: $0.289 per hour
Management fee: $0.289 x 0.12 = $0.03468
Total: $0.32368 per instance-hour
On microVMs, an equivalent shape running flat out for an hour costs:
CPU: 8 vCPU x $0.0895 per vCPU-hour = $0.71600
Memory: 16 GB x $0.00945 per GB-hour = $0.15120
Total: $0.86720 per hour
A continuously busy 8 vCPU, 16 GB agent therefore costs about 2.7 times more on microVMs than on an instance. That is not an argument for moving everything, because microVMs bill actual CPU consumption and peak memory per second, and almost no agent consumes 8 vCPU continuously.
The useful question is where the crossover sits. Memory bills on peak rather than on utilisation, so treat the $0.15120 memory line as fixed and solve for the CPU fraction:
0.15120 + (u x 0.71600) = 0.32368
u = (0.32368 - 0.15120) / 0.71600
u = 0.241
Roughly 24% sustained CPU utilisation on that shape, before any Savings Plan discount. Below it, microVMs are cheaper and you keep the fast scaling. Above it, an instance is cheaper and the gap widens quickly. Apply existing EC2 commitment coverage and the crossover moves lower still, because the discount cuts the $0.289 while the fee stays pinned to the On-Demand rate.
Three assumptions are doing work here and should be checked against your own numbers: peak memory is held at 16 GB, the EC2 rate is US East (N. Virginia) On-Demand, and AWS's pricing page states no Region for the microVM per-vCPU and per-GB rates, so treat those as list rates rather than Region-specific ones.
Co-location changes the answer again. Because multiple agents share one host and one session file system, three agents on one c7g.2xlarge split that $0.32368 an hour rather than each paying it. That is the single biggest lever available, and it has no equivalent on the microVM side.
The G-series discount is worth naming
The reduced 7.8% fee on G-series families, including the Graviton-based gr6, is not a rounding difference on GPU workloads. On a hypothetical $1.00 an hour instance the fee is $0.078 against $0.120, which is $0.042 an hour, or about $367.92 a year on a continuously running instance. Multiply by a fleet and the family choice starts to matter as much as the instance size.
The supported accelerator families are listed in the developer guide rather than on the pricing page: NVIDIA g4dn, g5, g6, g6e, gr6, g6f, gr6f and g7e, plus AWS inf2 powered by Inferentia2. Choosing an unsupported accelerator family fails CreateCapacityProvider with a ValidationException that names the instance type and lists the supported families; non-accelerator instance types are unaffected.
One gap worth flagging before you build a budget on it. AWS's 7.8% sentence covers G-series families specifically. The pricing page says nothing about the fee applied to inf2, so do not assume it inherits either rate without checking your own bill.
When to use which
| Workload pattern | Use runtime instances | Use runtime microVMs |
|---|---|---|
| Session length | Multi-day workflows up to 14 days | Request-response and batch work inside 8 hours |
| Utilisation | Sustained, above roughly 24% CPU on the equivalent shape | Bursty, spiky, long idle gaps between invocations |
| Hardware needs | GPU or Inferentia acceleration, direct OS access | CPU-only workloads with no OS-level requirements |
| Topology | Several collaborating agents sharing a host and a file system | One agent per invocation, scaled horizontally |
| Existing commitments | Heavy EC2 Savings Plan or RI coverage to absorb the compute | No EC2 commitment to apply |
| Scaling behaviour | Predictable capacity you provision through a capacity provider | Fast scaling with no capacity planning |
AWS's own recommended topology is a hybrid rather than a choice: a lightweight orchestrator agent on a microVM handling API calls, task routing and result aggregation, dispatching compute-intensive work to specialist agents on instances. Code compilation, security scanning and GUI automation are the examples AWS names, and they share a profile: long-running, stateful, and needing direct OS access.
That hybrid is also the cheapest shape for most teams. The orchestrator is idle most of the time and belongs on per-second billing. The workers are busy while they run and belong on an instance you can stop when they finish.
The FinOps controls that actually matter here
Four habits keep this bill honest, and none of them are exotic.
Stop sessions rather than leaving them running. Instances bill per instance-hour from boot until stop or terminate, so an abandoned 14-day session is a 14-day bill. The 14-day ceiling is a capability, not a target, and the failure mode is a forgotten development session rather than a production workload.
Attribute cost per capacity provider. Because the instances run in your account, they show up in Cost Explorer as EC2 like anything else, which is a benefit for chargeback and a hazard for attribution. Tag capacity providers so agent compute does not disappear into a general EC2 line, and check it against the observability you already run; our guide to AgentCore production observability and scaling covers the telemetry side.
Size your commitment coverage against the compute half only. The fee never absorbs into a Savings Plan, so a coverage target calculated on the total agent bill will overshoot. The sizing method is in our AWS Savings Plans target coverage guide.
Watch EBS through stops. Persistent volumes bill at standard EBS rates while a session is stopped, so a stop-and-resume pattern across a long project accrues storage cost between the compute peaks. That is usually the right trade, but it should be in the model rather than a surprise.
Teams still on the older agent stack have a sequencing question to answer first, which our note on Bedrock Agents moving to maintenance mode and the AgentCore migration sets out, and the wider platform comparison sits in enterprise AI agent platforms across AgentCore and Gemini.
India-specific considerations
Asia Pacific (Mumbai) is in the GA Region list, which is the detail that makes this immediately relevant rather than a 2027 planning item. Indian teams running agents that touch personal data can keep the compute, the session file system and any attached EBS volumes in-country, which removes the cross-border transfer conversation from the design entirely.
That matters under the Digital Personal Data Protection Act 2023, but it matters practically too. A 14-day session with a shared file system is a persistent working copy of whatever the agent has read. Treat the session directory as a data store with a retention policy rather than as scratch space, keep EBS encryption on, and make session termination part of the data lifecycle rather than a cost optimisation you get to later.
On cost, the pattern we see in Indian engineering organisations favours instances more than the global average would suggest, because the common workload is a small number of long-running internal agents rather than a high-volume consumer surface. A handful of agents co-located on one right-sized instance, stopped outside working hours, is a materially cheaper shape than the same agents on per-second billing with idle time included. The broader discipline is in our cloud FinOps guide for Indian teams and the cross-cloud view in FinOps for AI cloud cost across AWS, Azure and GCP.
What to do this week
Pull one representative agent and measure two numbers: average CPU utilisation across the whole session including idle, and peak memory. Those two numbers, against the rates above, decide the answer for that agent and no amount of architecture discussion substitutes for them.
Then check your Savings Plan coverage. If you are already well covered on EC2, the instance option is cheaper than the raw rate comparison suggests, because only the fee sits outside the commitment.
Finally, look at how many agents you actually run. If the answer is three or four long-lived agents, co-locating them on one capacity provider is the largest single saving available, and it is a deployment change rather than a rewrite.
The real cost here is rarely the compute rate. It is the session you forgot to stop.
How eCorpIT can help
eCorpIT builds and runs production agent platforms on AWS, covering capacity provider design, microVM and instance placement, session lifecycle controls, and the cost attribution model that keeps agent compute visible in your EC2 bill. Our senior engineering teams work to CMMI Level 5 process discipline and ISO 27001:2022 controls, and we design applications aligned with DPDP requirements where personal data passes through an agent session. For a costed placement review against your own utilisation data, contact us.
FAQ
References
Last updated: 14 August 2026.
