AWS ejecuta Claude Code de forma remota: una microVM por tarea

Un agente de programación remoto resuelve un problema conocido: Claude Code en local solo resulta útil mientras el portátil permanece abierto, el entorno está disponible y la tarea no exige una larga ejecución de pruebas. AWS propone trasladar este proceso a Amazon Bedrock AgentCore. El desarrollador describe la tarea, cierra el portátil y, más tarde, recibe un borrador de pull request con los cambios y los resultados de la validación.

Lo importante aquí no es simplemente que Claude se ejecute en la nube. El valor está en el perímetro de control ya montado: un entorno independiente para cada tarea, acceso temporal a GitHub, conexiones privadas con los servicios de AWS, un rol de IAM restringido y una revisión humana obligatoria. El agente puede escribir código, pero no puede fusionarlo de forma autónoma en la rama principal.

Como se ejecuta una tarea

Imaginemos un pequeño error: una API devuelve 500 en lugar de 404 cuando no encuentra un registro. El desarrollador envía la descripción mediante el complemento de Claude Code o la consola web. La solicitud se firma con credenciales de AWS, Amazon Bedrock Guardrails la comprueba, se guarda en DynamoDB y entra en una cola de SQS.

El despachador inicia una sesión independiente de AgentCore Runtime. Cada tarea obtiene su propia microVM, con procesador, memoria y sistema de archivos aislados. En su interior ya están instalados Claude Code CLI, Claude Agent SDK, git y make. El agente recibe un token temporal de GitHub, clona el repositorio y consulta las indicaciones guardadas de ejecuciones anteriores del proyecto.

A continuación, Claude Opus elabora un plan y Claude Sonnet aplica los cambios. El agente ejecuta los comandos de instalación y pruebas definidos por el propio repositorio. Después, Opus revisa el resultado y, si es necesario, devuelve el trabajo para otra iteración. Se permiten hasta tres intentos. Al final, el agente crea una rama con un nombre como agent/<taskId> y abre un pull request que indica el comando de validación, su código de salida y el número de intentos. Si las pruebas fallan, el pull request permanece como borrador.

De donde procede la seguridad

El contenedor no recibe claves permanentes de AWS. Las llamadas a los modelos pasan por Amazon Bedrock mediante credenciales temporales de IAM proporcionadas por el entorno de ejecución. La GitHub App solo se instala en los repositorios seleccionados y el token emitido al agente tiene una vigencia máxima de 8 horas. Los permisos se limitan al contenido del repositorio y a los pull requests, mientras que los commits se firman con la cuenta de la aplicación.

La red también está restringida: el entorno funciona en subredes privadas de una VPC y se conecta a Bedrock y otros servicios de AWS mediante puntos de conexión privados. El acceso a internet es necesario para GitHub y los registros de paquetes. En el ejemplo, los dominios del proveedor de modelos se bloquean mediante DNS Firewall, aunque AWS advierte expresamente que una lista de dominios prohibidos no controla todo el tráfico HTTPS. Para producción hace falta una lista de permitidos aplicada en AWS Network Firewall.

Guardrails examina la tarea original para detectar intentos de jailbreak, solicitudes maliciosas y secretos. Sin embargo, los archivos del repositorio y la salida de los comandos no pasan por esta comprobación. Por tanto, una instrucción maliciosa escondida en un README o en un script de compilación sigue siendo un riesgo. El aislamiento mediante microVM protege las demás tareas y el portátil del desarrollador, pero no convierte en seguro el código que no es de confianza.

Que debe hacer el equipo

Conviene empezar con tareas acotadas en un repositorio de confianza: una pequeña funcionalidad, la corrección de un error o la incorporación de pruebas. El proyecto debe ofrecer comandos reproducibles de setup y test, y la rama principal debe estar protegida mediante una revisión obligatoria. Las investigaciones abiertas y las grandes refactorizaciones encajan peor: el agente está limitado a tres intentos y, durante la ejecución, resulta más difícil dirigirlo que en una sesión local.

También hay un coste. El despliegue tarda entre 15 y 25 minutos, y registrar el repositorio exige otros 8–12 minutos. NAT Gateway, los puntos de conexión de red, WAF, Cognito, DNS Firewall, el almacenamiento de imágenes y los registros generan cargos incluso cuando no hay tareas activas. Un presupuesto de 200 dolares solo envía una alerta; no detiene el gasto.

La conclusión práctica es sencilla: no se trata de “Claude Code en un servidor remoto”, sino de un modelo para una fábrica administrada de pull requests. Puede interesar a equipos que necesiten tareas paralelas en segundo plano, auditoría dentro de AWS y aislamiento respecto a los portátiles de trabajo. Pero solo debería ponerse en marcha junto con protección de ramas, control del tráfico saliente, límites de gasto y una regla estricta: el agente propone los cambios y una persona decide qué llega a producción.