Once módulos de decisiones; este las ensambla. No hay teoría nueva — hay el diagrama que estuvimos construyendo sin dibujarlo entero, la tabla que lo justifica línea por línea, y las instrucciones de adaptación: qué construir primero según tu escala, y qué de todo esto te llevas cuando cruces a GCP o Azure en los próximos cursos de la serie.

El caso que corre por el diagrama es el agente reactivo del catálogo — el clasificador de correos — con el cotizador (aprobación de por medio) apareciendo donde el flujo se pone interesante. Son deliberadamente los mismos casos de la Metodología de casos de uso: aquella serie decidió si construirlos y cuánto costaban; esta muestra sobre qué corren.

La tesis del módulo

Una plataforma de agentes autónomos en AWS es, en su esencia, un patrón de cuatro tiempos: el trabajo despierta cómputo efímero (colas y eventos), el cómputo piensa a través de un punto único de modelos (gateway y guardrails), sus acciones pasan por jaulas independientes (IAM, red, presupuesto), y lo irreversible espera un veredicto humano sin gastar un centavo (aprobación asíncrona). Todo lo demás — los doce módulos — son las decisiones que hacen ese patrón concreto, seguro y pagable.

El diagrama completo

   LA PLATAFORMA DE AGENTES AUTÓNOMOS EN AWS

  correo entra          cron 2am        humano (API)
       │                   │                │
       ▼                   ▼                ▼
  ┌─────────┐      ┌─────────────┐   ┌───────────┐
  │  SQS    │      │ EventBridge │   │ API GW    │
  │ (+DLQ)  │      │ Scheduler   │   │ (auth+    │
  └────┬────┘      └──────┬──────┘   │  límites) │
       │                  │          └─────┬─────┘
       │                  │                │
       └────────┬─────────┴────────────────┘
                ▼          todo en subred privada
  ┌───────────────────────────────────────────────┐
  │  AGENTE — cómputo efímero (Fargate/Lambda)    │
  │  rol IAM propio · secretos en el borde        │
  │  estado fuera: DynamoDB · Aurora · S3 · Redis │
  └───────┬───────────────────┬───────────────────┘
          │ pensar            │ acción irreversible
          ▼                   ▼
  ┌───────────────┐   ┌────────────────────┐
  │ Bedrock       │   │ Step Functions     │
  │ (perfil por   │   │ espera aprobación  │
  │ agente +      │   │ (token + timeout   │
  │ guardrails)   │   │ conservador)       │
  └───────────────┘   └────────────────────┘

  transversales: CloudTrail → cuenta seguridad ·
  GuardDuty · CloudWatch/X-Ray · Budgets+acciones ·
  tags en todo · egress = lista corta

Recórrelo con los cuatro tiempos de la tesis: despertar (columna superior: cola, reloj o petición — nunca un proceso esperando), pensar (el punto único hacia Bedrock, con perfil que atribuye y guardrail que filtra), actuar dentro de jaulas (el rol mínimo, la subred sin salida libre, el presupuesto con freno), y frenar ante lo irreversible (la máquina de estados dormida esperando el veredicto). Si puedes explicar por qué cada caja está donde está, el curso cumplió.

La tabla de decisiones

Cada pieza del diagrama, su decisión y dónde se argumentó — útil como checklist de revisión de cualquier arquitectura de agentes que te presenten:

Decisión	La respuesta del curso	Módulo
¿Dónde vive cada entorno?	Cuentas separadas, SCPs como techo	1
¿Qué puede hacer el agente?	Un rol por agente, política por tarea	2
¿Dónde corre?	Efímero salvo tráfico humano continuo	3
¿Por dónde respira?	Privadas + endpoints; egress = lista corta	4
¿Cómo se hablan las piezas?	Colas y eventos; síncrono solo con humanos	5
¿Dónde vive el estado?	Por forma de acceso; historial = honeypot	6
¿Cómo consume modelos?	Bedrock como gateway; proxy solo con razón	7
¿Quién paga qué?	Tags + perfiles; freno en capas por rol	8
¿Administrado o propio?	Por pieza: compra lo peligroso, guarda tu diferencial	9
¿Cómo se blinda?	Secretos en el borde, CMK, guardrails, trail inmutable	10
¿Cómo se supervisa sin estar?	Métricas de trabajo, alarmas con acción, aprobación asíncrona	11

Las tres escalas: no todo se construye el día uno

La arquitectura de referencia es el destino, no el punto de partida — el mismo principio del mínimo viable de la landing zone, aplicado al curso entero:

Escala	Qué construyes	Qué difieres conscientemente
Piloto (1 agente, datos internos)	Cuenta separada de prod · rol propio · cola+DLQ · Lambda/Fargate · tags · budget con alerta	Proxy de gateway · CMK · GuardDuty · aprobación asíncrona (si nada es irreversible)
Producción (1-3 agentes, datos de clientes)	+ subredes privadas y endpoints · egress cerrado · perfiles de inferencia · guardrails · CMK en historial · CloudTrail a cuenta segura · dashboard + alarmas · aprobación asíncrona	Proxy propio (si sigues solo-Bedrock) · EKS · throughput aprovisionado
Plataforma (muchos agentes/equipos)	+ gateway propio con cuotas · AgentCore donde la tabla del m9 lo diga · anomaly detection · Organizations con tag policies exigidas · runbooks y recalibración de gobernanza	—

La columna del medio es el contrato mínimo para tocar datos de clientes; la diferencia entre piloto y producción no es tamaño — es responsabilidad. Y nota qué nunca aparece como diferible: el rol propio, la cola, los tags y el budget. Esas cuatro piezas cuestan horas y son la diferencia entre incidente y anécdota desde el primer día.

El puente a GCP y Azure

Los próximos cursos de la serie mantienen este esqueleto — es la promesa de la opción C. Lo que viaja tal cual, porque es arquitectura y no producto: los cuatro tiempos del patrón, el reparto de datos por forma de acceso, el agente como principal con mínimo privilegio, el egress como lista corta, el freno en capas, la aprobación con timeout conservador. Lo que cambia de nombre (y a veces de forma — cada curso abrirá sus módulos con la tabla de equivalencias):

Concepto (este curso)	AWS	En GCP verás	En Azure verás
Unidad de aislamiento	Cuenta	Proyecto (¡otra semántica!)	Suscripción / RG
Identidad de workload	Rol IAM	Service account	Managed identity
Cómputo efímero	Lambda/Fargate	Cloud Run / Functions	Container Apps / Functions
Colas y eventos	SQS/EventBridge	Pub/Sub / Scheduler	Service Bus / Event Grid
Modelos administrados	Bedrock	Vertex AI	Microsoft Foundry (ex Azure AI Foundry)
Orquestación con espera	Step Functions	Workflows	Durable Functions / Logic Apps

La primera fila es el aviso de que no será un buscar-y-reemplazar: el “proyecto” de GCP no es la “cuenta” de AWS con otro nombre — organiza permisos y facturación con otra filosofía, y ahí empezará el curso de GCP.

Errores comunes (los del curso entero, destilados)

Empezar por los servicios y no por el patrón. Quien entiende los cuatro tiempos arma la plataforma con cualquier catálogo; quien colecciona servicios arma un inventario.
Construir la escala “plataforma” para un piloto. Seis meses de gateway multi-tenant para un agente que clasifica correos es el anti-patrón de la landing zone máxima. La tabla de escalas existe para eso.
Saltarse las cuatro piezas no diferibles. Rol propio, cola, tags, budget: horas de trabajo que ninguna escala excusa. Todo lo demás admite “después”; esto no.
Tratar el diagrama como dogma. Es una referencia: tu caso puede legítimamente cambiar piezas — lo que no puede es cambiarlas sin saber qué decisión está tomando. Para eso está la tabla con los módulos.
Cruzar de nube con buscar-y-reemplazar. Las equivalencias de la última tabla son puentes, no sinónimos. Los cursos de GCP y Azure existen precisamente porque las diferencias importan.
Terminar el curso y no dibujar el propio. El examen real: toma tu caso (o el de la Metodología), dibuja tu versión de este diagrama y justifica cada caja con su módulo. Donde no puedas justificar, ahí falta decisión — no servicio.

La frase para llevarse

“Cuatro tiempos definen la plataforma: el trabajo despierta al agente, el agente piensa por un punto único, actúa dentro de jaulas independientes, y lo irreversible espera un veredicto sin gastar. Los servicios cambian de nube y de año; ese patrón — y las jaulas — son la arquitectura.”

Qué viene

Aquí cierra el curso de AWS — el fundacional de la serie de nubes. El siguiente es el curso de GCP: mismo esqueleto de 12 módulos, cero teoría repetida, y el espacio dedicado a lo que de verdad cambia — empezando por la diferencia de filosofía entre cuentas y proyectos, siguiendo por Cloud Run (el cómputo efímero hecho casi filosofía de plataforma) y Vertex AI como catálogo de modelos. Si vienes de este curso, cada módulo te tomará la mitad: la arquitectura ya la tienes; falta el dialecto.

Arquitectura AWS — Módulo 12: la arquitectura de referencia