Google Cloudは今月初め、ベルリンで開催されたWeAreDevelopers World Congressにて、Cloud Runサンドボックスをパブリックプレビューとして提供開始したと発表した。これはAWSがそのバージョンをリリースしてから数週間後のことである。両サンドボックスは同じ問いに答えるものである：エージェントが書いたコードは実際にはどこで実行されるべきか？
同じ四半期に2つのハイパースケーラーがサンドボックスを発表したことで、この分野の状況は完結した。現在、主要4クラウド（AWS、Google Cloud、Microsoft Azure、Cloudflare）はすべて、隔離されたコード実行をネイティブプリミティブとして提供しており、それぞれが質的に異なる隔離スタックとライフサイクルモデルを公開している。
AWSはFirecracker上にLambda MicroVMを構築し、各セッションに専用仮想マシンを割り当て、最大8時間の実行時間と、メモリ、ディスク、実行中プロセスを保持するサスペンド・レジュームサイクルを提供する。Googleは2つのアプローチをとり、GKEエージェントサンドボックスにはgVisorカーネルインターセプトを使用し、Cloud Runは既存のCloud Runインスタンス内に軽量な隔離実行境界を追加する。
Microsoftはこのパターンの先駆者である。Azure Container Appsの動的セッションは2024年からHyper-V境界上で動作しており、MicrosoftによればCopilotだけで1日あたり40万以上のセッションを消費している。Cloudflareはコンテナ上にサンドボックスを構築し、各サンドボックスは独自のVM内で隔離され、WorkersとDurable Objectsを通じて制御される。
4社はセキュリティ境界をどこに置くかについて真摯なアーキテクチャ上の意見の相違がある。しかし各社が販売する製品は同じである：信頼できないコードを送り込めば、プラットフォームはそれを呼び出し元アプリケーションから隔離された場所で実行し、クレデンシャルの露出は別途管理される。
Cloud Run実装では、サンドボックスはフラグとして機能する。デプロイコマンドに--sandbox-launcherフラグを追加すると、コンテナ内の/usr/local/gcp/bin/sandboxにサンドボックスバイナリがマウントされ、アプリケーションは通常のサブプロセス呼び出しを通じてそれを実行する。Googleはこの機能に対して追加料金を請求しない。サンドボックスは既存インスタンスに割り当てられたCPUとメモリを借用するためである。Googleのデモでは、1つのCloud Runサービスが500ミリ秒の平均時間で1,000のサンドボックスを起動、実行、停止した。
Google自身の発表は、代替案として、コンテナクラスタ上に複雑なサンドボックスインフラを構築するか、専門のサードパーティマイクロVMランタイムに費用を支払うことを挙げている。この一文はあるカテゴリのベンダーを狙ったものである。彼らはカーネルを共有するコンテナと起動に数分かかる仮想マシンの間の隙間に、真のビジネスを築いてきた。現在、これら4社はすべてマネージドサンドボックス実行を提供しているが、パッケージングと価格設定は異なる。
隔離は封じ込めの境界であり、ガバナンス層ではない。Firecracker VMは生成されたコードをホストや他のセッションから隔離するが、クレデンシャルやネットワーク到達性は設定上の決定事項である。開発者が意図的に渡したクレデンシャルをコードが何をするかについては何も行わず、ガバナンスはまったく別の層に存在する。封じ込め境界は安全に付与できる自律性の上限を設定するものであり、問題のより安価な部分である。
ベンダーの制約はコモディティ化の中でも存続し、具体的である。Lambda MicroVMは5つのリージョンでGraviton上で動作し、上限は8時間であるため、x86やより長い期間を必要とするチームは依然としてオーケストレーションを自前で行う必要がある。Cloud Runサンドボックスは親インスタンスのCPUとメモリを共有するため、暴走したスクリプトはそれを生成したサービスとリソースを競合する。これらのベンダー固有の制限がこのまま鮮明であるならば、ニュートラルなマルチクラウドサンドボックスはその価値を保ち、これは完了しなかったコモディティ化として読める。
今やすべてのクラウドは、エージェントがホスト上でコードを実行すべきでないことに同意している。これにより、議論はコードが安全に封じ込められた後に、その行動を誰が統制するかという問題に移る。