Este curso abre una serie de tres — AWS, GCP y Azure — con una premisa que lo distingue de casi todo el material cloud que existe: no vamos a configurar nada. No hay pantallazos de consola ni tutoriales de clics. Lo que vamos a construir, módulo a módulo, es la arquitectura base de una plataforma de agentes de IA: los diagramas, los criterios de decisión y los trade-offs que hacen que un agente 100% autónomo — uno que despierta solo, trabaja solo y gasta plata solo — pueda operar en la nube sin que su dueño viva pegado a un dashboard. La configuración se aprende en una tarde con la documentación; la arquitectura mal decidida se paga durante años.

AWS es el curso fundacional de la serie: aquí se enseñan los conceptos y su aterrizaje AWS. Los cursos de GCP y Azure asumirán estos conceptos y dedicarán su espacio a las diferencias. Y el punto de partida no es ningún servicio — es el mapa.

La tesis del módulo

Antes de elegir un solo servicio, la arquitectura de un agente de IA en AWS exige tres decisiones de mapa: en qué cuenta vive (aislamiento), en qué región corre (latencia, datos y catálogo de servicios) y qué parte del stack es tu responsabilidad (modelo compartido). Los proyectos que fracasan en cloud rara vez eligieron mal un servicio; eligieron no decidir el mapa, y todo lo que construyeron encima heredó ese vacío.

La cuenta: la unidad de aislamiento real

En AWS, la cuenta (account) no es un login: es la frontera dura de aislamiento — de permisos, de facturación, de límites de servicio y de radio de explosión (blast radius: hasta dónde llega el daño cuando algo sale mal). Todo lo que existe en AWS existe dentro de una cuenta, y dos recursos en cuentas distintas no se ven salvo permiso explícito.

La decisión de arquitectura número uno es cuántas cuentas y cómo repartirlas. La práctica madura no es una cuenta gigante con todo adentro, sino varias cuentas por función, gobernadas por AWS Organizations (el servicio que agrupa cuentas bajo una organización, con políticas y facturación consolidada):

        ORGANIZACIÓN AWS TÍPICA PARA UNA
        PLATAFORMA DE AGENTES DE IA

              ┌────────────────────┐
              │  cuenta management │  facturación,
              │  (organización)    │  políticas SCP
              └──────────┬─────────┘
                         │
        ┌──────────┬─────┴────┬───────────┐
        ▼          ▼          ▼           ▼
  ┌──────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
  │ seguridad│ │ dev     │ │ prod    │ │ sandbox │
  │ logs,    │ │ agentes │ │ agentes │ │ pruebas │
  │ auditoría│ │ en des. │ │ en prod │ │ libres  │
  └──────────┘ └─────────┘ └─────────┘ └─────────┘

¿Por qué importa esto para agentes? Porque un agente autónomo es exactamente el tipo de workload que quieres poder aislar y limitar por diseño: un agente en sandbox que entra en bucle no puede tocar producción ni quemar su presupuesto, porque la frontera de cuenta lo impide sin que nadie escriba una regla. Las SCP (Service Control Policies: políticas de la organización que limitan qué puede hacerse en cada cuenta, por encima de cualquier permiso individual) son el techo duro — “en sandbox nadie puede usar instancias caras”, “en prod nadie puede desactivar los logs” — y aplican incluso al administrador de la cuenta.

Ojo: este patrón multi-cuenta tiene nombre en AWS: es la landing zone — y es la misma landing zone conceptual del módulo de la metodología, ahora en su capa de infraestructura. AWS la ofrece semi-armada con Control Tower (el servicio que despliega la estructura multi-cuenta con guardrails preconfigurados). Para este curso basta con entender el patrón; el mensaje de arquitectura es que la separación dev/prod/seguridad se decide el día 1, porque migrar recursos entre cuentas después es de las tareas más caras que existen.

Regiones y zonas: dónde corre físicamente

Región (region): un conjunto geográfico independiente de data centers (us-east-1 en Virginia, sa-east-1 en São Paulo). Las regiones no comparten nada por defecto: recursos, precios y catálogo de servicios varían entre ellas. Para Chile, al escribir esto (septiembre de 2026) la región más cercana sigue siendo São Paulo: AWS anunció en mayo de 2025 una región South America (Chile) con tres AZs, prevista para fines de 2026 — el día que abra, el criterio de residencia de datos cambia de respuesta para muchos casos locales.
Zona de disponibilidad (AZ, availability zone): cada región tiene 3+ AZs — data centers separados con energía y red independientes, conectados con latencia mínima. La alta disponibilidad básica en AWS es “corre en ≥2 AZs”; los servicios administrados suelen hacerlo por ti.

Para una plataforma de agentes, la elección de región tiene tres criterios, en este orden:

Criterio	Pregunta	Impacto en agentes de IA
Datos	¿Alguna ley o contrato exige residencia?	Si los datos no pueden salir del país, la región está decidida (o el caso cambia)
Catálogo	¿Están los servicios de IA que necesito?	Bedrock y los modelos nuevos llegan primero a us-east-1/us-west-2; regiones chicas esperan meses
Latencia	¿Quién consume las respuestas y desde dónde?	Para agentes batch/autónomos importa poco; para chat en vivo, sí

Cuidado: el criterio 2 pesa más en IA que en cloud tradicional. Un stack clásico (VMs, bases, colas) existe en toda región; el catálogo de modelos y funciones de Bedrock, no. La respuesta de AWS a esto es la inferencia cross-region (perfiles que enrutan la llamada al modelo hacia otras regiones — del mismo ámbito geográfico o, en los perfiles globales que existen desde 2025, de cualquier región comercial — para conseguir capacidad): resuelve capacidad, pero implica que tu prompt cruza fronteras — lo que conecta directo con el criterio 1. Si tu política de datos dice “nada sale del país” y tu perfil de inferencia dice “enruta a Virginia”, tienes un problema de arquitectura, no de configuración.

Responsabilidad compartida: qué es tuyo aunque sea administrado

El modelo de responsabilidad compartida (shared responsibility model) es el contrato conceptual de toda la nube: AWS es responsable de la nube (hardware, data centers, el software del servicio); tú eres responsable de lo que pones en la nube (tus datos, tus permisos, tu configuración). La versión para plataformas de agentes:

Capa	AWS responde por	Tú respondes por
Física	Data centers, hardware, red troncal	—
Servicio administrado	Que Bedrock/Lambda/S3 funcionen	Cómo los configuras y qué les das
Identidad	El motor de IAM	Cada permiso que otorgas
Datos	Durabilidad del almacenamiento	Clasificación, cifrado, quién accede
Agente	—	Todo: qué hace, qué gasta, qué toca

La última fila es el punto ciego típico: usar servicios administrados de agentes (módulo 9) no transfiere la responsabilidad por lo que el agente hace. Si tu agente autónomo borra datos de un cliente, AWS operó el runtime perfectamente — el diseño de permisos y límites que lo permitió es tuyo. Todo este curso es, en el fondo, el diseño de esa última fila.

El mapa de la serie: los 12 módulos

Con el mapa puesto, así se construye la plataforma — cada módulo una capa, del cimiento al agente:

Bloque	Módulos	Capa
Básico	1-4	El mapa · identidad (IAM) · cómputo · redes
Intermedio	5-8	Microservicios y APIs · estado y datos · LLM gateway · FinOps
Avanzado	9-12	Servicios de agentes (AgentCore) · seguridad · operación autónoma · arquitectura de referencia

El módulo 12 termina con el diagrama completo del agente 100% autónomo en AWS, con cada decisión de los módulos anteriores marcada en él.

Errores comunes

Empezar por los servicios y no por el mapa. “¿Uso Lambda o ECS?” antes de decidir cuentas, región y responsabilidad es amueblar una casa sin saber en qué terreno está. Las tres decisiones de mapa condicionan todas las demás.
Una sola cuenta para todo. Dev, prod y experimentos en la misma cuenta significa que el radio de explosión de cualquier error — humano o de agente — es total. La frontera de cuenta es el aislamiento más barato que AWS ofrece: es gratis y es dura.
Elegir región solo por latencia. Para agentes de IA, el catálogo de modelos y la residencia de datos pesan más que 40 ms de diferencia. La tabla de tres criterios se recorre en orden.
Asumir que “administrado” = “no es mi problema”. El modelo compartido no tiene excepciones por marketing: la configuración, los permisos y el comportamiento del agente son tuyos en todos los servicios, incluidos los más administrados.
Ignorar las SCP hasta que duele. El límite duro organizacional (“esto no se puede hacer en esta cuenta, punto”) es el único guardrail que un permiso mal otorgado no puede saltarse. Para agentes autónomos, es la diferencia entre incidente y anécdota.
Tratar la landing zone como burocracia enterprise. Aunque seas un equipo de tres personas, la separación mínima (una cuenta prod, una de todo lo demás) cuesta una hora hoy y evita la migración imposible de mañana.

La frase para llevarse

“La arquitectura en AWS empieza con tres preguntas que no mencionan ningún servicio: ¿en qué cuenta vive?, ¿en qué región corre?, ¿qué parte es mía aunque sea administrada? El que responde eso primero construye sobre un mapa; el que no, construye sobre la página de precios.”

Qué viene

Módulo 2: identidad — IAM y el agente como principal. Todo lo que ocurre en AWS es una llamada a una API, y toda llamada la hace una identidad con permisos. Para un agente autónomo eso tiene una consecuencia enorme: el agente es una identidad de IAM, con sus roles, sus políticas y su mínimo privilegio — y diseñar esa identidad es diseñar qué puede hacer tu agente cuando nadie lo mira. Vamos a entender usuarios vs. roles, políticas, credenciales temporales, y el patrón que gobierna todo el curso: el agente nunca tiene más permisos que la tarea que ejecuta.

Arquitectura AWS — Módulo 1: el mapa de AWS