Bedrock AgentCore runtime instances: 14-day agent sessions

AWS made AgentCore runtime instances generally available: persistent, managed EC2 for production AI agents, with sessions that live up to 14 days instead of 8 hours. If you've been fighting a serverless timeout to keep an agent working a long job, this is the escape hatch. It also swaps a per-invocation bill for an always-on one, which is the part most teams will discover in month two.

What actually happened

Per the AWS announcement on Aug 6, runtime instances complement — not replace — AgentCore's existing serverless microVM option. The microVMs handle invocations up to 8 hours with faster startup. Runtime instances hold session state for up to 14 days.

The engineering detail is where it gets interesting. Multiple agents can run on the same host inside one session and share a filesystem — AWS's example puts a code-writer and a code-reviewer agent in the same /tmp/agentcore-session/[session-id]/ directory, so they hand work off through files instead of API calls between services. You also get direct access to the underlying OS and to GPU-accelerated instance types, neither of which the microVM sandbox gives you. Python 3.11–3.14 with native code, or bring a container. Linux ARM64 and x86_64 at launch.

Pricing is standard EC2 plus a management fee for AgentCore orchestration. Nine regions: US East (N. Virginia, Ohio), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney, Tokyo), Europe (Frankfurt, Ireland). Sessions can be stopped and restarted to avoid paying through idle time.

Why long-running agent sessions matter for your business

The honest framing: AWS just admitted that serverless is the wrong shape for a real agent. An agent doing a multi-day migration, a nightly reconciliation that spans a batch window, or a research task with a scratch directory it keeps returning to — that's a process with a working set, not a request with a response.

Three things to weigh before you move a workload.

You're back to paying for idle. Serverless agent pricing punished you for long tasks. This punishes you for gaps between them. A 14-day session on a c7g.2xlarge that thinks for forty minutes a day is a bad trade. The stop/restart control exists for exactly this — build the scheduling in on day one, not after the first invoice. If you're sizing this, run the numbers the same way you would any AI spend line item.

The shared filesystem is the feature and the risk. Agents coordinating through /tmp is fast and debuggable. It's also a shared mutable surface with no schema, no versioning, and no audit trail unless you add one. Decide who writes where before you have three agents in the directory.

Direct OS access changes your blast radius. The microVM sandbox was a security boundary you got for free. Choosing an EC2 instance means you own patching posture, egress rules, and what a confused agent can reach — the same lesson as scoping agent egress and containing sandbox escapes. Longer sessions mean more time for a compromised agent to be interesting.

For most small teams, the microVM is still the right default. Reach for runtime instances when you have a specific job that genuinely doesn't fit in eight hours — not because 14 days sounds better.

Sources: AWS What's New, AWS News Blog.