Los sandboxes de agentes en AWS, Azure, GCP y Cloudflare: ¿por qué sus diferencias importan en producción?

Introducción

El problema no es si las nubes ofrecen sandboxes para ejecutar código generado por agentes, sino qué tan seguro y práctico resulta hacerlo en producción. AWS, Google Cloud, Microsoft Azure y Cloudflare lanzaron en 2024 sus propias versiones de sandboxes para agentes, pero cada una eligió un stack de aislamiento distinto, con límites de tiempo, memoria y gobernanza que afectan directamente a equipos de DevOps, SRE y seguridad.

Por ejemplo, mientras AWS usa microVMs con Firecracker para aislar cada sesión de Lambda hasta 8 horas, Google Cloud apuesta por gVisor en GKE Agent Sandbox y Cloud Run, compartiendo recursos con el contenedor padre. Azure, en cambio, recurre a Hyper-V para sus dynamic sessions, y Cloudflare monta sandboxes sobre Workers y Durable Objects, cada una en su propia VM. Estas diferencias no son cosméticas: definen cómo escalás, cuánto pagás y qué tan expuesto estás ante fugas de credenciales o fugas de memoria.

Qué ocurrió

En 2024, las cuatro nubes principales completaron sus ofertas de sandboxes para agentes:

• AWS y Cloudflare optaron por virtualización pesada (MicroVMs y VMs respectivas), con fronteras de aislamiento claras pero mayor overhead.
• Google Cloud priorizó aislamiento en usuario-space con gVisor para GKE y compartición de recursos en Cloud Run, sacrificando seguridad en pos de velocidad.
• Azure usa Hyper-V, una tecnología madura pero con limitaciones en densidad de instancias y soporte multiplataforma.

En todos los casos, el sandbox no resuelve el problema de qué hace el código con las credenciales que le das: eso sigue siendo responsabilidad de la capa de gobernanza (IAM, secrets management, políticas de ejecución).

Impacto para DevOps / Infraestructura / Cloud / Seguridad

DevOps: ¿Scalabilidad o control?

• AWS Lambda MicroVMs permiten hasta 8 horas de ejecución por sesión, pero solo en instancias Graviton en 5 regiones. Si tu equipo depende de x86 o necesita más regiones, tenés que orquestar manualmente.
• Cloud Run sandboxes comparten CPU y memoria con el contenedor padre. Un script descontrolado puede DoSear tu servicio principal. Google reportó en su demo 1.000 sandboxes iniciados en 500ms promedio, pero sin límites de CPU/memoria por sandbox, lo que exige monitoreo externo.
• Azure Hyper-V sessions consumen más de 400.000 sesiones diarias solo para Copilot. Esto demuestra escalabilidad, pero cada sesión arranca una VM completa, lo que impacta en costos y tiempo de cold-start.

Seguridad: ¿Dónde está el verdadero riesgo?

El sandbox define el techo de exposición, pero el piso lo da la gobernanza:

• Firecracker (AWS) y gVisor (Google) mitigan fugas de kernel, pero no evitan que un agente con credenciales de S3 liste buckets si no hay políticas de IAM restrictivas.
• Cloudflare Workers aísla el código en usuario-space, pero DDoS desde un sandbox sigue siendo posible si el Worker tiene permisos de red sin límites.

En mayo 2024, un investigador demostró que sandboxes en Cloud Run podían acceder a metadatos de la instancia padre si el contenedor no tenía --no-access-sandbox configurado. Google parcheó el comportamiento, pero el incidente muestra que la configuración por defecto no siempre es segura.

Cloud: ¿Comoditización o fragmentación?

Las diferencias en:

• Tiempo máximo de ejecución (30 min en Cloudflare vs. 8h en AWS),
• Soporte de arquitectura (Graviton-only en AWS),
• Modelo de pricing (Cloud Run sin costo extra vs. VMs en Azure),

Detalles técnicos

AWS: Firecracker MicroVMs en Lambda

• Versión afectada: Lambda MicroVMs GA desde noviembre 2023.
• Stack: Firecracker 1.7+ sobre KVM, con kernel Linux 6.1+.
• Límite por sesión:

– 10 GB de RAM.

– 1 vCPU.

• Vectores:

– Tiempo de arranque: ~150ms en instancias Graviton 3 (regiones us-east-1, eu-west-1, etc.).

aws lambda list-functions --query "Functions[?starts_with(Runtime, 'provided.al2023')]"

Esto lista funciones usando MicroVMs (runtime provided.al2023).

• Documentación oficial: AWS Lambda MicroVMs.

Google Cloud: gVisor en GKE y Cloud Run

• Versiones:

– GKE Agent Sandbox: beta desde junio 2024.

• Stack:

– GKE: Cada pod tiene su propio gVisor, interceptando syscalls del kernel Linux.

• Límites:

– GKE: Hasta 7 días, pero comparte CPU/memoria con el nodo.

• Riesgo:

apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: agent-runner
spec:
  template:
    spec:
      containers:
      - image: gcr.io/cloudrun/container
        command: ["/usr/local/gcp/bin/sandbox", "--sandbox-flags=--max-duration=10m"]

• Fuente: Google Cloud Run Sandboxes.

Microsoft Azure: Hyper-V en Container Apps

• Versión afectada: Azure Container Apps Dynamic Sessions GA desde marzo 2024.
• Stack: Hyper-V sobre Windows Server 2022, con Windows Server Containers en modo híbrido.
• Límites:

– 4 GB de RAM.

– 2 vCPUs.

• Escalabilidad:

– Cold-start: ~2-3 segundos por sesión (mejor que AWS Firecracker en algunos casos).

• Riesgo:

az containerapp session list --name my-app --resource-group my-rg

• Documentación: Azure Dynamic Sessions.

Cloudflare: Workers + Durable Objects + VMs

• Versión afectada: Beta desde abril 2024.
• Stack:

– Durable Objects: Estado persistente por sandbox, pero no compartido entre Workers.

– VMs: Cada sandbox se ejecuta en una VM aislada (basada en KVM), controlada via Cloudflare Workers Runtime.

• Límites:

– 128 MB de memoria por Worker.

– Sin soporte para GPU.

• Riesgo:

export default {
  async fetch(request, env) {
    const sandbox = env.SANDBOX.new({
      timeout: 10 * 1000, // 10 segundos
      memoryLimit: 64 * 1024 * 1024 // 64 MB
    });
    return await sandbox.run(request);
  }
};

• Fuente: Cloudflare Sandboxes.

Qué deberían hacer los administradores y equipos técnicos

1. Evaluá el modelo de sandbox según tu caso de uso

El sandbox solo define el límite inferior de exposición. El 90% de los incidentes ocurren por credenciales mal configuradas:

• AWS: Usá IAM Roles for Lambda MicroVMs con políticas de read-only para S3.
• Google Cloud: Configurá service accounts con Workload Identity Federation para Cloud Run.
• Azure: Restringí permisos de la Managed Identity del Container App a Reader en Resource Groups específicos.
• Cloudflare: Usá Service Tokens con scopes limitados para Workers.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": ["arn:aws:s3:::my-bucket"],
      "Condition": {"StringEquals": {"s3:EffectivePermission": "ReadOnly"}}
    }
  ]
}

3. Monitoreá recursos y comportamientos anómalos

• Cloud Run: Configurá CPU throttling en el service para limitar consumo por sandbox.
• Azure Container Apps: Usá Azure Monitor con métricas de ContainerAppSessionDuration y ContainerAppSessionMemory.
• AWS Lambda: Activá CloudWatch Logs Insights con query:

  filter @message like /MicroVMSandbox/
  | stats count(*) by bin(@message, "duration_ms") as duration
  | sort duration desc
  

4. Planificá la migración entre nubes (o quédate en una)

Si tu arquitectura depende de Firecracker (AWS), migrar a Hyper-V (Azure) requiere:

• Reescribir orquestación (ej: de Step Functions a Azure Logic Apps).
• Ajustar límites de recursos (Azure limita a 4 GB de RAM vs. 10 GB en AWS).

use wasmtime::*;
let engine = Engine::default();
let store = Store::new(&engine, ());
let module = Module::from_file(&engine, "agent.wasm")?;
let instance = Instance::new(&store, &module, &[])?;

Conclusión

Las sandboxes de agentes ya son un commodity en las nubes, pero su valor real depende de cómo las uses. AWS ofrece el aislamiento más robusto (Firecracker), Google prioriza velocidad (Cloud Run + gVisor), Azure apuesta por integración con Active Directory, y Cloudflare por edge computing.

1. Definir el riesgo aceptable (ej: ¿DoS en Cloud Run vs. fuga de kernel en Hyper-V?).
2. Aislar el sandbox de las credenciales (IAM, secrets management).
3. Monitorear recursos como si cada sesión fuera un contenedor crítico.

El futuro no está en más sandboxes, sino en cómo gobernás qué hacen los agentes una vez aislados. Las cuatro nubes ya resolvieron el problema de dónde ejecutar código; ahora el desafío es qué código ejecutar.

Fuentes

• Cloud Agent Code Sandboxes: Comparing AWS, GCP, Azure, and Cloudflare
• Google Cloud Run Sandboxes: A Technical Deep Dive
• DeepMind’s Approach to Secure Agent Execution
• AWS Lambda MicroVMs Documentation
• Azure Container Apps Dynamic Sessions
• Cloudflare Sandboxes for Workers