Las dos reglas de red de la serie — nada que piense o guarde vive expuesto; el egress es una lista corta — nacieron en AWS, cruzaron a GCP y cierran aquí. Azure vuelve al modelo regional de AWS con dos rasgos propios que pesan en el diseño.

Concepto	En AWS	En GCP	En Azure
Alcance de la red	VPC regional	VPC global	VNet regional (peering para unir)
Firewall básico	Security groups	Reglas por SA/tags	NSGs (por subnet o NIC)
Acceso privado a servicios cloud	VPC endpoints	Private Google Access / PSC	Private endpoints (universal)
Salida de privadas	NAT Gateway	Cloud NAT	NAT Gateway
Egress filtrado por dominio	(proxy propio)	(proxy propio)	Azure Firewall (reglas FQDN)

La tesis del módulo

Dos rasgos definen la red Azure de la plataforma: el private endpoint es el mecanismo universal — casi todo servicio PaaS (la base, el bucket, el modelo) puede recibir una IP privada dentro de tu VNet y cerrarse al mundo — y Azure Firewall filtra el egress por nombre de dominio, volviendo la lista corta del agente legible: “puede salir a api.crm.com y a nada más” se escribe literalmente así. El resto es traducción: VNet regional con peering, NSGs como firewall, NAT para salir.

La base, rápido

La VNet es regional como la VPC de AWS (la plataforma multi-región une VNets con peering — la plomería que GCP ahorraba vuelve, con hub-and-spoke como patrón CAF para ordenarla). Las subnets parten la VNet, y los NSGs (network security groups) son el firewall de reglas — aplicados a subnets o interfaces, con application security groups para agrupar por rol y no por IP (el pariente del security-group-referenciado). El cómputo del módulo 3 se integra a la VNet para vivir en privado; NAT Gateway da la salida controlada. Nada que un lector de la serie no arme solo.

Private endpoints: el mecanismo universal

El rasgo Azure #1. Un private endpoint proyecta un servicio PaaS — la cuenta de Storage, el Cosmos DB, el servicio de modelos del módulo 7, el Key Vault — dentro de tu VNet con una IP privada, y el servicio puede entonces negar todo acceso público: existe solo para quien está en la red. Es el PrivateLink de AWS elevado a método universal: en una plataforma Azure madura, cada servicio de datos y de IA de los módulos 6, 7 y 10 lleva su private endpoint y su acceso público apagado.

Dos consecuencias operativas que en Azure son parte del diseño y no nota al pie:

DNS privado: el private endpoint funciona porque el nombre del servicio resuelve a la IP privada desde tu red — las zonas DNS privadas que lo logran son parte del despliegue (el detalle que más horas de debugging regala cuando falta: el servicio “no responde” porque el nombre sigue resolviendo a la IP pública que apagaste).
La pareja con la política: “private endpoint creado” sin “acceso público deshabilitado” es la puerta nueva junto a la puerta vieja abierta. Van juntos, y Azure Policy (módulo 1) puede exigir el par en toda la jerarquía.

Azure Firewall: la lista corta con nombres

El rasgo Azure #2, y el regalo directo al guardrail anti-trifecta de la serie: Azure Firewall (el firewall administrado que se pone como salida obligada de las subnets del agente) filtra el egress con reglas por FQDN — por nombre de dominio, no por IP:

   EL EGRESS DEL AGENTE, LEGIBLE (Azure)

  subred del agente (sin salida directa)
        │  ruta forzada (UDR)
        ▼
  ┌──────────────────────────────┐
  │ Azure Firewall               │
  │  permitir: api.crm.com       │
  │  permitir: hooks.notif.com   │
  │  denegar: todo lo demás      │
  └──────┬───────────────────────┘
         ▼
      internet (solo esos destinos)

  servicios Azure: NI PASAN POR AQUÍ
  (van por private endpoints, sin internet)

La lista corta que en AWS y GCP se armaba con IPs, proxies o disciplina, aquí se escribe con los nombres reales de los destinos — auditable de un vistazo. El costo: Azure Firewall es un servicio con precio propio no trivial; la gradación honesta es la de siempre — NSGs y rutas para el piloto, Firewall con FQDNs cuando hay datos de clientes y herramientas con salida (la columna “producción” de la tabla de escalas).

Ojo — el tráfico a los servicios de Azure no cuenta como egress: con los private endpoints del punto anterior, tu agente habla con la base, el bucket y el modelo por la red privada — ese tráfico ni toca el firewall. El egress que se filtra es el residual hacia el mundo real (las dos APIs externas del agente), que es exactamente como debe ser: la lista corta corta de verdad, porque todo lo interno ya viaja por dentro.

Errores comunes

Private endpoint sin apagar el acceso público. La puerta privada nueva junto a la pública abierta: mitad del trabajo, cero de la garantía. Van en pareja, exigida por policy.
Olvidar el DNS privado. El clásico “el endpoint no funciona”: el nombre resuelve a la IP pública apagada. Las zonas DNS privadas son parte del despliegue del endpoint, no un extra.
Egress por IP cuando hay FQDNs. Mantener listas de IPs de APIs de terceros es la fragilidad que Azure Firewall vino a jubilar. Nombres, no números.
Todo el tráfico interno por el firewall. Los servicios de Azure van por private endpoints; forzarlos por el firewall suma costo y latencia sin sumar control. El firewall filtra el residual externo.
Peering improvisado. Las VNets regionales que crecen sin plan reinventan el spaghetti que GCP evitaba. Si la plataforma será multi-región/multi-VNet, el hub-and-spoke del CAF se decide temprano.
La subred del agente con salida directa. Sin la ruta forzada al firewall, la lista corta es decorativa. UDR (ruta definida) hacia el firewall o el diseño es teatro.

La frase para llevarse

“En Azure lo privado se proyecta — cada servicio PaaS con su private endpoint y el acceso público apagado, con el DNS privado como parte del rito — y la lista corta de egress por fin se escribe con nombres: el agente puede salir a api.crm.com y a nada más, dicho literalmente así en el firewall.”

Qué viene

Módulo 5: integración — Service Bus y los despertadores. La cola enterprise de Azure (con sesiones, orden y DLQ nativo de fábrica), Event Grid como bus de eventos, Storage Queues como opción austera — y el criterio para repartirlas. Más el trío de despertadores en versión Azure y el API Management guardando la puerta.

Arquitectura Azure — Módulo 4: redes, la VNet del agente