AgentCore Runtime V2 is the release that finally makes serverless agents feel like serverless functions instead of a container boot you pay for in patience. On September 18, 2026 AWS made the new runtime generally available in Amazon Bedrock AgentCore, and the headline is simple: snapshot-based starts, memory that grows and shrinks with the agent, and a P75 cold start around two seconds whether your image is 200 MB or 2 GB. Let’s open the hood.
What AgentCore Runtime V2 actually changes
The original runtime (now effectively V1) already gave you a serverless microVM per session with hardware-enforced isolation and scale-to-zero. What it did not give you was a fast start. Every new session meant pulling the container, booting it, and running your init code: importing the agent framework, loading tool definitions, warming SDK clients. AWS’s own numbers in the launch deep dive put V1 cold starts at roughly 5.4 to 30 seconds depending on image size. Thirty seconds is not a cold start. That’s a coffee break.
V2 keeps the same programming model and the same isolation story, and changes three things underneath:
- Snapshot-based start. Container initialization runs once, the resulting microVM state is captured, and every new instance restores from that snapshot instead of re-running init.
- Elastic memory. Memory is paged into the microVM on demand and reclaimed when the instance goes cold, rather than being sized for the worst case up front.
- A different billing meter. You pay for memory actually loaded, not the peak high-water mark.
You still get scale-to-zero, no pre-provisioning, and a dedicated microVM per session. Nothing about the isolation model is relaxed to buy the speed.
The snapshot lifecycle, step by step
When you create or update a runtime with V2, AgentCore takes your container image, boots it, and lets your initialization code run to completion. That’s the moment it captures the snapshot. From then on, a new session does not start a container from scratch; it restores the captured state into a fresh microVM and your handler is ready to take the request.
The clever part is what gets left out. The snapshot is stripped of caches before it is stored, so its size stays roughly flat as your image grows. That’s why the P75 cold-start numbers barely move across a 10x range in image size: AWS reports about 1.9 to 2.0 seconds for images between 200 MB and 2 GB. On V1, image size was the dominant variable. On V2 it mostly stops mattering, which is great news for anyone who shipped a fat image with half of PyPI inside it.
Once restored, agent code execution itself is quick. In AWS’s testing, the agent code path ran at about 34 ms P75. The model call will dwarf that, but it means the platform is no longer the slow part of the request.
If you’ve used Lambda SnapStart, the mental model is familiar: init once, freeze, restore many times. The same cautions apply. Anything your init code does that should be unique per instance (random seeds, temporary credentials, open network connections) gets frozen into the snapshot and shared by every restore. The migration piece later today covers that in detail; for now, just know the snapshot is taken after init, not before.
Elastic memory: paging in, reclaiming out
Classic container sizing makes you pick a memory number big enough for the worst request you’ll ever see. Agents are terrible at this, because their footprint depends on what the model decides to do: a quick lookup uses almost nothing, a long tool-calling loop that loads a document set uses a lot.
With AgentCore Runtime V2, memory pages are loaded into the microVM when your code touches them and reclaimed when the instance is cold. The practical effect is that a restored instance starts small, grows while it works, and gives memory back instead of sitting on a peak allocation for the life of the session.
What changes on the bill
Here’s the part your FinOps team will ask about. V1 billed memory against the peak you reserved. V2 bills memory actually loaded. The per-GB rate is higher on V2, but the footprint is smaller, and AWS’s position is that for most agents the bill goes down. That “most” is doing real work: an agent that sits at a high, steady memory footprint for the entire session could see less benefit, since it pays the higher rate on nearly the same amount of memory. Check current rates on the AgentCore pricing page and model your own workload before you promise anyone a number.
AWS has also put a few items on the public roadmap: committed baseline pricing, x86 microVMs, session suspend and resume, and scoped identity. None of those are available yet, so don’t design around them.
Opting in with platformVersion
V2 is opt-in. You set platformVersion to V2 when you create or update an agent runtime. The runtime platform versions section of the developer guide is the source of truth. The cleanest way to drive it from the CLI is a JSON input file, which keeps the long nested parameters readable:
{
"agentRuntimeName": "support_agent",
"agentRuntimeArtifact": {
"containerConfiguration": {
"containerUri": "123456789012.dkr.ecr.us-west-2.amazonaws.com/support-agent:1.4.0"
}
},
"roleArn": "arn:aws:iam::123456789012:role/AgentCoreRuntimeRole",
"networkConfiguration": { "networkMode": "PUBLIC" },
"protocolConfiguration": { "serverProtocol": "HTTP" },
"platformVersion": "V2"
}aws bedrock-agentcore-control create-agent-runtime \
--region us-west-2 \
--cli-input-json file://runtime-v2.jsonFor an existing runtime, the same field goes into update-agent-runtime alongside the runtime ID. Updates produce a new runtime version, which matters for rollback:
aws bedrock-agentcore-control update-agent-runtime \
--region us-west-2 \
--agent-runtime-id support_agent-AbCdEf1234 \
--cli-input-json file://runtime-v2-update.jsonIn the SDK it’s the same shape: pass platformVersion="V2" to create_agent_runtime or update_agent_runtime on the bedrock-agentcore-control client in boto3. Invocation does not change at all; invoke-agent-runtime on the data plane works exactly as before, so callers never know you switched. Full parameter references live in the create-agent-runtime CLI reference.
Regions and platform constraints
At launch, V2 is available in us-east-1, us-east-2, us-west-2, eu-west-1, and ap-northeast-1. The x86 microVM item on the roadmap is a hint worth taking: build your images for arm64, as you already should for AgentCore Runtime, and push them to Amazon ECR in the same Region.
What this means for how you build agents
A few engineering conclusions fall out of the architecture:
- Eager init is now cheap. Work done at init is paid once at snapshot time, not per session. Loading your framework, tool schemas, and prompt templates up front becomes the right default.
- Per-instance state must be lazy. Anything that must be unique or fresh per session belongs in the request path or behind a lazy accessor, not at module import.
- Image size stops being your latency problem. Still trim it for build and security reasons, but you no longer need to sacrifice a dependency to shave seconds off cold starts.
- Measure, don’t guess. Use Amazon CloudWatch and the AgentCore observability views to compare cold and warm session latency before and after the switch.
Frameworks don’t care about any of this. A Strands Agents app wrapped with the AgentCore runtime SDK runs unchanged on V2, and so does anything else that speaks the runtime’s HTTP contract. The work is in what your init code does, not in which framework you picked.
If you’ve been running agents on ECS or EKS because AgentCore’s cold starts were too painful for interactive traffic, V2 removes the main argument. Two seconds P75 on a fresh session, scale-to-zero, and per-session isolation is a very different trade than it was a month ago. Start with one non-critical agent, flip platformVersion, and look at the numbers yourself. More detail lives in the AgentCore documentation.
At Enkompass (enkompass.net), this is our home turf. We build event-driven, serverless systems that scale to zero and bill like it, and AgentCore agents are now firmly on that list. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.