AgentCore Runtime Instances [What It Changes]

TL;DR

• AgentCore Runtime Instances are Amazon Bedrock AgentCore's managed EC2 compute type: your agents run on dedicated instances in your AWS account, and AWS handles provisioning, patching, scaling, and teardown.

• As of August 6, 2026, a Runtime Instance session can stay up for 14 days, versus the 8-hour ceiling on the default microVM runtime.

• You pick GPU, memory, or compute families through a capacity provider, then attach agents without rewriting how you deploy or invoke them.

• Keep short chat-style agents on microVMs; park multi-day shipment, inventory, and document jobs on instances, and stop the session when the backlog is clear.

Key Takeaways

• The 8-hour microVM wall is the constraint that broke: overnight reconcilers, multi-day document stacks, and GPU jobs no longer have to checkpoint or die mid-run.

• A capacity provider is the contract for instance type, VPC, storage, and IAM; AgentCore launches Amazon EC2 managed instances in your account from that template.

• Several agents can share one host and one filesystem, so a writer, reviewer, and tester can work a folder of bills of lading without calling each other over the network.

• Billing is EC2 in your account plus a management fee calculated on the On-Demand price; Savings Plans cut the compute line, not the fee.

• Small fleets should mix topologies: daytime dispatch chat on microVMs, weekend POD and ELD exception jobs on instances.

What AgentCore Runtime Instances actually are

AgentCore Runtime Instances are a compute option inside Amazon Bedrock AgentCore that runs AI agents on dedicated Amazon EC2 instances in your own account, with AgentCore handling setup, patching, scaling, and lifecycle, for sessions that last up to 14 days.

That sentence is the whole product. It is not a new chatbot, and it is not a replacement for the serverless microVMs AgentCore already shipped. It is a second lane for agents that have to stay alive through a backlog that does not fit in an 8-hour box.

A 2-truck HVAC shop does not care about GPU families. It cares that the weekend invoice pile is still half-matched when Monday dispatch starts. A 10-person marketing agency cares that a render-and-review crew can share a working folder across two nights without someone babysitting a virtual machine. A solo-run clinic cares that a chart-coding agent can keep a local workspace of scanned PDFs through a long holiday weekend. The vendor signal is enterprise AWS. The operational fact is the same for a small shop: if the agent dies at hour eight, a human finishes the stack.

Logistics teams feel it first. Proof-of-delivery images, bills of lading, and electronic logging device files do not arrive in a tidy 60-second chat. They arrive in overnight dumps. The state of logistics automation is already a stack of TMS, ELD, and document tools; the missing piece was an agent that could sit on that stack for more than one shift.

What AWS shipped on August 6, 2026

On August 6, 2026, AWS announced that AgentCore runtime instances are generally available. You create a capacity provider that names the EC2 instance types your agents need — GPU-accelerated, memory-optimized, or compute-optimized — then attach agents to it from the console, CLI, SDKs, or APIs.

According to Amazon Web Services, runtime instances support long-running agent sessions of up to 14 days, while the default serverless microVM runtime is designed for sessions of up to 8 hours. Runtime instance sessions last 14 days. That is the number that changes the overnight job.

The AWS News Blog post by Sébastien Stormacq fills in the packaging: Linux on ARM64 and x86_64, Python 3.11 through 3.14 plus container images, a @app.entrypoint decorator, and a zip file or container. Frameworks named in that post are CrewAI, LangGraph, LlamaIndex, and Strands. Agents on the same host can call each other as tools and share a session directory. You can stop a session Monday night and resume Wednesday with the workspace intact.

This sits on top of AgentCore itself. The July 16, 2025 preview post introduced Runtime, Memory, Observability, Identity, Gateway, Browser, and Code Interpreter as pieces you can use together or alone. AgentCore became generally available on October 13, 2025, adding VPC, PrivateLink, CloudFormation, resource tagging, and Agent-to-Agent protocol support on Runtime, in nine Regions. Runtime Instances are the 2026 follow-on for teams that outgrew the 8-hour window.

InfoQ's August 19, 2026 write-up treats the launch as persistent compute for multi-agent collaboration, not a replacement for microVMs. InfoQ's July 2025 launch coverage had already flagged the original Runtime's 8-hour long-running path. The new option is the second compute type under the same APIs.

How the mechanism works in plain language

Think of a capacity provider as a reusable recipe. The AgentCore Instances developer guide says it names the operating system, allowed instance types, VPC and subnets, storage volumes, and IAM roles. AgentCore validates it (CREATING, then READY, or CREATE_FAILED). After create, only the description can be edited; other changes mean you duplicate the provider.

When you create an agent runtime you pick a compute type. Choosing Instances binds that runtime to a capacity provider. You cannot change the compute type later. A session is one isolated EC2 managed instance created from that provider, keyed by a runtimeSessionId you send on invoke. The first call with a new ID provisions the instance (slow). Later calls with the same ID reuse it. When two runtimes share a provider and the same session ID, both agents land on the same box and share a filesystem.

A session runs at most 14 days. At that cap, AgentCore stops the instance but keeps the persistent volumes. Invoke again with the same session ID and AgentCore attaches those volumes to a new instance, which may be on a patched machine image. Delete the session and the volumes go too. Delete the capacity provider and every associated session and volume goes with it.

That is different from the microVM model in the AgentCore overview, where one runtime hosts one agent in a fast-starting sandbox. The comparison table in the Instances guide is blunt: microVMs for lightweight API-driven work that finishes in hours; Instances for long-running, stateful, or collaborative work that needs GPUs or a multi-agent host. MicroVMs support PUBLIC or VPC networking; Instances are VPC-only. MicroVMs have no GPU path; Instances support NVIDIA families g4dn, g5, g6, g6e, gr6, g6f, gr6f, and g7e, plus AWS inf2 (Inferentia2). AgentCore installs GPU drivers, so a standard CUDA image does not have to bundle them.

Amazon EC2 instance types still decide the hardware: general purpose, compute optimized, memory optimized, accelerated computing, storage optimized, HPC. The capacity provider is how you name which of those families AgentCore is allowed to launch.

For the older async path on microVMs, the long-running agents guide is still in force: a /ping of HealthyBusy keeps a session alive; an idle Healthy session is terminated after 15 minutes. Runtime Instances do not replace that ping contract for microVMs. They replace the need to fake a 14-day job as a chain of 8-hour sandboxes.

Enkompass's August 13, 2026 engineering guide walks the same primitives — capacity provider, session TTL, stop and restart — and argues most organizations will run both compute types. That matches AWS's own hybrid sketch: a lightweight orchestrator on microVMs dispatching long work to instance-backed workers.

Why this shipped now

The constraint that broke is session length plus hardware choice. AgentCore Runtime already solved packaging, identity, and observability. It did not solve "this job is still chewing POD images at hour nine" or "this worker needs a GPU in our VPC." Teams were quietly running side fleets of EC2 to cover those agents, which is the opposite of a managed runtime.

AWS Lambda still times out at 900 seconds (15 minutes), with a 3-second default. Lambda was never the overnight reconcilers' home. MicroVMs stretched that to 8 hours. Runtime Instances stretch it to 14 days and add GPUs, shared disks, and your existing EC2 commitments.

Tooling around agents also matured enough to use the extra time. The Model Context Protocol is the USB-C port for connecting agents to files, databases, and tools. AgentCore Gateway already turns APIs and Lambda functions into MCP tools. LangGraph persists memory across turns. LlamaIndex's document stack exists to turn messy scans into structured context. None of that helps if the process hosting the agent is gone.

Microsoft Foundry hosted agents show the same industry move: per-session VM sandboxes, persistent $HOME and /files, idle timeout configurable from 5 through 60 minutes (15-minute default), and permanent delete after 30 days of inactivity. AWS's 14-day cap is a different number on the same idea — keep the workspace, recycle the machine.

What it changes for a small fleet

Property-carrying work already runs on a clock. According to the Federal Motor Carrier Safety Administration hours-of-service summary, property-carrying drivers may drive a maximum of 11 hours after 10 consecutive hours off duty. The same page sets a 14-hour on-duty window, a 30-minute break after 8 cumulative driving hours, 60/70-hour limits across 7/8 days, and a 150 air-mile short-haul exception.

Put those next to an 8-hour agent. A legal driving window is 14 hours. A microVM agent dies at 8. The overnight team that matches ELD status, fuel, and delivery photos to the TMS is doing a job that looks more like a 14-hour window than a chat turn. The ELD rule did not change basic HOS; it made the record automatic and transferable. Agents that read those records still have to finish.

That is why a 6-truck regional carrier should care even if it will never open the AgentCore console this quarter. If you already compare ELD hardware for small fleets and weigh AscendTMS against McLeod, the new question is which overnight jobs are still being cut off. Shipment-record recon, inventory scans, and document stacks are the three the AWS announcement itself named as the kind of work that needs more than a short sandbox.

The Bureau of Transportation Statistics Freight Analysis Framework estimates U.S. freight flows across 42 commodity types for a 2022 base year, by origin, destination, and mode. That is a lot of rows. An agent that is supposed to walk a commodity slice, flag mismatches, and write exceptions cannot be designed as a 60-second function. It can be designed as a 14-day session with a shared folder of working files.

Teams already routing bills of lading through US Tech Automations workflows can treat Runtime Instances as a compute swap, not a rebuild: same tools, longer worker. A small fleet already matching ELD exceptions inside US Tech Automations can park the overnight reconcilers on instances and keep the daytime chat agents on microVMs.

Timeline and sourced figures

Sources: AWS News Blog, Jul 16, 2025; AWS What's New, Oct 13, 2025; AWS What's New, Aug 6, 2026.

Sources: AgentCore Instances guide; long-running agents guide; AgentCore pricing.

Source: Amazon Bedrock AgentCore Pricing, Runtime instances example.

Sources: FMCSA HOS summary; AWS What's New, Aug 6, 2026; Lambda timeout docs.

USTA analysis: how much longer is one session?

This block uses only two sourced inputs from AWS: a 14-day instance session and an 8-hour microVM session.

• Input A: 14 days (AWS What's New, August 6, 2026; Instances developer guide).

• Input B: 8 hours (same AWS pages).

• Convert A to hours: 14 × 24 = 336 hours.

• Ratio: 336 ÷ 8 = 42.

A single AgentCore Runtime Instances session can last 42 times as long as a single microVM session before AgentCore forces a stop. That is not 42 times the throughput, and it is not 42 times the bill. It is the stretch of one continuous workspace. A 10-hour overnight POD match that used to require a checkpoint-and-resume layer now fits inside one session with margin. A weekend inventory walk that used to be three glued-together 8-hour runs can be one session you stop Sunday night.

The cost side of the same AWS example is public: AWS prices 1,000 jobs at $971.04. According to the AgentCore pricing page, that figure is 1,000 three-hour jobs on c7g.2xlarge at $0.289 an hour plus a 12% management fee. MicroVM sessions still cap at 8 hours. eCorpIT's August 14, 2026 cost note takes those same list rates and puts the utilisation crossover near 24% sustained CPU on that 8 vCPU / 16 GB shape, before Savings Plans. We are not restating 24% as an AWS number; it is eCorpIT's arithmetic on AWS's published rates.

What it costs, and what it does not

AgentCore pricing splits Runtime into two compute types. microVMs bill actual CPU and peak memory per second, with a 1-second minimum and a 128 MB memory floor. AWS says agentic workloads typically spend 30–70% of time in I/O wait, and CPU during that wait is not billed if nothing else is running. Instances bill the EC2 instance from boot until stop or terminate, with about a 1-minute minimum, plus a management fee that is a percentage of the public On-Demand price. Savings Plans, Reserved Instances, and On-Demand Capacity Reservations apply to the EC2 line, not the fee. EBS volumes bill at standard EBS rates even while a session is stopped. Network is standard EC2 transfer.

G-series families, including Graviton-based gr6, take a reduced 7.8% management fee. The pricing page does not state an inf2 fee, so do not assume 7.8% or 12% for Inferentia without reading your bill.

The AgentCore product page points at a Signal65 lab summary commissioned around AgentCore (not Runtime Instances specifically). According to Signal65, engineers spent 75% less time on infrastructure and integrations versus a custom stack, with 2.1× faster end-to-end development and 5.2× faster cloud deployment across three sample agents. That is a development-time study, not a 14-day session study. Keep it in that box.

Four Signals filed the Stormacq post as a major infrastructure launch for agent orchestration. Useful as a timestamp, not as a benchmark.

Honest limits

Runtime Instances do not make an agent correct. They make it possible for an incorrect agent to run for 14 days. A 14-day session with a shared filesystem is a working copy of whatever the agent read: rate confirmations, driver names, consignee addresses. Treat that directory as a data store with a retention rule, not as scratch.

You do not SSH in and patch these boxes. They are EC2 managed instances AgentCore operates in your account. They may be hidden from default EC2 list views and still bill you. First invocation of a new session includes provisioning delay. Compute type is sticky. Capacity provider config is mostly immutable. GPU sharing is all-agents-on-the-box, not per-agent isolation of the accelerator.

According to NIST, the AI Risk Management Framework 1.0 was released in January 2023 as a voluntary, cross-sector tool for trustworthy AI. The companion NIST AI 600-1 generative AI profile (July 2024) is explicit that generative systems create or worsen risks around data, human-AI interaction, and long-running misuse. A 14-day unattended worker is a longer window for those risks, not a shorter one. Map, measure, and manage still apply. The NIST AI 100-1 PDF frames AI systems as socio-technical; a logistics agent that writes exceptions into a TMS is exactly that.

Microsoft's hosted-agent idle path is a reminder that "persistent" is not "infinite." According to Microsoft, a hosted-agent session is permanently deleted after 30 days of inactivity. AWS's 14-day cap is a hard lifetime on one instance; volumes can outlive it if you re-invoke. Neither vendor is offering a forever process.

CrewAI and LangGraph still need human-in-the-loop on anything that spends money or moves a truck. LlamaIndex still needs a clean parse. Strands still needs hooks if you want a write blocked. Runtime Instances host that code. They do not replace it.

How to adopt this without a rebuild

Do not migrate every agent. Put request-response dispatch, quoting chat, and "where is my shipment" on microVMs. Put the jobs that already fail at hour eight — POD matching, inventory walks, certificate packs, work-instruction acknowledgement backfills — on a capacity provider.

If you already collect supplier certificates or work-instruction acknowledgements in manufacturing-adjacent logistics (certificate of analysis collection, work-instruction acknowledgement, changeover checklist tracking), the pattern is the same: a folder of files, several specialists, a clock longer than a shift. Co-locate those specialists on one instance. Stop the session when the pack is closed so you are not paying 14 days of EC2 for a 6-hour job.

Tag the capacity provider so the EC2 line does not vanish into general compute. Watch EBS on stopped sessions. Size Savings Plan coverage against the compute half only. If those jobs already live in US Tech Automations, the next step is attaching a longer-lived worker, not rewriting the workflow.

The public front door for that kind of workflow map is US Tech Automations. The product path for agentic workers is the platform link at the end of this page.

Signal vs Speculation

Demonstrated fact (sourced): As of August 6, 2026, AWS has generally available AgentCore Runtime Instances. Sessions last up to 14 days. microVMs remain the default at up to 8 hours. Compute is EC2 in your account plus a management fee on the On-Demand price (12%, or 7.8% on G-series). Nine Regions are in the GA list. Capacity providers, shared filesystems, GPU families, stop/restart, and sticky compute type are in the developer guide. FMCSA still runs 11-hour driving / 14-hour windows. NIST's AI RMF 1.0 (January 2023) and AI 600-1 (July 2024) are the voluntary risk frame. Microsoft hosted agents persist session state and delete after 30 idle days.

Our read (12–36 months, small and mid-size businesses): If the 8-hour wall was the reason overnight reconcilers stayed human, mixed topologies will become the default for any shop that already has an AWS account and a document backlog. The orchestrator stays on microVMs because it is bursty. The worker moves to instances because it is stateful. We do not expect a 2-truck HVAC shop to create a GPU capacity provider. We do expect 10- to 50-truck fleets, 3PL document teams, and warehouse inventory groups to try one instance-backed job in the next year, then stop it when the folder is clean.

Our read on cost: If Savings Plan coverage on a fleet is already high, the 12% fee becomes a larger share of the agent bill, which will push teams to co-locate several agents on one host and to treat 14 days as a ceiling, not a target. If utilisation on the equivalent shape stays well under eCorpIT's ~24% line, microVMs remain cheaper and should stay the default.

Our read on risk: Longer unattended sessions will force the NIST MAP/MEASURE steps into logistics SOPs — who can invoke, what the shared folder may hold, when the session is deleted. Vendors will not do that for a 6-truck shop. The shop will have to name a person.

Not a forecast we will defend: that Runtime Instances replace TMS products, ELD devices, or human dispatch. They host workers that sit next to those systems.

Glossary

• AgentCore Runtime Instances: AgentCore compute type that runs agents on AWS-managed EC2 instances in your account for up to 14 days.

• Capacity provider: Reusable template for instance types, OS, VPC, storage, and IAM that AgentCore uses to launch those instances.

• microVM: Default AgentCore serverless sandbox; fast start, one agent per session, up to 8 hours.

• Session / runtimeSessionId: Isolated instance (or microVM) plus its persistent volumes, keyed by an ID you pass on invoke.

• Management fee: Extra percentage of EC2 On-Demand charged on Instances; not covered by Savings Plans.

• HealthyBusy: Ping status that keeps a microVM session alive while background work runs; idle Healthy sessions die after 15 minutes.

• Persistent volume: EBS disk attached to an instance session that survives stop and re-attach, and bills while stopped.

• Shared session directory: Filesystem several co-located agents can read and write instead of calling each other's APIs.

FAQ

What are AgentCore Runtime Instances?

They are Amazon Bedrock AgentCore's managed-EC2 compute type for production agents that need longer sessions, GPUs, or several agents on one host. AWS announced general availability on August 6, 2026, as a complement to microVMs, not a replacement.

How long can a Runtime Instance session run?

It can run up to 14 days, after which AgentCore stops the instance and keeps the volumes unless you delete the session. Re-invoke with the same runtimeSessionId to attach those volumes to a new instance.

Should a small trucking fleet turn off microVMs?

No. Keep short, bursty agents — tracking chat, quote lookups, exception pings — on microVMs, which bill per second and start fast. Use instances for the overnight reconcilers that currently die at 8 hours.

What does the 12% management fee apply to?

It is a percentage of the public EC2 On-Demand price for the instance, billed on top of your EC2 charges. Savings Plans and Reserved Instances cut the EC2 line only. G-series families, including gr6, are listed at 7.8%.

Can several agents share one instance?

Yes. Two runtimes that share a capacity provider and the same runtimeSessionId land on the same EC2 host and share a filesystem. That is the pattern AWS used for a code writer and a code reviewer in the launch blog.

What happens to files when you stop a session?

Configured EBS volumes remain and keep billing at standard EBS rates. The instance does not. Delete the session (or the capacity provider) when you want the disk gone.

How does this relate to hours-of-service rules?

It does not change FMCSA rules. It changes whether an agent reading ELD and TMS records can stay up through a 14-hour on-duty window instead of dying at 8 hours.

What to do next

If you have one job that still fails because the sandbox ends — a POD folder, an inventory CSV, a certificate pack — that is the candidate. Map it as a worker with a session ID, a stop step, and a delete step. Leave the chat agents where they are.

See how agentic workflows host that longer-lived worker on the same pipeline you already use for documents and exceptions, then open the agentic workflows platform when you are ready to attach compute rather than rebuild the flow.