Google 9 июля 2026 года вывела Cloud Run sandboxes в публичное превью и тем самым закрыла квартет: теперь AWS, Google Cloud, Microsoft Azure и Cloudflare предлагают встроенные песочницы для запуска кода, который пишет ИИ-агент. Для команд, которые строят продукты поверх LLM, это уже не экзотика для лаборатории, а новый базовый слой облачной архитектуры.
Но дальше начинается самое интересное: одинаковую задачу все четыре провайдера решают по-разному. И от этой разницы зависят цена ошибки, требования к безопасности и то, насколько больно потом будет переезжать между облаками.
Google закрыла квартет нативных песочниц
Повод для разговора дал именно Google Cloud. Компания представила Cloud Run sandboxes на конференции WeAreDevelopers World Congress в Берлине, а затем подробно описала запуск в официальном блоге. Смысл функции простой: сервис на Cloud Run может безопасно исполнять недоверенный код или дочерние процессы, не отдавая им доступ к основной среде выполнения.
Для разработчика это выглядит почти буднично. В команде развёртывания появляется флаг --sandbox-launcher, а внутри контейнера становится доступна утилита sandbox. Google отдельно подчёркивает, что не вводит отдельную наценку: песочницы используют уже выделенные экземпляру CPU и память. В демонстрации один сервис Cloud Run запускал, исполнял и завершал 1000 песочниц со средней задержкой около 500 миллисекунд на каждую.
У каждого облака своя граница изоляции
AWS сделала ставку на Lambda MicroVMs поверх Firecracker. Каждая сессия получает отдельную микровиртуальную машину, может работать до восьми часов и умеет приостанавливать состояние с сохранением памяти, диска и процессов. Это вариант для сценариев, где агент не просто запускает короткий скрипт, а живёт дольше одного запроса.
Microsoft пришла к этому подходу раньше. В Azure Container Apps dynamic sessions сессии работают с изоляцией Hyper-V с 2024 года, а Microsoft сообщала, что один только Copilot использует более 400 тысяч таких сессий в день. Это уже не витрина для конференции, а нагрузка промышленного уровня.
Google пошла по двум путям сразу. В GKE Agent Sandbox компания использует gVisor, а в Cloud Run добавила более лёгкую модель: песочница запускается внутри существующего экземпляра сервиса. Cloudflare, в свою очередь, строит Sandbox SDK поверх Containers, Workers и Durable Objects. Формально это контейнерная модель, но сами контейнеры у Cloudflare работают внутри отдельных виртуальных машин, то есть компромисс между скоростью и жёсткой изоляцией у неё свой.
Ограничения никуда не делись
На бумаге всё выглядит как стандартная функция облака: взял и запускай агентный код безопасно. На практике у каждого провайдера остаются свои рамки. У AWS есть потолок в восемь часов, привязка к Graviton и ограниченный набор регионов. У Cloud Run песочница делит ресурсы с родительским экземпляром, поэтому неудачный скрипт может спорить за CPU и память с основным сервисом. У Cloudflare и Azure логика управления тоже завязана на собственные сервисы платформы, а значит, переносимость между облаками быстро превращается из красивой идеи в дорогой проект.
Есть и более приземлённая проблема. Песочница решает задачу изоляции, но не задачу управления. Она не отвечает на вопрос, какие секреты получит агент, куда ему можно ходить по сети и что он попробует выгрузить наружу. Иными словами, контейнер для хаоса индустрия уже построила; теперь нужно решать, сколько свободы этому хаосу вообще выдавать.
Значение для рынка
Для русскоязычных продуктовых и платформенных команд вывод простой: собирать собственную инфраструктуру для безопасного запуска агентного кода теперь нужно реже. Облака закрывают базовый сценарий из коробки, и это снижает порог входа для внутренних Copilot-сервисов, аналитических агентов и инструментов автоматизации. Но вместе с удобством растёт зависимость от конкретной модели изоляции, поэтому архитектурный выбор между AWS, Google, Azure и Cloudflare теперь касается не только цены или региона, но и того, как именно ваш агент будет жить, тормозить и ошибаться в продакшене.
Следующий раунд конкуренции пойдёт уже не за сам факт безопасного запуска, а за правила поведения агента после старта.