はじめに
2026年9月19日、Amazon Bedrock AgentCore に新しい Runtime が登場しました。
What's New では、Amazon Bedrock AgentCore のサーバーレス microVM コンピュートの新しい世代として案内されています。
公式ドキュメント上の名前は AgentCore Runtime V2 で、従来の microVM ベースの Runtime を V1 と呼び、Runtime ごとに platformVersion で切り替えます。
この記事では、What's New、Developer Guide、料金ページを読んで、V1 から何が変わったのかを整理します。
扱うのは次の4点です。
- コールドスタートとメモリ課金の変更点
- 有効化の手順
- 料金の単価の違い
- コードの書き方と運用で変わる点
なお、実際に V2 の Runtime を作って動かしてはいません。
公式の記載にもとづく整理で、実測値は含みません。
V2 で何が変わったのか
V2 は、従来のサーバーレス microVM 型 Runtime の次世代版です。
ゼロスケール、ハードウェアによるセッション分離、従量課金といった特性は V1 と同じで、変わったのは次の2点です。
-
スナップショットからの復元：環境を一度だけ準備してスナップショットを取り、新しいインスタンスはそこから復元して起動します。
V1 は起動のたびに環境を初期化していました -
メモリの動的管理：必要になったときにメモリを追加で割り当て、使われなくなった分を回収します。
V1 はセッション終了までメモリを確保したままでした
公式が示しているコールドスタートの数値は、コンテナイメージ 200 MB から 2 GB の場合の P75 で次のとおりです。
- V1：5.4〜30 秒
- V2：1.9〜2.0 秒
V2 ではイメージサイズや同時実行数に依存せず、コールドスタートが一定になるとされています。
2026年8月に GA した Instances(Amazon EC2 上で最長14日のセッションを動かすコンピュートタイプ)は別系統で、V2 はサーバーレス microVM 側の刷新です。
V1 と V2 の流れの違い
コールドスタートからアイドルまでの流れを、V1 と V2 で並べると次のようになります。
V2 では、Runtime の作成や更新の時点でスナップショットを取るぶん、作成と更新に数分かかります。
V1 は数秒で READY になります。
その代わり、セッションごとのコールドスタートが短くなり、アイドル中のメモリは 120 秒後に回収されます。
V2 を有効化する
platformVersion は Runtime ごとに指定します。
作成時に省略すると V1、更新時に省略すると現在の設定のままです。
コンソールでは Runtime の作成画面で Platform version に V2 を選びます。
CLI の場合は次のとおりです。
aws bedrock-agentcore-control create-agent-runtime \
--agent-runtime-name "my-agent" \
--role-arn "arn:aws:iam::111122223333:role/AgentExecutionRole" \
--agent-runtime-artifact '{
"containerConfiguration": {
"containerUri": "111122223333.dkr.ecr.us-west-2.amazonaws.com/my-agent:latest"
}
}' \
--network-configuration '{"networkMode": "PUBLIC"}' \
--platform-version V2
作成のレスポンスには platformVersion が含まれません。
設定を確認するには get-agent-runtime を呼びます。
aws bedrock-agentcore-control get-agent-runtime \
--agent-runtime-id my-agent-ABCDE12345 \
--query platformVersion
提供リージョンは次の5つで、東京も含まれます。
- us-east-1
- us-east-2
- us-west-2
- eu-west-1
- ap-northeast-1
V1 と V2 の料金単価
料金ページには V1 と V2 の単価が並んでいます。
| 項目 | V1 | V2(従量) | V2 のコミット済みベースライン |
|---|---|---|---|
| vCPU(1時間あたり) | $0.0895 | $0.1276 | $0.0997 |
| メモリ(1GBあたり1時間) | $0.00945 | $0.0169 | $0.0132 |
コミット済みベースラインは2026年10月に始まる予定です。
課金は1秒単位で、最小は1秒、メモリは最小 128 MB です。
これは V1 と共通です。
単価だけを見ると、V2 は vCPU が約1.43倍、メモリが約1.79倍です。
V2 が安くなるかどうかは、使用量がどれだけ減るかで決まります。
メモリについて単純に計算すると、V1 で確保していたメモリに対して、V2 で課金されるメモリの平均が約56%以下になれば、メモリ料金は V1 と同等以下になります。
アイドルの時間が長いエージェントや、メモリ使用量が大きく上下するエージェントは、この条件を満たしやすいと考えられます。
一方、メモリを使い切り続けるエージェントは割高になる可能性があります。
CPU については、V2 の単価が上がっており、公式はプラットフォームのオーバーヘッドも減らすと説明しています。
このオーバーヘッドの削減幅は公開情報からは分からないため、実際のコストは同じエージェントを V1 と V2 で動かして請求を比べるのが確実です。
コードの書き方が変わる
起動時に行った処理はスナップショットに含まれ、復元された全インスタンスで同じ値になります。
判断の基準は次の1つです。
デプロイし直さない限り変わらない値は起動時に計算する。リクエストごとに変わる値や期限のある値は handler 内で計算する。
スナップショットは AgentCore Runtime のバージョンごとに1つ取られ、そのバージョンが存在する間は使い回されます。
起動時に行ってよい処理は、依存ライブラリの import、モデルの重みの読み込み、デプロイバンドル内の静的設定の読み込み、クライアントの生成とウォームアップ呼び出しです。
AgentCore SDK では app.run() より前(モジュールスコープ)で行い、120 秒以内に終わらせます。
handler 内で行う必要がある処理は次のとおりです。
| やりたいこと | handler 内で行う理由 |
|---|---|
| 乱数、ID、トークンの生成 | 起動時に取得した値は全インスタンスで同一になる |
| 現在時刻の取得 | 起動時の時刻はスナップショット時点で固定される |
| 経過時間の計測 |
time.monotonic() は復元をまたいで進まず、誤った値がエラーなしで出る |
| 認証情報の利用 | 起動時に読み込んだ認証情報は、インスタンス起動時に期限切れの可能性がある |
| インスタンスの識別 | 復元された全インスタンスで hostname は localhost、PID は 1 になる |
書き方の例は次のとおりです(build_client などは説明用の仮の関数です)。
import os, time
from bedrock_agentcore.runtime import BedrockAgentCoreApp
# 起動時に一度だけ実行され、スナップショットに含まれる
client = build_client()
warm_up(client)
app = BedrockAgentCoreApp()
@app.entrypoint
def invoke(payload):
creds = get_credentials() # 期限切れなら更新する
request_id = os.urandom(16).hex() # リクエストごとに一意
now = time.time() # スナップショット時点ではなく現在時刻
...
app.run() # ポート 8080 で待ち受けを始め、最初の healthy な /ping でスナップショットが取られる
ほかにも、次の点が公式ドキュメントに書かれています。
- Gateway から取得したツールカタログを起動時にキャッシュすると、ツール構成がスナップショット時点で固定される
- 暗号ライブラリは snapshot-safe のビルドが必要。直接コードデプロイのベースイメージは対応済みで、自前のコンテナでは Amazon Linux 2023 の
openssl-snapsafe-libsを使う - 送信元ポートの固定バインドは、復元後の再接続と衝突する可能性があるため避ける
- 起動時に開いたソケットは復元後に維持されないが、クライアントの内部状態(エンドポイントや認証情報の解決結果、コネクションプール)は引き継がれるため、起動時にクライアントを生成して一度呼び出しておく
運用で気をつけること
作成や更新の挙動が V1 と異なります。
- 作成と更新は数分かかり、READY になるまで
CREATINGやUPDATINGのままになる。この間に update や delete を呼ぶとConflictExceptionになるため、get_agent_runtimeでステータスをポーリングする - スナップショットは、最初に healthy を返した
/pingの時点で取られる。初期化が終わってから healthy を返す必要があり、起動から 120 秒以内に healthy にならないと作成が失敗する - 環境変数の合計サイズは V2 で 1.5 KB(直接コードデプロイ)または 2.5 KB(コンテナ)までで、V1 の 4 KB より小さい。公式は V1 と同水準に引き上げる予定としている
- AWS CloudFormation と AWS CDK は、現時点で
platformVersionの指定に対応していない - スナップショットは自動で管理される。Runtime を更新すると旧バージョンのスナップショットは削除対象になるが、実行中のセッションが終わるまで残り、最大で8時間かかる
既存のセッションについては、トラブルシューティングのページに、更新後も既存のセッションは作成時のコードで動き続けるとの記載があります。
新しいコードを使うには新しいセッション ID を使います。
どんなエージェントで V2 を検討するか
ここは公式の記載ではなく、上記の情報から私が考えた目安です。
- コンテナイメージが大きい、またはトラフィックが急に増える場面ではコールドスタートの短縮が直接の利点になる
- アイドルの時間が長い、またはメモリ使用量が大きく上下するエージェントは、メモリ課金の減少で単価差を吸収できる可能性がある
- CDK や CloudFormation で Runtime を管理している場合は、
platformVersionを指定できないため、現状では移行しにくい - 環境変数を多く使っている構成は、サイズ上限を確認する必要がある
確認できていないこと
次の点は、今回の調査では確認できていません。
- V2 の Runtime を実際に動かした場合のコールドスタートとコスト
- 詳細なエンジニアリング解説(What's New が案内しているブログ)の内容
- 既存セッションを持つ Runtime を V1 から V2 へ更新した場合の、既存セッションの扱いの明文化された記述
最後まで読んでいただきありがとうございました。