Último módulo del curso y de la serie. Primero lo que corresponde: el diagrama de Azure con su tabla — el examen local. Después, lo que solo este módulo puede dar: los tres cursos puestos uno al lado del otro, la tabla tri-cloud definitiva, y la pregunta con la que un arquitecto cierra: ¿cuál para qué?

La tesis del módulo

Los cuatro tiempos — el trabajo despierta cómputo efímero, el cómputo piensa por un punto único, actúa dentro de jaulas independientes, lo irreversible espera veredicto sin gastar — se dibujaron idénticos en tres catálogos distintos, y esa es la conclusión de la serie: la arquitectura de agentes autónomos es portable; los catálogos son dialectos. Azure aporta su acento — el directorio como raíz, la suite integrada, el despliegue con capacidad propia — y la elección de nube, al final, es una decisión de contexto organizacional más que de superioridad técnica.

El diagrama completo

  LA PLATAFORMA DE AGENTES AUTÓNOMOS EN AZURE

  correo entra       cron 2am         blob subido
       │                │                 │
       ▼                ▼                 ▼
  ┌──────────┐   ┌─────────────┐   ┌───────────┐
  │ Service  │   │ cron del    │   │ Event     │
  │ Bus(+DLQ)│   │ job         │   │ Grid      │
  └────┬─────┘   └──────┬──────┘   └─────┬─────┘
       │                │                │
       └───────────┬────┴────────────────┘
                   ▼   RG por agente · VNet privada
  ┌───────────────────────────────────────────────┐
  │ AGENTE — Container App/job (KEDA por la cola) │
  │ managed identity · Key Vault en el borde      │
  │ estado: Cosmos · PostgreSQL · Blob · Redis    │
  └───────┬───────────────────┬───────────────────┘
          │ pensar            │ acción irreversible
          ▼                   ▼
  ┌───────────────┐   ┌────────────────────┐
  │ Foundry       │   │ Durable Function / │
  │ (despliegue + │   │ Logic App espera   │
  │ TPM + Content │   │ veredicto (timeout │
  │ Safety)       │   │ conservador)       │
  └───────────────┘   └────────────────────┘

  transversales: logs → workspace seguridad (KQL) ·
  Defender + plan IA · budgets → action groups ·
  private endpoints + egress FQDN · tags por policy

La tabla de decisiones se relee con las respuestas locales — ¿dónde vive? suscripciones + RG por agente bajo policy; ¿qué puede hacer? managed identity con roles en su scope; ¿dónde corre? Container Apps con KEDA por la señal correcta; ¿por dónde respira? private endpoints universales + egress por FQDN; ¿cómo se hablan? Service Bus con las finuras por razón; ¿dónde el estado? Cosmos/Postgres/Blob con el honeypot cifrado; ¿cómo consume modelos? despliegues con TPM (y APIM si multi-equipo); ¿quién paga y frena? tags obligatorios + budget → action group; ¿administrado o propio? la suite por pieza con reemplazo documentado; ¿cómo se blinda? Key Vault, CMK, Prompt Shields, Defender; ¿cómo se supervisa? App Insights + KQL + dos finales de aprobación. Las cuatro piezas no diferibles cierran su gira: identidad propia por agente, cola con DLQ, tags (aquí: exigidos por policy), presupuesto con alerta.

La tabla tri-cloud definitiva

El artefacto final de la serie — las filas que un arquitecto consulta al cruzar cualquier frontera:

Concepto	AWS	GCP	Azure
Raíz organizacional	Organización	Organización	Tenant (Entra ID)
Unidad de aislamiento	Cuenta	Proyecto (liviano)	Suscripción + RG
Identidad del agente	Rol IAM	Service account	Managed identity
Cómputo efímero	Lambda / Fargate	Cloud Run	Container Apps
Cola + abanico	SQS + SNS	Pub/Sub	Service Bus
Reloj	EventBridge Scheduler	Cloud Scheduler	cron de jobs / Logic Apps
Sesiones del agente	DynamoDB	Firestore	Cosmos DB
Objetos	S3	GCS	Blob Storage
Modelos administrados	Bedrock	Vertex AI (hoy Gemini Enterprise Agent Platform)	Foundry (deployments)
Stack de agentes	AgentCore	ADK + Agent Runtime	Agent Framework + Agent Service
Guardrail del diálogo	Bedrock Guardrails	Model Armor	Content Safety
Perímetro de datos	(se compone)	VPC Service Controls	(se compone + policy)
Espera de veredicto	Step Functions	Workflows callback	Durable / Logic Apps
Análisis del gasto	Cost Explorer	Billing → BigQuery	Cost Management + exports
Freno de fábrica	Budget actions	Cuotas de API	TPM por despliegue

¿Cuál nube para qué? La respuesta sin marketing

La pregunta final merece respuesta directa, con la advertencia honesta de que el contexto manda más que el catálogo:

La razón número uno es organizacional, no técnica: dónde están tus datos, tus contratos, tu equipo y sus habilidades pesa más que cualquier fila de la tabla. La mejor nube suele ser la que tu organización ya opera bien — y los tres cursos existen precisamente para que esa inercia sea una decisión informada y no una condena.
AWS es el default del mercado por catálogo, madurez y talento disponible — y su stack de agentes (Bedrock + AgentCore) no tiene un modelo de la casa que empuje el diseño. El terreno seguro cuando no hay un factor que incline.
GCP brilla donde la estructura y los datos mandan: proyecto-por-agente regalando aislamiento y FinOps, BigQuery como centro de gravedad analítico, y el stack abierto (ADK, A2A) con Gemini y Claude de primera clase. El favorito de plataformas data-céntricas y equipos que valoran lo liviano.
Azure gana en su terreno: la empresa Microsoft — identidad corporativa gobernando agentes y aprobadores, GPT y Claude con contrato enterprise, los conectores al ecosistema (Teams, SharePoint, Dynamics) y la suite Foundry componiendo rápido. Si tus agentes van a vivir entre empleados de Office y sistemas de Microsoft, pelear contra esa gravedad es caro.
Multi-cloud como estrategia deliberada — el gateway portable, el framework abierto, los cuatro tiempos como lingua franca — es legítimo para quien tiene el tamaño que lo amortiza; para el resto, es complejidad comprada por miedo. La portabilidad que sí es gratis es la de la arquitectura: eso fue esta serie.

Ojo — el examen final de la serie: toma tu caso — o los dos de la Metodología, que ya tienen baseline, economía y dossier — y dibuja su plataforma en la nube que tu organización usa, justificando cada caja con su módulo. Después, como prueba de fuego, tradúcela a una segunda nube con las tablas de equivalencias. Si la traducción te tomó horas y no semanas, la serie cumplió: aprendiste el idioma, no tres dialectos sueltos.

Errores comunes (los del cierre)

Elegir nube por benchmark de un servicio. La fila que hoy gana la pierde en el próximo release; el contexto organizacional no cambia por release. La decisión es de contexto.
Multi-cloud por miedo al lock-in. El lock-in real se mitiga con arquitectura portable (esta serie) y contratos — no duplicando plataformas antes de tener una que funcione.
Llegar al módulo 12 sin dibujar nada. Tres cursos de criterios no reemplazan el ejercicio de diseñar. El examen final existe; ríndelo.
Tratar las tablas de equivalencias como traductor literal. Tres veces lo dijo la serie: son puentes con letra chica (el proyecto no es la cuenta, el despliegue no es el modelo, Service Bus no es SQS con lujos). El puente se cruza leyendo.
Olvidar qué no depende de ninguna nube. El rol mínimo, el egress corto, la idempotencia, el freno en capas, el timeout que jamás aprueba por silencio, el baseline antes del ROI — la doctrina entera de este catálogo. Las nubes sirven la plataforma; el criterio sigue siendo tuyo.

La frase para llevarse

“Tres catálogos, un solo patrón: el trabajo despierta al agente, el agente piensa por un punto único, actúa enjaulado y espera veredicto sin gastar. Elige la nube por tu contexto, tradúcela con las tablas — y quédate con lo que la serie realmente enseñó: la arquitectura es el idioma; todo lo demás es dialecto.”

Qué viene

Aquí cierra la serie de nubes — AWS como fundacional, GCP y Azure como dialectos dominados. El catálogo continúa donde la Metodología de casos de uso decide qué construir y estos tres cursos deciden sobre qué: el paso natural siguiente es el curso de Data Engineering para IA — el ciclo del dato que alimenta todo lo anterior. Y si quieres el recorrido inverso, el curso de Deploy lleva tu agente concreto a producción con tus propias manos.

Arquitectura Azure — Módulo 12: la arquitectura de referencia y el cierre de la serie