2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@Nana_777(山本 直弥（Nao）)
in

【AWS】AgentCore runtimeをV1からV2へ移行しよう【AgentCore】

2
Last updated at Posted at 2026-11-12

はじめに

Amazon Bedrock AgentCoreの次世代のruntimeは、2026年9月18日に公開されました。公式ドキュメントではV2と呼ばれ、従来のruntimeはV1です。V2は、初期化済みのエージェントのスナップショットからセッションを復元する方式で、起動が速く、使った分だけ課金されます。公開から約2か月は、platformVersion をV2にした人だけが使えるオプションでした。

そして2026年11月12日、AWSから「次世代のAgentCore runtimeが既定になった」ことが発表されました。

"Starting today, new runtimes in Amazon Bedrock AgentCore use the next generation of AgentCore runtime by default."
出典: https://aws.amazon.com/about-aws/whats-new/2026/11/new-agentcore-runtime-default/

つまり、新しく作るruntimeが何も指定しなければV2になる、というニュースです。既存のruntimeは移行するまで現行版（V1）のままです。V2がいつ出て、今回のニュースで何が変わったのかは、次の節で時系列に整理します。

一方で、手を動かす立場からは次のような疑問が出ます。

  • 既存のruntimeはどうなるのか。移行は必要か。移行するとき、実行中のセッションや呼び出しはどうなるか
  • 戻せるのか
  • 移行はコンソールでもできるのか。CloudFormationではどうか
  • コードは変えなくてよいのか

そこで本記事では、同じエージェントをV1とV2の両方で動かして比べ、V1からV2への移行を、CLI、マネジメントコンソール、CloudFormationの3つの方法で試しました。公式ドキュメントに載っていない部分は、実際に動かして確かめています。

前提として、AgentCore runtimeの基本（コンテナイメージでエージェントをデプロイすること）と、AWS CLIの基本的な使い方を想定しています。

検証は東京リージョン（ap-northeast-1）で2026年11月13日に行いました。AWSの画面やドキュメントは変わりうるため、日付を明記しています。

V2がいつ出て、今回のニュースで何が変わったか

V2は今回のニュースで初めて出たものではありません。公式の発表とリリースノートから、時系列を整理します。日付は原文の表記です。リリースノートは月単位の記載で、日は書かれていません。

日付 出来事 出典
2026年9月18日 新しいAgentCore Runtime（V2）が公開された。対象は us-east-1、us-east-2、us-west-2、eu-west-1、ap-northeast-1（東京）の5リージョン。使うには、runtimeの作成または更新時に platformVersion をV2にする What's New
2026年9月18日 AWSのMLブログで、設計（スナップショットからの復元、メモリのオンデマンド割り当て）と計測結果が公開された MLブログ
2026年10月 V2で、環境変数の上限が4KBになった。セッションコンテキストキーとFUSEマウントがV2で使えるようになった リリースノート
2026年11月 V2が10リージョンに拡大した。コンテナイメージの上限が10GB、1セッションあたりの同時接続が250、メモリのベースライン設定（resourceConfigurations）、ビルド時のwarmupフック、が追加された リリースノート
2026年11月12日 新規に作るruntimeが、V2を既定で使うようになったと発表された（19リージョン）。既存のruntimeは移行するまで現行版のまま What's New

出典:

公開時にAWSが示した数値

9月18日の発表とブログでは、AWSの計測として次の数値が示されています。

項目 V1 V2
コールドスタート（P75） 約5.4秒〜約30秒 約1.9〜2.0秒
計測条件（What's New） 200MB〜2GBのイメージ 同左
計測条件（MLブログ） us-east-1のechoエージェントに対して、us-west-2のEC2から5,000回のコールドスタートを計測 同左

課金については、ブログに次の説明があります。

"You pay a higher rate but on far fewer GB-hours, and for most agents the footprint drops more than the rate rises, so the bill goes down."
出典: 上記のMLブログ

単価は上がるが、課金されるGB時間が大きく減るため、多くのエージェントでは請求が下がる、という説明です。本記事では請求額は検証していません。

公開の翌日（2026年9月19日）には、第三者のブログ（Classmethod）が、東京リージョンでV1とV2を比べています。46MB、335MB、859MBの3種類のイメージを、各1回ずつ計測した結果は次のとおりです。

イメージ V1の初回のコールドスタート V2の初回のコールドスタート
46MB 3.4秒 2.1秒
335MB 5.5秒 2.2秒
859MB 13.6秒 1.8秒

出典: https://dev.classmethod.jp/en/articles/amazon-bedrock-agentcore-runtime-v2-tried/

V1はイメージが大きいほど遅くなり、V2はほぼ一定、という傾向です。本記事の検証（V2が約1.6〜2.2秒）とも近い値でした。

今回のニュースで変わったこと

項目 2026年11月12日より前 2026年11月12日の発表
V2を使う方法 platformVersion をV2にする（オプトイン） 同じ。ただし、省略すると新規はV2になる、と発表された
省略したときの新規runtime V1 V2（発表）
既存のruntime V1のまま 移行するまで現行版のまま（変わらない）
対象リージョン 5リージョン（9月）、10リージョン（11月のリリースノート） 19リージョン（東京を含む）

変わるのは、新規に作るときの「省略した場合」だけです。既存のruntimeは変わりません。

ただし、検証した時点（2026年11月13日）の私の環境では、省略するとV1になりました（次の「既定のバージョンはどちらか」で確認します）。AWSのドキュメント（How AgentCore Runtime works）にも "V1 is the default." と書かれたままでした。発表より前に、AWS側から既定の変更についての告知があったかは、確認できませんでした。

結論

Gemini_Generated_Image_hh2zjahh2zjahh2z.jpg

検証した範囲での結論です。条件は、小さいコンテナイメージ（約43.5MB）、起動時に20秒の初期化を行うエージェント、東京リージョンです。

観点 結果
既定のバージョン CLIで --platform-version を省略するとV1になった。コンソールの作成画面でも、V1が選択済みで、V2には "recommended" と表示されていた
作成時間 V1は約1.4秒、V2は約199秒
新しいセッションの待ち時間 V1は約23.7秒（コールドスタート）の場合と、0.4〜1.2秒の場合があった。V2は約1.6〜2.2秒で安定した（初回のみ3.7秒）
スナップショットの影響 V2では、起動時に作った値と、ハンドラ内のPythonの random の値が、複数のセッションで同じになった
移行（V1からV2） CLI、コンソール、CloudFormationのいずれも、runtimeを更新するだけでできた。所要時間は約3〜3.5分
移行中の呼び出し 更新中も呼び出しは成功した。実行中のセッションは、更新の前後で途切れなかった
戻せるか CLI、コンソール、CloudFormationのいずれでも、V2からV1に戻せた（数秒〜17秒）
resourceConfigurations APIでは設定できた。コンソールの更新画面とCloudFormationのテンプレートには項目がなかった

以降、それぞれの確認方法と結果を示します。

AgentCore runtimeのV1とV2

Gemini_Generated_Image_hwk869hwk869hwk8.jpg

公式の発表とドキュメントの記載を整理します。数値は公式の記載で、本記事の検証で確かめたものではありません。

項目 V1 V2 出典
起動方式 記載なし（通常のコンテナ起動） 初期化済みエージェントのスナップショットから復元 発表、ドキュメント
作成・更新の所要時間 数秒でREADY 数分 ドキュメント
コンテナイメージの上限（圧縮） 2GB 10GB ドキュメント
課金（consumption） CPU $0.0895/vCPU-hour、メモリ $0.00945/GB-hour CPU 0.1276/vCPU-hour、メモリ $0.0169/GB-hour 料金ページ
committed baseline なし あり（resourceConfigurations） ドキュメント
コンピューティングタイプ「インスタンス」 使える 使えない（コンソールの表示） コンソール
起動時間の公式の数値 P75で29.7秒（2GBイメージ） P75で2秒未満（2GBイメージ） 発表

出典:

発表と公式ドキュメントで、既定についての記載が食い違っています。発表は「新規のruntimeは次世代が既定」ですが、ドキュメントのPlatform versionsの節には "V1 is the default." とあります。この点は次の節で確かめます。

また、ドキュメントには、スナップショット方式に伴う注意が書かれています。

"Restoring from a snapshot changes how you structure your agent code."
出典: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agents-tools-runtime.html

検証の環境と方法

検証用のエージェント

標準ライブラリだけで書いた小さなHTTPサーバーです。起動時に20秒の「重い初期化」を行ってから、ポート8080で待ち受けます。/invocations は、起動時に固定された値と、リクエストごとに作った値を返します。

# 起動時の処理（V2ではスナップショットに含まれる想定）
time.sleep(INIT_SECONDS)  # 20秒。重い初期化の代わり
STARTUP_RANDOM = random.random()
STARTUP_UUID = str(uuid.uuid4())
STARTUP_EPOCH = time.time()

# /invocations のレスポンス（抜粋）
{
    "startup_uuid": STARTUP_UUID,          # 起動時に作った値
    "startup_epoch": STARTUP_EPOCH,        # 起動時の時刻
    "handler_random": random.random(),     # ハンドラ内のPythonのrandom
    "handler_uuid": str(uuid.uuid4()),     # ハンドラ内のuuid4
    "handler_urandom_hex": os.urandom(8).hex(),
    "pid": os.getpid(),
    "hostname": socket.gethostname(),
}

待ち受けを始めるまで /ping が成功しないため、V2では初期化が終わった時点のスナップショットが取られる想定です（公式の記載: 最初のhealthyな /ping 応答時に取得）。

環境

項目 値
リージョン ap-northeast-1（東京）
実施日 2026年11月13日
コンテナイメージ linux/arm64、約43.5MB、ECRに配置
実行ロール ECRの取得とCloudWatch Logsの書き込みだけを許可した専用ロール
ネットワーク PUBLIC
AWS CLI / boto3 2.39.3 / 1.43.91（resourceConfigurations の確認には boto3 1.44.2 を別の仮想環境で使用）

呼び出しの方法

新しい runtimeSessionId で invoke_agent_runtime を呼び、所要時間と応答内容を記録します。毎回新しいセッションなので、各回が新しいセッションの起動を含みます。実行中のセッションの確認には、固定のセッションIDを使います。

既定のバージョンはどちらか

まず、公式の記載が食い違っていた既定のバージョンを確かめました。

CLIで --platform-version を省略した場合

aws bedrock-agentcore-control create-agent-runtime \
  --agent-runtime-name v_default \
  --agent-runtime-artifact "containerConfiguration={containerUri=<ECRのイメージURI>}" \
  --role-arn <実行ロールのARN> \
  --network-configuration networkMode=PUBLIC

作成後に get-agent-runtime --query platformVersion で確認すると、V1でした。

コンソールの作成画面

東京リージョンのコンソールでは、runtimeが1つ以上あると、「エージェント」ページ右上の「さらに追加」から「エージェントをホスト」で作成画面に入ります。ドキュメントの「Create Host agent (runtime)」とは名称が違いました。

02_さらに追加.png

作成画面の「ランタイムプラットフォームバージョン」は、V1が選択済みで、V2には "recommended" と表示されていました。

03_エージェントをホスト01.png

この画面には、V2についての表示がもう1つありました。コンピューティングタイプの「インスタンス」に、"Not available with runtime platform version V2." と書かれています。インスタンスを使いたい場合は、V2は選べません。

作成方法 省略時の既定
CLI/API V1
コンソール V1（V2はrecommended表示）

公式ドキュメントの「V1 is the default.」と一致する結果でした。発表の「次世代が既定」は、検証時点（2026年11月13日）の私の環境では確認できませんでした。段階的に反映されている可能性はありますが、その点は確認できていません。

作成にかかる時間

V1を明示、V2を明示、省略の3通りで、runtimeを作りました。時間は get-agent-runtime の createdAt と lastUpdatedAt の差です。

runtime 指定 platformVersion READYまでの時間
v1_explicit V1 V1 約1.4秒
v2_explicit V2 V2 約199秒（3分19秒）
v_default 指定なし V1 約1.2秒

V2は、スナップショットを準備するぶん、作成に数分かかります（ドキュメントの "Create and update take minutes." と一致）。

新しいセッションの待ち時間

V1とV2を比べる

10回ずつ、新しいセッションで呼び出しました。作成の約10分後の計測です。

項目 V1 V2
所要時間（中央値／最小／最大） 0.60秒／0.43秒／1.24秒 1.79秒／1.63秒／3.68秒

V2は1.6〜2秒前後で安定しました。初回だけ3.68秒でした。

10分あけて3回呼び出した場合も、結果は同じ傾向でした。

回 V1 V2
1 0.77秒 2.17秒
2 0.75秒 1.90秒
3 0.58秒 1.84秒

V1が速く返ったのは何故か

意外なことに、この表ではV1のほうが速く返っています。初期化に20秒かかるエージェントなので、V1の新しいセッションは約20秒以上かかるはずです。

起動時刻（startup_epoch）を見ると、v1_explicit の10セッションと、一度も呼んでいない v_default の3セッションは、いずれも作成の約24秒後（それぞれ同じ秒）に起動していました。つまり、新しいセッションの呼び出しで起動したのではなく、あらかじめ起動済みのインスタンスで応答していたことになります。

一方で、同じ手順で作成した直後の mig_cli（V1）では、新しいセッションの呼び出しが毎回23.7〜25.7秒かかりました。startup_epoch は呼び出しの直前で、実際にコールドスタートしていました。V2からV1に戻した直後にも、23.7秒でした。

runtime（V1） 状況 新しいセッションの所要時間
v1_explicit 作成の約10分後 0.43〜1.24秒
v_default 一度も呼んでいない 0.85〜1.01秒
mig_cli 作成直後 23.7〜25.7秒
mig_cli V2からV1に戻した直後 23.7秒、23.8秒

V1が起動済みインスタンスを持つ条件は、今回の検証では特定できませんでした。公式ドキュメントにも、V1の事前起動についての記載は見つかりませんでした。

そのため、V1については「待ち時間が約0.5秒のこともあれば、初期化時間を含む約24秒のこともあった」と、事実だけを記します。V2の1.6〜2.2秒は、どの状況でも安定していました。公式の「P75が29.7秒から2秒未満」は2GBのイメージでの値なので、本記事の数値（43.5MBのイメージ）と直接は比べられません。

スナップショットの影響

Gemini_Generated_Image_9w9w4a9w9w4a9w9w.jpg

スナップショットは、runtimeごとに、エージェント自身の初期化が終わった時点の状態を保存したものです。別のruntimeやアカウントの値が混ざることはありません。問題になるのは、同じruntimeから復元された複数のセッション（たとえば別々のユーザーの呼び出し）が、起動時に作られた値を共有することです。

V1のコードが「セッションごとに専用のプロセスが起動し、起動時の値はセッションごとに別になる」ことを暗黙の前提にしていると、V2ではその前提が崩れます。エラーは出ずに値だけが同じになるので、気づきにくい点に注意が必要です。

コードの書き方 V2での問題
random でID・トークン・nonceを作っている 別のセッションに同じ値が出る可能性がある
起動時に作ったUUIDを、セッション固有のIDとして使っている 複数のセッションで同じIDになる
起動時に認証情報や外部の状態を読み込んでいる スナップショットの時点で固定され、復元後も残る

なお、ここで比べる値は、runtimeSessionId ではありません。検証用のエージェントが起動時に自分で作った値です。

V2では、起動時の処理がスナップショットに含まれ、復元された全インスタンスに引き継がれます。ドキュメントにも、次のように書かれています。

「The random module is likewise seeded at startup, so restored instances repeat the same sequence.」
出典: https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-v2-optimize.md

実際に確認した結果です。10回の呼び出し（それぞれ新しいセッション）の応答を比べました。

項目 V1 V2
startup_uuid の種類 10種類（全て別） 2種類（8回が同じ値）
startup_epoch 10回とも同じ秒に揃っていた（上記の起動済みインスタンス） 2つの時刻（8回が同じ値）
handler_random（ハンドラ内の random.random()） 10種類 2種類。startup_uuid が同じセッションは同じ値になった
handler_uuid（ハンドラ内の uuid.uuid4()） 10種類 10種類
pid / hostname 1 / localhost 1 / localhost

V2で分かったことは次のとおりです。

  • 起動時に作った値（startup_uuid など）は、複数のセッションで同じになる
  • ハンドラ内で呼んだ random.random() も、同じスナップショットから復元されたセッションでは、最初の呼び出しの値が同じになる
  • uuid.uuid4() と os.urandom() は、毎回異なる値だった
  • スナップショットは2つだった。10分以上あけても、同じ2つから復元された
  • startup_epoch から、スナップショットはREADYになる約97秒前に取られていた

ドキュメントの推奨のとおり、乱数や識別子はハンドラ内で secrets や os.urandom()、uuid.uuid4() を使って作る必要があります。Pythonの random を、IDやトークンの生成に使っているコードは、V2に移行すると同じ値が出る可能性があります。

/ping が間に合わない場合

V2では、最初のhealthyな /ping 応答時にスナップショットを取ります。ドキュメントには、起動から120秒以内にhealthyにならないと作成が失敗する、とあります。

起動時の初期化を130秒に変えたイメージで、V2のruntimeを作りました。

CREATE_FAILED（作成から約229秒後）
failureReason: The runtime failed its health check. Ensure your container serves the configured health endpoint.

起動の初期化が120秒を超える場合は、V2ではそもそも作成できません。作成が失敗するまでの時間は、120秒に準備の時間が加わった値と考えられますが、内訳は確認していません。

CLIでV1からV2に移行する

V1のruntime（mig_cli）を、update-agent-runtime でV2に移行しました。

aws bedrock-agentcore-control update-agent-runtime \
  --agent-runtime-id <runtimeのID> \
  --agent-runtime-artifact "containerConfiguration={containerUri=<ECRのイメージURI>}" \
  --role-arn <実行ロールのARN> \
  --network-configuration networkMode=PUBLIC \
  --platform-version V2

--agent-runtime-artifact、--role-arn、--network-configuration も、更新時に指定が必要でした。

結果

確認 結果
所要時間 約204秒。バージョン番号が1から2に増えた
更新中の get-agent-runtime 開始の1秒後から、platformVersion はV2、statusはUPDATING
更新中の再update ConflictException（"Cannot update agent ... while it's UPDATING."）
更新中の呼び出し（新しいセッション6回） 全て成功。ただしREADYになるまで旧版の挙動で、毎回約23.7秒
実行中のセッション 更新の前後で途切れなかった
READY後の新しいセッション 約1.9秒（V2の挙動）
--platform-version を省略して更新 V2のまま維持された

実行中のセッションは、更新の前に開始した固定のセッションIDで、更新中に約30秒ごとに呼び出して確認しました。startup_uuid が最後まで同じで、time.monotonic() が増え続け、応答は約0.35〜0.42秒でした。移行をまたいでも、同じプロセスのまま動いています。

つまり、V1からV2への移行で、すでに動いているセッションは影響を受けず、新しいセッションだけがREADYのタイミングでV2に切り替わります。更新中も呼び出しは失敗しませんでした。

DEFAULTエンドポイントは、更新後のバージョンに追従しました。CLIで更新を繰り返した mig_cli は、バージョン4になった時点で、DEFAULTのliveVersionも4でした。

マネジメントコンソールで移行する

コンソールでも、V1からV2に移行できました。

手順

  1. runtimeの詳細画面の右上にある「更新」ボタンを押す
  2. 「ランタイムを更新」画面の「ランタイムプラットフォームバージョン」で、V2を選ぶ
  3. 「ランタイムを更新」を押す

名前とコンピューティングタイプは、更新画面では変更できません（表示のみ）。

14_ランタイム更新.png

結果

押した直後に、次のバナーが表示されました。ステータスは「更新中」になり、「更新」と「エージェントをテスト」のボタンは無効になります。

15_ランタイム更新直後.png

確認 結果
所要時間 約3分16秒（CLIは約204秒）
更新中の実行中セッション 途切れなかった。応答は約0.35秒
更新後 実行中のセッションは継続。新しいセッションは2.08秒（V2の挙動）

CLIと同じ結果でした。

V1/V2をコンソールで確認する場所

詳細画面の見出し部分や、一覧のカードには、V1/V2の表示がありません。「設定」タブの「バージョンの詳細」に、「ランタイムプラットフォームバージョン」として表示されます。

11_設定画面02.png

V2のruntimeの同じ画面では、V2と表示され、さらに「Session capacity: Pay per use」という項目が出ていました（V1の画面にはなかった項目です）。

22_バージョンの詳細.png

「Pay per use」が課金方式（consumption）に対応する表示かどうかは、公式の記載を確認できていません。resourceConfigurations を外した状態での表示だったことから、そう考えられるという推測にとどまります。

V2からV1に戻せるか

ドキュメントには、V2からV1に戻す手順の記載が見つかりませんでした。次の方法で試しました。

方法 結果
CLI（--platform-version V1） 戻せた。READYまで約5秒（バージョン4）
コンソール 更新画面でV1を選べた（無効になっていない）。押した後、すぐにREADY（V1、バージョン3）
CloudFormation（PlatformVersion をV1に変更） 戻せた。約17秒

戻した後の挙動は、移行前のV1と同じでした。新しいセッションは約23.7秒のコールドスタート、V2に移行する前に開始した固定のセッションは、そのまま継続しました（応答は約0.36秒）。

ドキュメントには、参照されなくなったバージョンのスナップショットは削除の対象になり、削除には最大8時間かかる場合がある、と書かれています。V2から戻した後のスナップショットの扱いは、確認していません。

16_V1選べるか.png

CloudFormationで移行する

CloudFormationの AWS::BedrockAgentCore::Runtime には、PlatformVersion プロパティがあります（Update requires: No interruption）。プロパティの許容値（V1/V2）は、リソースのドキュメントに記載がありません。

テンプレートの抜粋です。

Resources:
  Runtime:
    Type: AWS::BedrockAgentCore::Runtime
    Properties:
      AgentRuntimeName: cfn_migration
      AgentRuntimeArtifact:
        ContainerConfiguration:
          ContainerUri: !Ref ContainerUri
      RoleArn: !Ref RoleArn
      NetworkConfiguration:
        NetworkMode: PUBLIC
      PlatformVersion: !Ref PlatformVersion
確認 結果
スタックをV1で作成 17秒でCREATE_COMPLETE。runtimeはREADY、V1
PlatformVersion をV2に変更（変更セット） 変更の種類は Modify、Replacementは False（置き換えなし）
変更セットの実行 210秒でUPDATE_COMPLETE。runtimeはREADY、V2、バージョン2
PlatformVersion をV1に戻す 17秒でUPDATE_COMPLETE。runtimeはV1、バージョン3

CloudFormationでも、runtimeが置き換わることなく、その場で更新されました。CDKのL1（CfnRuntime）にも platformVersion があることを、ドキュメントで確認しています。実際にCDKでデプロイする検証は行っていません。TerraformのプロバイダーでPlatformVersion相当を指定できるかも、確認していません。

resourceConfigurations（committed baseline）

V2には、メモリのベースラインを設定する resourceConfigurations があります。ベースラインを設定すると、より低い単価で課金され、ピーク時はベースラインの最大4倍までバーストできます（公式ドキュメントの記載）。

AWS CLI 2.39.3とboto3 1.43.91には、resourceConfigurations のパラメーターがありませんでした。新しいboto3（1.44.2）を別の仮想環境にインストールして試しました。

c.update_agent_runtime(
    agentRuntimeId=rid,
    agentRuntimeArtifact={"containerConfiguration": {"containerUri": img}},
    roleArn=role,
    networkConfiguration={"networkMode": "PUBLIC"},
    platformVersion="V2",
    resourceConfigurations=[{"minimumMemoryInMiB": 2048}],
)
確認 結果
V2のruntimeに付けて更新 成功。201秒でREADY。get_agent_runtime に resourceConfigurations: [{minimumMemoryInMiB: 2048}] が返る
V1のruntimeに付けて更新 ValidationException: resourceConfigurations can only be used when platformVersion is V2.
省略して更新 201秒でREADY。resourceConfigurations が外れた（consumptionに戻る）
コンソールの更新画面 メモリやCPUのベースラインに当たる項目は見当たらなかった
CloudFormationのテンプレートに記述 create-stack が約6秒でROLLBACK_COMPLETE。"Validation failed with 1 error(s)."（プロパティが未対応）

ベースラインの設定は、現時点ではAPIとSDK（新しいバージョン）からだけのようです。

料金ページには、committed baselineの単価が "launching by October 2026" と書かれています。APIで設定できましたが、課金に実際に反映されるかは、請求額を確認していないため分かりません。

移行の判断の目安

ここまでの結果から、V2への移行を考えるときの判断の目安を表にしました。公式の記載ではなく、本記事の検証結果からの私の見立てです。

状況 見立て
起動時の初期化が長い（数十秒以上）、またはイメージが大きい V2の恩恵が大きい。V1はコールドスタートで初期化時間がそのまま待ち時間になる場合があった
起動時の初期化が120秒を超える V2は作成に失敗する。初期化を軽くする必要がある
Pythonの random などで、IDやトークンを作っている 起動時やハンドラ内の random は、同じ値が出る可能性がある。secrets、os.urandom()、uuid.uuid4() に変える
起動時に認証情報や外部の状態を読み込んでいる スナップショットに固定される。ハンドラ内で更新する（ドキュメントの注意）
コンピューティングタイプ「インスタンス」を使いたい V2は使えない
IaCで管理している PlatformVersion を変えるだけで、置き換えなしで更新できる。ただし更新に約3.5分かかる
ベースライン（committed baseline）を使いたい 現時点ではAPI/SDKのみ。IaCやコンソールでは設定できない

移行の手順自体は、更新するだけで済み、実行中のセッションは影響を受けず、戻すこともできます。リスクが小さい操作なので、まず検証用のruntimeでV2の挙動を確かめてから進める、という流れが取りやすいと考えます。

実際に検証する方法

本記事の検証は、次の順で行いました。コマンドの引数は、各自の環境に合わせて読み替えてください。

  1. ECRにリポジトリを作り、検証用のイメージをlinux/arm64でビルドして、pushする
  2. 実行ロール（信頼ポリシーは bedrock-agentcore.amazonaws.com）を作る
  3. create-agent-runtime で、--platform-version V1、V2、省略の3通りで作る。get-agent-runtime でstatusとplatformVersionを確認する
  4. 新しい runtimeSessionId で invoke_agent_runtime を複数回呼び、所要時間と応答（startup系の値、ハンドラ内の値）を比べる
  5. 別のruntimeをV1で作り、実行中のセッション（固定のセッションID）を呼びながら、update-agent-runtime でV2に移行する。status、platformVersion、所要時間を記録する
  6. コンソールの更新画面でも同じことを試す
  7. --platform-version V1 で戻せるか確認する
  8. CloudFormationのテンプレートで PlatformVersion を変更し、変更セットとスタックの更新を確認する

Windows環境でDockerを使うときの注意があります。Docker DesktopのWindows版では、ECRの認証トークンが長すぎて、既定の認証情報ストアに保存できず、docker push が403で失敗することがありました（error storing credentials ... The stub received bad data）。その場合は、認証情報ストアを使わない設定フォルダを DOCKER_CONFIG に指定して、認証情報を直接書く方法で、pushできました。

検証後は、runtime、CloudFormationのスタック、ECRリポジトリ、IAMロール、CloudWatch Logsを削除してください。V2のスナップショットは、削除に最大8時間かかる場合があります。

さいごに

AgentCore runtimeのV2は、初期化に時間がかかるエージェントで、新しいセッションの待ち時間を、初期化時間に左右されない安定した値（今回は約2秒）にしてくれるものでした。

移行は、runtimeを更新するだけで行えました。更新中も呼び出しは失敗せず、実行中のセッションは途切れず、V1にも戻せます。操作として大きなリスクはありません。注意が必要なのは、スナップショットに起因するコードの挙動（起動時に固定される値や、Pythonの random）、120秒の初期化の上限、そして既定がV1のままであることでした。

発表は「次世代が既定」ですが、検証した時点の私の環境では、CLIでもコンソールでもV1が既定でした。V2を使いたい場合は、platformVersion を明示する必要があります。

英語版

[AWS] Migrating AgentCore runtime from V1 to V2 [AgentCore]

参考文献

2
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
2
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?