Identidad resuelta en el módulo 2; ahora el agente necesita un cuerpo: cómputo donde ejecutar su código. Y aquí AWS intimida por abundancia — Lambda, App Runner, Fargate, ECS, EKS, Batch, EC2 — cuando en realidad, para agentes de IA, el menú se colapsa con tres preguntas que no mencionan ningún servicio. Este módulo las hace, arma la tabla de decisión y la aplica a los tipos de agente que la plataforma va a correr.

Una aclaración de alcance: hablamos del cómputo de tu código de agente (el loop, las herramientas, la integración). La inferencia del modelo es aparte — vive en Bedrock o en tu LLM gateway (módulo 7) — y los runtimes administrados de agentes (AgentCore) son el módulo 9. Aquí decidimos dónde corre lo que tú escribes.

La tesis del módulo

El cómputo de un agente se decide con tres preguntas — ¿cuánto dura la tarea?, ¿cuánto pesa su entorno?, ¿el trabajo llega como tráfico o como lotes? — y con una convicción de diseño: el agente autónomo no es un servidor esperando; es trabajo que despierta cómputo. Pagar por un proceso encendido 24/7 para un agente que trabaja 40 minutos al día no es arquitectura conservadora: es no haber entendido el modelo de la nube.

El menú, glosado en una pasada

Lambda: funciones que corren al llegar un evento, escalan solas y se cobran por milisegundo. Límite duro: 15 minutos por ejecución y un entorno acotado. El cómputo “sin servidores” por excelencia.
Fargate: contenedores sin administrar máquinas — le das la imagen, AWS pone el fierro. Sin límite de duración; pagas mientras el contenedor viva.
ECS (Elastic Container Service): el orquestador de contenedores nativo de AWS — decide cuántas copias corren, dónde y cómo se reemplazan. Usa Fargate (o EC2) como músculo.
EKS (Elastic Kubernetes Service): Kubernetes administrado. Máxima portabilidad y ecosistema, máxima complejidad operativa del menú.
Batch: colas de trabajos pesados por lotes sobre cómputo efímero, con prioridades y reintentos administrados.
Step Functions: no es cómputo — es la máquina de estados administrada que orquesta pasos (Lambdas, tareas ECS, llamadas a servicios) con reintentos, ramas y esperas de hasta un año. Guárdala en mente: reaparece en el módulo 11 como columna vertebral de la aprobación asíncrona.

Las tres preguntas

1. ¿Cuánto dura la tarea? El eje que descarta más rápido. Bajo ~10 minutos por invocación: Lambda es candidata natural. Sobre eso — y un agente con varios turnos de modelo, herramientas y reintentos se pasa de 15 minutos con facilidad — Lambda queda fuera y el mundo es de contenedores (Fargate/ECS) o de partir la tarea en pasos cortos orquestados por Step Functions.

2. ¿Cuánto pesa el entorno? Dependencias grandes, binarios, un navegador para herramientas de browsing, estado en disco entre pasos: contenedor. Función liviana con SDK y poco más: Lambda. El cold start (arranque en frío: la latencia de crear el entorno en la primera invocación) importa solo si hay un humano esperando la respuesta — al agente nocturno no le duele arrancar en dos segundos.

3. ¿El trabajo llega como tráfico o como lotes? Peticiones continuas con picos (un asistente con usuarios): servicio en ECS con auto-scaling. Ráfagas discretas de eventos (correos que llegan): Lambda o tareas efímeras disparadas por cola. Lotes masivos programados (analizar 10.000 llamadas cada noche): Batch o tareas Fargate lanzadas por scheduler.

        ¿DÓNDE CORRE EL AGENTE? — EL ÁRBOL

START ──► ┌──────────────────┐
          │ ¿tarea < ~10 min │
          │ y entorno chico? │
          └───┬──────────┬───┘
           sí │          │ no
              ▼          ▼
        ┌─────────┐  ┌─────────────────┐
        │ Lambda  │  │ ¿flujo continuo │
        └─────────┘  │ de usuarios?    │
                     └───┬─────────┬───┘
                      sí │         │ no
                         ▼         ▼
                  ┌───────────┐ ┌──────────────┐
                  │ servicio  │ │ tareas       │
                  │ ECS +     │ │ efímeras:    │
                  │ escalado  │ │ Fargate/Batch│
                  └───────────┘ └──────────────┘

¿Y EKS? Entra por razones organizacionales, no técnicas: equipos que ya operan Kubernetes, portabilidad multi-cloud como requisito, o herramientas del ecosistema K8s que necesitas. Si ninguna aplica, EKS es pagar el peaje operativo más caro del menú para llegar al mismo lugar que ECS.

La tabla de decisión por tipo de agente

Los tipos de workload agéntico que una plataforma real corre, con su cómputo natural:

Tipo de agente	Ejemplo del catálogo	Duración	Cómputo natural
Reactivo corto	Clasificar un correo al llegar	Segundos	Lambda (evento desde cola)
Reactivo largo	Investigar y redactar una cotización	5-30 min	Tarea Fargate efímera por evento
Conversacional	Asistente con usuarios en vivo	Continuo	Servicio ECS + auto-scaling
Lote programado	Analizar todas las llamadas del día	Horas	Batch / Fargate + scheduler
Flujo multi-paso	Pipeline aprobar→ejecutar→verificar	Días (espera)	Step Functions orquestando pasos

Dos lecturas de la tabla. Primera: cuatro de cinco filas usan cómputo efímero — nace con el trabajo, muere al terminar, cuesta cero entre medio. Es la tesis del módulo hecha tabla: el agente autónomo es trabajo que despierta cómputo, y el único caso de proceso siempre vivo es el conversacional con humanos esperando. Segunda: la fila de Step Functions no compite con las otras — las compone. Un flujo de días no es un contenedor corriendo días: es una máquina de estados que duerme gratis entre pasos y despierta cómputo efímero en cada uno.

Ojo — el costo de la espera: la trampa clásica del agente “esperador”: un contenedor vivo esperando que alguien apruebe, que llegue un correo, que pase la hora. En la nube, esperar con el proceso encendido es pagar por no hacer nada. La espera se diseña fuera del cómputo — en la cola (el mensaje espera gratis), en el scheduler (EventBridge dispara a la hora), o en Step Functions (el estado de espera no factura cómputo). El módulo 5 desarrolla las colas; el 11, las esperas de aprobación.

Cuidado — el estado no vive en el cómputo: si el cómputo es efímero, todo lo que el agente necesita recordar (historial, progreso, resultados parciales) debe vivir fuera — en las bases del módulo 6. Un agente que guarda estado en su disco local es un agente amnésico cada vez que su contenedor muere. Esta regla — cómputo desechable, estado externo — es quizás el principio de diseño cloud más importante de todo el curso.

Conexión con la economía

Este módulo tiene una lectura de FinOps directa (desarrollada en el módulo 8): el cómputo efímero convierte el costo fijo en variable, que es exactamente la forma de costo que la economía de casos de uso sabe evaluar — costo por tarea × volumen. Un servicio 24/7 para carga esporádica rompe esa cuenta: pagas capacidad, no trabajo. La excepción legítima es volumen alto y sostenido, donde el servicio siempre-vivo amortiza y el efímero paga sobreprecio por arranque — el mismo cruce API-vs-autohospedaje de siempre, en versión cómputo.

Errores comunes

El servidor 24/7 para el agente que trabaja una hora al día. El anti-patrón más frecuente, heredado del mundo on-premise. Si no hay humanos esperando respuestas continuas, el cómputo debe ser efímero.
Forzar Lambda más allá de sus límites. Partir un agente de 40 minutos en hacks para caber en 15 es pelear contra la herramienta. Sobre ~10 minutos reales, contenedor efímero — o Step Functions si los pasos son naturales.
Elegir EKS por prestigio. “Lo serio es Kubernetes” es la razón equivocada. EKS se justifica por organización (equipo K8s, multi-cloud requerido), no por seriedad; ECS llega igual de lejos con la mitad de operación.
Esperar con el motor encendido. Contenedores vivos aguardando eventos, aprobaciones u horarios. La espera va en colas, schedulers y máquinas de estado — que esperan gratis.
Estado en el disco del agente. Cómputo efímero + estado local = amnesia por diseño. Todo lo que debe sobrevivir a la ejecución vive en almacenamiento externo desde el primer diseño.
Decidir el cómputo antes que la forma del trabajo. “Usemos Fargate” antes de saber si el trabajo es tráfico, ráfaga o lote es empezar por la respuesta. Las tres preguntas van primero; el servicio sale solo.

La frase para llevarse

“Tres preguntas eligen el cómputo: cuánto dura, cuánto pesa, cómo llega el trabajo. Y una convicción lo gobierna: el agente autónomo no es un servidor esperando trabajo — es trabajo que despierta cómputo, lo usa y lo apaga. Todo lo que deba sobrevivirle vive fuera.”

Qué viene

Módulo 4: redes. El agente ya tiene identidad y cuerpo; falta decidir por dónde respira. La VPC y sus subredes públicas y privadas, los security groups, y las dos preguntas de red que definen la seguridad de una plataforma de agentes: cómo llegan las llamadas a los servicios de AWS sin pasar por internet (endpoints privados), y — la más importante para agentes autónomos — qué puede salir: el control de egress como guardrail físico contra la exfiltración, que ninguna inyección de prompt puede desactivar.

Arquitectura AWS — Módulo 3: cómputo para agentes