Foundry Agent Service: una subred /27 aguanta en desarrollo y cae en produccion
Elegir 32 direcciones IP para el entorno de desarrollo parece razonable hasta que las sesiones de agente agotan la subred delegada en produccion y el fallo aparece como un 429 sin panel ni alerta que lo explique.
Un /27 parece de sobra para un entorno de desarrollo: 32 direcciones. Tres semanas despues, en produccion, los agentes hosted empiezan a fallar al crear sesion con un HTTP 429 y el codigo subnet_exhausted, el data proxy devuelve 5xx intermitentes bajo carga y el aprovisionamiento de proyectos nuevos se detiene en silencio. No hay panel en el portal que lo explique ni alerta que avise: toca rebuscar en las trazas de Application Insights para descubrir que el problema no era de red, sino de direcciones IP.
Es justo el modo de fallo que la documentacion de red de Foundry Agent Service existe para evitar, y uno de los puntos menos comentados de la plataforma, porque el aislamiento de red se vende como un "anade un private endpoint y listo". Debajo del asistente del portal hay dos planos, reglas de asignacion de IP y ratios de sesion por direccion.
Dos planos en cada peticion
Cada peticion cruza dos redes que muchos arquitectos funden mentalmente en una. La primera la gestiona Microsoft: el endpoint de Foundry (el gateway al que habla el SDK, del tipo .services.ai.azure.com), la capa de Micro VM que ejecuta los agentes hosted, el Tools Service y el data proxy. La segunda es la VNet del cliente, y Foundry solo mira dos cosas de ella: la subred delegada, donde Micro VMs e instancias del data proxy consumen direcciones IP, y la subred de private endpoints, donde viven la cuenta de Storage, Cosmos DB, Azure AI Search y Key Vault detras de Private Link.
Los dos flujos de peticion no son iguales. El de un prompt agent va del cliente al endpoint, de ahi al Tools Service, al data proxy y a los recursos del cliente por el private endpoint. El de un agente hosted mete un salto adicional por la Micro VM antes de llegar al Tools Service. No es una simplificacion del diagrama: es el comportamiento real en tiempo de ejecucion, y explica que ambos tipos de agente consuman IP de forma distinta.
Cada sesion, una IP
Cada sesion de un agente hosted corre en una Micro VM con su propia NIC en la subred delegada. El detalle que descoloca al depurar es que las llamadas a los tool servers no salen por esa NIC: pasan por el data proxy, sea cual sea el tipo de agente. Un timeout en una herramienta puede ser de la Micro VM, del proxy o de la propia subred.
El golpe real: esa subred delegada es capacidad compartida entre todos los proyectos de la cuenta Foundry. Las sesiones consumen IP como un pool de conexiones consume sockets, y nadie ofrece un grafico de utilizacion. El tamano lo decides a ciegas antes de firmar el diseno, sin red de seguridad posterior.
Ese es el motivo de fondo del "Standard Setup with private networking": mantener el trafico de los agentes dentro del perimetro del cliente, con almacenamiento, Cosmos DB y busqueda vectorial en el tenant propio. El aislamiento se lleva la parte de cumplimiento, pero el dimensionamiento se queda fuera de la conversacion. Quien aprueba la arquitectura deberia hacer antes la aritmetica de direcciones; el material de referencia cubre ademas DNS, VNet peering, solapamiento de rangos y la alternativa de la VNet gestionada.
