AWS's September 18, 2026 announcement is about speed. A next-generation AgentCore Runtime, elastic memory, consistent cold starts, hardware-enforced session isolation.

The number that should shape an architecture is smaller and much less quoted: fifteen minutes.

A faster cold start is an engineering result. What happens to an agent's memory when the session ends is a governance decision, and the documentation is unusually clear about it.

What this analysis can and cannot support

Three limits belong at the top.

First, everything below about Amazon Bedrock AgentCore is AWS's own published description of its own service. That is authoritative for what AWS says it built and a poor source for whether it performs as described on your workloads. No independent benchmark or third-party audit is cited here.

Second, no price, committed rate or customer outcome is asserted. The announcement points readers to a pricing page rather than stating a figure, and no customer is named for this Runtime.

Third, the questions, the comparison and the indicators are this publication's analysis. They have not been validated as a protocol.

What AWS actually announced

The September 18 post introduces the next generation of AgentCore Runtime, described as the serverless microVM compute inside AgentCore, and frames the change around two things.

Memory. AWS says the new Runtime delivers "elastic memory management that reclaims unused memory throughout the session so you pay for actual usage rather than the peak." Each session starts with a small profile, memory is allocated on demand, and unused memory is reclaimed rather than held to the end.

Cold starts. The Runtime prepares the agent environment once and snapshots it, and each new instance restores from that snapshot rather than repeating the full startup sequence. In AWS's testing, that produced a P75 cold start of 1.9 to 2.0 seconds for container images from 200 MB to 2 GB, against 5.4 to 30 seconds on the previous version.

The commercial framing is deliberately restrained. AWS promises "no pre-provisioning, scale to zero, hardware-enforced session isolation, and pay only for what you use," with lower costs and faster starts. It does not quantify the cost change.

Opting in is a field, not a migration: set platformVersion to V2 when creating or updating a runtime.

The number that decides where your architecture lives

Session isolation is the most consequential feature in the announcement, and it is also the one most likely to be read as a security footnote.

Amazon's developer guide is explicit about the lifecycle. A session ends on inactivity, with a default of 15 minutes, or on reaching a maximum lifetime, with a default of 8 hours. When it ends, the entire microVM is terminated and memory is deleted. Session state is temporary by design, and long-term context belongs in a separate memory service rather than in the session.

The guide frames that isolation as a security property: it prevents data contamination between sessions. It is also a design constraint with a bill attached.

Any agent that needs to remember something across a lunch break must write it somewhere durable. That somewhere becomes a data store with its own access rules, retention policy, audit trail and named owner. The runtime did not create that obligation. It made it impossible to ignore.

Which produces a better question than "is the session isolated?" It is: what does our agent persist, where does it land, and who can read it in ninety days?

The health check that produces a support ticket

One operational detail deserves more attention than it usually gets. The guide states that the Runtime takes its snapshot at the first healthy /ping response, and that a container must report healthy within 120 seconds.

Read those two sentences together and the failure mode is obvious. A health check that answers before initialization finishes tells the platform the agent is ready when it is not, and the snapshot then captures an agent that was never fully initialized.

This is the sort of instruction that gets skimmed in a migration review and produces a support ticket three weeks later, when a workload that passed in a demo behaves differently under real traffic for reasons nobody can immediately explain.

Six Regions, and a topology decision that expires

The September announcement lists availability in six Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Europe (Frankfurt) and Asia Pacific (Tokyo).

Regional coverage for a service like this moves faster than blog posts age. A buyer planning a deployment should confirm the current list against the service documentation rather than either a launch note or a weekly roundup, because the answer determines where the data sits, which determines whether the workload is permissible at all.

The announcement is also a reminder that AWS describes its own testing. The 1.9 to 2.0 second figure is a P75 measured on container images between 200 MB and 2 GB. It is a useful design intent and not a purchasing benchmark for your image, your dependencies or your concurrency profile.

Four questions before moving a workload to V2

  • What does one completed session cost us today? Not per token, not per call. Without a baseline measured in the units you are billed for, the promise of paying for actual usage rather than the peak cannot be tested.
  • Does anything depend on in-session memory surviving? If yes, it moves to a durable store before the runtime change, and that store needs an owner, a retention rule and an access review.
  • What does our health check report, and when? If /ping answers before initialization completes, the platform snapshots an agent that was not ready, and the first symptom will be a failed invocation.
  • Which Regions are we allowed to use? Confirm the current list from the service documentation, not from a launch post that may already be stale.

A 30-day evaluation, run as a comparison

  • Days 1 to 5. Pick one agent with real traffic and a bounded blast radius. Record current consumption, cold-start behavior and session count.
  • Days 6 to 12. Stand up the same agent on V2 in a non-production environment. Confirm Region availability before committing to a topology.
  • Days 13 to 18. Fix the health check. Report healthy only after initialization completes, and verify the timing against the 120-second window.
  • Days 19 to 25. Run both versions against the same workload and compare the consumption line rather than the rate card.
  • Days 26 to 30. Have someone who built none of it reconstruct one session from records: what the agent was asked, what it persisted, where that landed, and how long the session lived.

Four indicators worth baselining

Cost per completed session, in the units you are actually billed for. Cold-start time at the 75th percentile on your own images, not AWS's. The share of agent context that is written to a durable store with a named owner and a retention rule, rather than assumed to survive in session. And time to reconstruct one session from records, which is the number that decides whether an incident is a two-hour conversation or a two-week archaeology project.

Baseline all four before the comparison begins. None requires a vendor benchmark, and each describes your operation rather than someone else's.

What remains unestablished

  • Whether V2 lowers total cost for any specific workload. AWS states the direction and does not quantify it.
  • What the service costs, and how consumption is priced relative to the previous generation. No figure was reviewed.
  • Whether the cold-start figures hold for images outside the 200 MB to 2 GB range tested, or under concurrency AWS did not describe.
  • What controls the service offers beyond session isolation for limiting what an agent can reach. Tool-level policy and network configuration options are not characterized in this analysis, and nothing here should be read as a statement about them.
  • Whether any of these capabilities improves reliability, security or cost at any organization. Nothing here establishes an outcome.
  • Market data. None was reviewed for this edition, so no stock movements are reported.

Evidence notes and limits

The AWS What's New post dated September 18, 2026 announcing the new AgentCore Runtime is the source for the elastic memory description and the quoted phrase about paying for actual usage rather than the peak, for the snapshot-based cold-start mechanism and the tested range of a P75 cold start of 1.9 to 2.0 seconds for images from 200 MB to 2 GB against 5.4 to 30 seconds on the previous version, for the quoted list of serverless characteristics including hardware-enforced session isolation and scale to zero, for the six-Region availability list, and for the instruction to set platformVersion to V2 when creating or updating a runtime. It is AWS describing its own service.

The AWS Weekly Roundup for November 9, 2026 is cited only for the fact that the roundup covers AgentCore Runtime V2 and for its framing that most of the cost of adopting something new is the move rather than the new thing. It is a vendor summary of vendor announcements, and no figure is drawn from it.

The Amazon Bedrock AgentCore developer guide is the source for the documented session lifecycle, including the 15-minute default inactivity timeout, the 8-hour default maximum lifetime, termination of the entire microVM and deletion of memory on session end, the statement that session state is temporary and that long-term context belongs in a dedicated memory service, and the requirement that a container report healthy within 120 seconds with the snapshot taken at the first healthy response. It was read in a localized version, and the lifecycle values are stated as defaults that can be configured within documented ranges.

No pricing page, service-level agreement, independent benchmark, third-party audit or customer case study was reviewed for this edition. The reading of session isolation as an architectural obligation, the health-check failure mode, the four questions, the comparison and the four indicators are this publication's analysis. Nothing here establishes that any organization reduced cost, improved reliability or met a compliance obligation.

The advertisement above is separate from this analysis and is not a source for any claim in it.