Puntos clave
- Trata el POC y el MVP como arquitecturas distintas, no como carpetas
.envrenombradas. - Dibuja el ingress y el egress como cajas separadas; un private endpoint no es una integración con VNet.
- Haz inventario de las zonas DNS privadas y de las VNet a las que están vinculadas antes de llamar privado a algo.
- Endurece Entra (managed identity, roles de aplicación, Conditional Access) cuando endurezcas la red.
- Pasa los secretos a referencias de Key Vault a través de redes privadas; no promuevas los marcadores de posición del POC.
- Deja que la red y la identidad decidan la etiqueta de la etapa; los archivos de configuración van detrás.
Un POC público demuestra el ciclo del producto. Un MVP privado demuestra que sobrevives a una red cerrada.
Son arquitecturas distintas. No finjas la segunda añadiendo más archivos env.
El POC optimiza para aprender el ciclo del agente. El MVP optimiza quién puede llegar a qué y en qué plano.
Modelo con nombre: etapas por plano
- Ingress: público o filtrado por IP en el POC; private endpoint para el shell del MVP y las API críticas.
- Egress: integración regional con VNet en el MVP (route-all cuando haya que inspeccionar el tráfico saliente).
- DNS privado: inventario de zonas y de las VNet a las que están vinculadas, para que los nombres se resuelvan a IP privadas.
- Identidad: managed identity para la app, Entra más roles de aplicación para los usuarios y una accesibilidad clara de la plataforma de agentes.
- Regla: la red y la identidad deciden la etiqueta de la etapa. Los archivos env van detrás. Un hostname público con secretos del POC sigue siendo una demo.
Figura 1. Etapas por plano. El POC puede ser público o filtrado por IP. El MVP necesita ingress privado, egress privado, DNS vinculado e identidad endurecida. Renombrar carpetas no mueve el plano.
Contexto y restricción
Los shells de agentes pueden pasar de "funciona en mi máquina" a "bloqueado por el DNS privado" en un solo paso. El modelo no ha empeorado. Ha cambiado el plano de red.
Un ingress público (o una lista de IP permitidas muy acotada) es una elección legítima para un POC. Los private endpoints, la integración con VNet, las zonas DNS privadas y las referencias de Key Vault son la elección para un MVP. No son el mismo diagrama con otros valores en .env.
Microsoft es explícito sobre esta separación en App Service: un private endpoint cubre el acceso privado entrante a la app. La integración regional con VNet cubre las llamadas salientes de la app hacia la red virtual. A menudo necesitas las dos. Confundirlas en un README es como los equipos acaban entregando un "MVP" que sigue respondiendo en el hostname público.
La figura 2 es el patrón de private endpoint de Learn para App Service. Trátalo como control del tráfico entrante, no como sinónimo de "todo privado".
Figura 2. Patrón de private endpoint para App Service. El acceso privado entrante no es acceso privado saliente. Fuente: Microsoft Learn: App Service private endpoints.
Separa las etapas por las diferencias que de verdad quieres decir
Escribe una tabla de arquitectura antes de clonar carpetas.
POC. Ingress público o filtrado por IP. Iteración más rápida. Endpoints de la plataforma de agentes que quizá sigan siendo accesibles desde internet. Secretos de corta duración o App Settings acotados. Suficiente Entra para que la gente inicie sesión y para demostrar los roles de aplicación. Sirve para el comportamiento del shell, el chat en streaming y los ciclos de subida.
MVP. Private endpoints en la API del shell y en las dependencias del plano de datos que no deben ser públicas. Integración con VNet para que la app pueda llamar a Key Vault, storage y endpoints de la plataforma privados. DNS privado vinculado a la VNet de integración para que los nombres se resuelvan a IP privadas. Una identidad más clara: managed identity para la app, roles de aplicación para los usuarios y Conditional Access donde haga falta. Los responsables de red, DNS privado y monitorización pasan a ser protagonistas.
Lo que se comparte: las formas del producto (SPA, API, interfaces de agentes), el modelo de autorización y la matriz de pruebas de roles. Lo que nunca debe pasar a la siguiente etapa: cadenas de conexión sobrantes, credenciales antiguas del registro y reglas públicas de permiso "temporales".
1. Dibuja el ingress y el egress como cajas separadas
El acceso privado entrante no es acceso privado saliente. Los private endpoints ponen la app (o una dependencia) en una IP privada para quienes llaman desde la red. La integración con VNet permite que los workers de App Service lleguen a recursos privados a través de una subred delegada. Microsoft documenta que esas subredes no deben ser la misma. Si tu diagrama tiene una sola nube con la etiqueta "privado", vuelve a dibujarlo. La figura 3 muestra la separación.
Figura 3. El ingress y el egress son cajas separadas. El private endpoint controla quién puede llegar al shell. La integración con VNet controla cómo llega el shell a Key Vault, storage y los endpoints de la plataforma.
2. Trata el DNS privado como una dependencia del producto
El fallo casi siempre está en el DNS: el hostname se sigue resolviendo como público, o como privado para una subred y no para otra. Vincula las zonas de Azure Private DNS a la VNet con la que se integra la app. Si usas un DNS propio, asegúrate de que reenvía correctamente. No te pases tres días depurándolo como si fuera un bug de la aplicación.
3. Endurece Entra cuando endurezcas la red
Las apps de agentes para usuarios siguen necesitando una historia de identidad clara cuando se cierra la red. Entra decide quién puede abrir el shell. Los roles de aplicación de la API siguen decidiendo qué funciones y rutas de agentes existen. El aislamiento de red reduce quién puede tocar el plano. No sustituye la autorización por agente. Las dos capas importan; resuelven amenazas distintas.
La figura 4 es el recordatorio de Learn de que las apps para usuarios siguen necesitando una historia de identidad cuando se endurece la red.
Figura 4. Las apps para usuarios siguen necesitando una historia de identidad clara cuando se endurece la red. Fuente: Microsoft Learn: authentication flows and app scenarios.
4. Saca los secretos del "gitignore para siempre"
Los App Settings del POC y los archivos .env locales valen para un spike. El MVP debería usar referencias de Key Vault (o algo equivalente) accesibles a través de redes privadas cuando el estándar de la plataforma lo exija. Los secretos de larga duración en plantillas que se pueden clonar son el próximo incidente.
5. Haz inventario de registros, planes y roles
Los container registries, las SKU de los planes de App Service y las asignaciones de roles de las managed identities no son intercambiables entre etapas sin un diagrama. Un MVP privado suele necesitar un plan de nivel superior para la integración con VNet y los private endpoints. Presupuéstalo como arquitectura, no como un coste sorpresa.
Errores comunes
El teatro de los archivos env.
Doce plantillas llamadas poc, mvp, prod que solo cambian URL mientras la red sigue siendo pública. El README dice MVP. Internet público dice otra cosa.
Private endpoint sin DNS privado. La app parece privada en el portal y aun así se resuelve mal. Los síntomas parecen errores 403 y timeouts aleatorios.
Dar por hecho que la integración con VNet cierra el ingress. La integración saliente no hace privada la app. Sigues necesitando private endpoints o restricciones de acceso para controlar el tráfico entrante.
La identidad se aplaza hasta "después de la red". Endureces el plano y dejas a cada usuario con sesión iniciada como operador de agentes de confianza. Los controles de red protegen el plano; no sustituyen la autorización por función.
Los secretos del POC se promueven en bloque. Marcadores de posición antiguos, claves compartidas y endpoints públicos de storage se cuelan en el MVP porque alguien copió la carpeta.
Una sola subred para todo. Los private endpoints y la integración con VNet se pelean por la misma subred delegada. La plataforma no se va a inventar capacidad por ti.
Úsalo tal cual o adáptalo
Úsalo tal cual
- Modelo de ingress por etapa (público o filtrado por IP en el POC; private endpoint para el shell del MVP y las API críticas).
- Modelo de salida del MVP (integración regional con VNet, route-all si hay que inspeccionar el tráfico saliente).
- Inventario de zonas DNS privadas y de las VNet a las que están vinculadas.
- Identidad para la app (managed identity), los usuarios (Entra + roles de aplicación) y la accesibilidad de la plataforma de agentes.
- Ubicación y rotación del almacén de secretos; nada de secretos de larga duración en archivos bajo gitignore como plan a largo plazo.
- Regla de promoción: la red y la identidad deciden la etiqueta de la etapa; los archivos de configuración van detrás. Las excepciones públicas necesitan un responsable y una fecha de revisión.
Figura 5. Controles de promoción, no teatro de archivos env. Primero la red y la identidad. Los secretos van detrás, por acceso privado. Solo entonces la etapa se gana la etiqueta MVP.
Adáptalo antes de usarlo
Montar un MVP privado lleva más tiempo. Necesitas a los responsables de red, DNS e identidad en la sala. La velocidad del POC cae cuando cada cambio espera a un private link.
Pierdes comodidad: demos desde el portal y curl desde fuera de la VNet. Planifica una VPN o un acceso por bastion en lugar de volver a abrir en silencio el ingress público. Los flujos on-behalf-of son más difíciles de depurar cuando el egress está cerrado; mantén separadas las pruebas de identidad y las de red para saber qué plano se ha roto.
Referencias principales: App Service private endpoints, App Service VNet integration y authentication flows and app scenarios.
Si tu MVP sigue siendo accesible en un hostname público con secretos del POC, no tienes un MVP. Tienes una demo más ruidosa.