I tried out the newly released Amazon Bedrock AgentCore Runtime V2
This page has been translated by machine translation. View original
Introduction
On September 18, 2026, a new platform version V2 was added to Amazon Bedrock AgentCore Runtime. Since V2 restores each session from a snapshot, it affects not only startup performance but also initialization performed at module scope.
In this article, we ran the same container image under both V1 and V2 in the Tokyo region and measured cold start times by image size. We also verify how values generated at startup—such as random numbers and timestamps—are handled across different sessions.
Differences Between V1 and V2
According to the official blog, V1 pulls and extracts the container image for each new session. V2, on the other hand, restores from a snapshot at startup, so image size does not affect the startup path. This is why startup is faster.
Test Environment
- Region: ap-northeast-1 (Tokyo)
- Agent: A Flask application for arm64 packaged as a container image
- Images (all sizes after compression): three variants — base (46 MB), pad-500m (335 MB) with random data embedded that is not loaded at import time, and pad-1g (859 MB)
Measurement Method
We created a new Runtime, invoked it immediately after it reached READY, and measured the elapsed time from a client within ap-northeast-1. Six Runtimes — 3 images × V1/V2 — were created in parallel with 0.5-second offsets.
CPU Information Check
Before comparing cold start times, we checked CPU information. The agent was configured to return platform.machine() and the first processor entry from /proc/cpuinfo on the initial invoke.
The values obtained for V2 base, pad-500m, and pad-1g were all as follows:
| Item | Value |
|---|---|
| machine | aarch64 |
| CPU implementer | 0x41 |
| CPU part | 0xd40 |
| CPU architecture | 8 |
The same values were obtained for V1 base, pad-500m, and pad-1g.
Runtime Creation Time
The time from creating a new Runtime until it becomes READY. Each value is from a single measurement.
| Image | V1 Ready | V2 Ready |
|---|---|---|
| base (46MB) | ~5 seconds | ~188 seconds |
| pad-500m (335MB) | ~5 seconds | ~188 seconds |
| pad-1g (859MB) | ~5 seconds | ~204 seconds |
V2 took approximately 3 minutes (188 seconds) for base and pad-500m, and approximately 3.5 minutes (204 seconds) for pad-1g.
Cold Start Comparison: V1 vs V2
The time taken for the first invoke immediately after creating a new Runtime. Each value is from a single measurement.
| Image | Compressed Size | V1 Cold Start | V2 Cold Start |
|---|---|---|---|
| base | 46 MB | 3.4s | 2.1s |
| pad-500m | 335 MB | 5.5s | 2.2s |
| pad-1g | 859 MB | 13.6s | 1.8s |
Since V1 includes image pull and extraction in the startup path, the first response becomes slower as size increases. V2 restores from a snapshot. Even with an image padded to 859 MB using data not loaded at import time, the response time was comparable to base. Dependencies that are loaded at import time were not measured in this test.
Warm Latency
We invoked the same session five times consecutively. Each value is from a single measurement. The first call here is a separate measurement from the previous section (first invoke immediately after new Runtime creation). These values represent the case of creating a new session on an existing Runtime.
| # | V1 | V2 |
|---|---|---|
| 1st (new session on existing Runtime) | 0.611s | 1.912s |
| 2nd | 0.167s | 0.210s |
| 3rd | 0.191s | 0.177s |
| 4th | 0.151s | 0.193s |
| 5th | 0.154s | 0.180s |
For the first call, V2 took 1.912 seconds and V1 took 0.611 seconds, meaning V2 was slower on this path. From the second call onward, no significant difference was observed for this base image.
What Changes with V2 Snapshots
V2 restores each session's container from a single snapshot. Code executed at module load time (import time) will produce identical results across sessions restored from the same snapshot — meaning values are determined when the snapshot is taken. We prepared an agent that records random numbers at module scope and called it twice from separate sessions.
| Value | V1 session1 | V1 session2 | Match? | V2 session1 | V2 session2 | Match? |
|---|---|---|---|---|---|---|
| random.random() | 0.257291 | 0.026107 | ✗ | 0.314435 | 0.314435 | ✓ |
| os.urandom(8).hex() | c80e2c1c... | 6a9f8409... | ✗ | f6e46eab... | f6e46eab... | ✓ |
Even os.urandom(), which uses the OS random source, returned the same value in V2. This means that keys, tokens, and session IDs generated at module scope will be identical across all sessions. Do not place random number generation or credential initialization at module scope. They must be executed inside the handler.
The same applies to timestamps. BOOT_TIME = time.time() is fixed to the value at the time the snapshot was taken. Therefore, the difference from the invoke time reflects elapsed time since snapshot creation, not since session startup.
The following module-scope code was used for measurement:
BOOT_TIME = time.time()
STARTUP_RANDOM_FLOAT = random.random()
STARTUP_RANDOM_HEX = os.urandom(8).hex()
Summary
We confirmed that cold start performance is improved in Amazon Bedrock AgentCore Runtime V2. For configurations with large image sizes where the first response from a new Runtime has been a concern, V2 is worth considering.
On the other hand, the CPU (Graviton generation) of the execution environment was identical between V1 and V2. V2 is not intended to improve computational performance. Additionally, since values initialized at module scope are included in the snapshot, care must be taken with session-specific values and credentials. Pricing also changes from V1, so we recommend thoroughly evaluating with your own workload before switching.
