I tried out the newly released Amazon Bedrock AgentCore Runtime V2
This page has been translated by machine translation. View original
Introduction
A new platform version V2 has been 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, I ran the same container image under both V1 and V2 in the Tokyo region and measured cold start times by image size. I 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, 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
I 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.
Checking CPU Information
Before comparing cold start times, I checked CPU information. The agent is 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 observed for V1 base, pad-500m, and pad-1g.
Runtime Creation Time
The time from creating a new Runtime until it reaches 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.
Comparing Cold Start Times Between V1 and 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 initial response slows down as image size increases. V2 restores from a snapshot. Even with an image padded to 859 MB with data not loaded at import time, the response time was comparable to base. I did not measure the impact of dependencies that are loaded at import time.
Warm Latency
I invoked the same session five times consecutively. Each value is from a single measurement. The first call is a separate measurement from the previous section (the first invoke immediately after creating a new Runtime). These values represent a new session created against an existing Runtime.
| # | V1 | V2 |
|---|---|---|
| 1st (new session to 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 with the base image used in this test.
What Changes with V2 Snapshots
V2 restores each session's container from a single snapshot. The results of code executed at module load time (import time) will be identical across sessions restored from the same snapshot — in other words, values are determined when the snapshot is taken. I 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. It 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
I was able to confirm that cold starts are improved in Amazon Bedrock AgentCore Runtime V2. For configurations with large image sizes where the initial response time of a new Runtime is a concern, V2 is worth considering.
On the other hand, the CPU (Graviton generation) in the execution environment was identical between V1 and V2. V2 is not intended to improve computational performance. Also, since the snapshot contains values initialized at module scope, care must be taken when handling session-specific values and credentials. Billing also changes from V1, so I recommend thoroughly evaluating V2 with your own workload before switching.
