AWS adds persistent EC2-backed runtime instances to Bedrock AgentCore for long-running agents
Sessions lasting up to 14 days and a shared file system show how agent infrastructure is splitting from the stateless serverless model.
AWS on 6 August 2026 announced runtime instances for Amazon Bedrock AgentCore, a managed EC2-backed environment in which several AI agents can run inside a single persistent session for up to 14 days. The launch was detailed in a post by Sébastien Stormacq on the AWS News Blog.
The existing AgentCore Runtime executes agents in microVMs with invocations capped at eight hours. Runtime instances are aimed at longer and heavier workloads: agents keep state across multi-step workflows and share session storage. In AWS's demonstration, a reviewer agent reads code written by a writer agent directly from a common file system rather than through API calls between them. The post suggests a lightweight orchestrator running on the microVM runtime can dispatch work to specialised worker agents on instances.
Instances run Linux on ARM64 or x86_64, and GPU-accelerated instance types are supported. Agents can be written in Python 3.11 through 3.14 with native code, or packaged as container images. The walkthrough uses a c7g.2xlarge instance with 8 vCPUs and 16 GiB of memory. Pricing is standard EC2 rates plus a management fee for AgentCore orchestration.
To use the feature, a developer first creates a capacity provider in the AgentCore console, choosing the operating system, instance type, VPC and subnets, and storage. They then create a runtime that references that provider and upload agent code as a zip file or container image marked with an @app.entrypoint decorator. Runtime instances are available in US East (Ohio and N. Virginia), US West (Oregon), Asia Pacific (Mumbai, Singapore, Sydney and Tokyo) and Europe (Frankfurt and Ireland).
Why it matters
The first wave of agent platforms borrowed the serverless model of short, stateless invocations. Vendors are now acknowledging that agents doing substantial work need long-lived state, shared scratch space and sometimes GPUs, which looks more like a server than a function. A split between a cheap orchestration layer and heavier workers is becoming the standard shape.
The first wave of agent platforms borrowed the serverless model of short, stateless invocations.
MicroVM runtime
Short-lived isolated invocations up to 8 hours; suited to lightweight orchestrator agents that dispatch work.
Runtime instance
Managed EC2 with sessions up to 14 days, shared session storage, optional GPUs; suited to heavy worker agents.
What you can learn from this
- Stateless and stateful compute solve different problems. Functions and microVMs start fast, scale to zero and are billed by the invocation, but they enforce time limits and discard local state when they end. A persistent instance keeps its file system, processes and memory alive for as long as the session runs, at the cost of paying for idle time. Time limits exist because the platform must reclaim resources, so any task longer than the limit has to either checkpoint its progress or move to a stateful tier. This is also why long tasks on stateless platforms often end up wrapped in retry loops that make failures harder to diagnose.
- The orchestrator and worker pattern separates coordination from heavy lifting. One small, cheap process decides what needs doing and hands tasks to workers with more resources. This keeps the expensive tier busy only when there is real work, and it means a crashed worker does not take the plan down with it. The same structure appears in job queues, build systems and distributed data frameworks. Agent platforms adopt it for the same reason: planning is cheap to compute, and only the execution needs serious hardware.
- A shared file system is the simplest form of inter-agent communication. Instead of defining APIs and message formats, one agent writes files and the next reads them, which is easy to inspect and debug. It works well for sequential pipelines where each stage finishes before the next begins, but concurrent writers need locking or naming conventions to avoid clobbering each other. Message queues become the better choice when many agents must coordinate in parallel.
- A capacity provider is a pool of compute described once and reused. You declare the instance type, network placement and storage, and the platform schedules workloads onto it, much like container orchestrators separate cluster definition from task definition. This lets teams change hardware, for example adding GPUs, without touching agent code. It also means networking and access control are set at the pool level, which is where security reviews should focus.
- Billing models should follow duty cycle. Per-invocation pricing suits bursty work with long gaps; per-hour instance pricing suits sustained work where the machine is busy most of the time. A management fee on top of raw compute is the cost of the platform handling scheduling, sessions and isolation for you. Choosing the wrong model is the most common way agent costs surprise a team. Measuring how many hours a day a workload is genuinely busy is the first step in choosing between them.
We teach this
How to use this in practice
- Classify three workloads on two axes. Take three tasks you would like an agent to perform and write down, for each, its expected duration and whether it needs state to survive between steps. Assign each to a stateless function tier or a persistent instance tier and note why. Add a third column for whether the task needs a GPU, since that alone can rule out the function tier. Done looks like a three-row table you could defend in a design review. Revisit it once you know each task's real duration, since estimates tend to be optimistic.
- Build a two-agent hand-off with nothing but a directory. Write a small script that generates a file into a folder, and a second script that watches the folder, reads the new file and writes a review alongside it. Run them in sequence, then try running them concurrently and observe what breaks. Done looks like a folder containing an input, an output, and a note on what convention you needed to avoid partial reads. A common fix is writing to a temporary name and renaming once the file is complete, which is worth trying here.
- Audit one long-running job for timeouts and checkpoints. Pick a script, pipeline or batch process you already run, find its maximum runtime and its timeout setting, and identify whether it can resume from partway. Done looks like a short list stating the job name, its limit, and either where it checkpoints or a one-line plan to add a checkpoint. Note whether the timeout was chosen deliberately or is simply the platform default. Time one full run so the limit is compared against a measured figure rather than a guess.
- Cost a 14-day session before you need one. Look up the on-demand hourly rate for an instance type in your region, multiply by 336 hours, and add the platform fee from the AgentCore pricing page. Compare that with what the same work would cost as a chain of short invocations. Include the cost of an idle instance waiting between steps, since that is exactly what a persistent session charges for. Done looks like two numbers side by side in a spreadsheet with the assumptions written underneath. Repeat for a GPU instance type to see how the ratio changes.
Sources
- Runtime instances: persistent compute for production AI agents on Amazon Bedrock AgentCore — AWS News Blog
Our reporting is an original summary; full coverage is at the links above.
Don't just read about it — build it.
Square 1 teaches the skills behind the headlines, with every line of your work graded by AI. Find your starting point in 3 minutes.
Get your free skill report