Power Platform VNet Injection: qué significan realmente "primary" y "secondary"

· 9 min de lectura

By Juan Pedro Márquez

En una configuración de Power Platform VNet injection, "primary" y "secondary" no enrutan nada. Son etiquetas declarativas en la Enterprise Policy — no una directiva de enrutamiento. El tráfico fluye hacia donde Microsoft haya colocado físicamente tu entorno, algo que confirmas con `Get-EnvironmentRegion`, no leyendo la etiqueta. Si te equivocas aquí, reconstruyes. Es el malentendido más caro que veo en estos proyectos, y se esconde a plena vista. Un equipo lee "primary VNet = West Europe" como una instrucción, aprovisiona esa VNet más grande, concentra ahí la capacidad — y luego Microsoft coloca el entorno en la región emparejada, así que el tráfico fluye por la "secondary" VNet que infra-aprovisionaron. El rendimiento se degrada, o las conexiones fallan. Ahora estás reconstruyendo el binding de la Enterprise Policy, que es disruptivo y lento. En una sesión de trabajo reciente con el equipo de plataforma de un operador de transporte europeo, detectar esto antes de que comprometieran su plan de IP colapsó un diseño de 33 VNets en un modelo ligero de dos VNets por entorno. Semanas de reconstrucción evitadas, en un solo pantallazo compartido de la salida de `Get-EnvironmentRegion`. Esta es la guía que me hubiera gustado que tuvieran desde el principio. ## ¿Las etiquetas "primary" y "secondary" enrutan el tráfico? No. En una [Enterprise Policy](https://learn.microsoft.com/en-us/power-platform/admin/vnet-support-overview) de Power Platform, las designaciones "primary" y "secondary" de VNet son metadatos declarativos. No seleccionan la ruta ni fuerzan el tráfico por una región. La [geografía Europe, por ejemplo, abarca dos regiones de Azure](https://learn.microsoft.com/en-us/power-platform/admin/vnet-support-overview) (West Europe y North Europe), y Microsoft decide en cuál de ellas vive físicamente un entorno dado. No puedes fijar la ubicación. Solo puedes declarar un par de VNets que cubra ambas regiones. El único comando que zanja la discusión es `Get-EnvironmentRegion`. Devuelve dónde está realmente el entorno. Declarar "primary = West Europe" mientras el entorno está en North Europe no cambia nada sobre la ruta del tráfico — solo da a todo el mundo una falsa sensación de control. Verifica la ubicación; no la infieras a partir de una etiqueta. ## ¿Qué regiones de Azure usa tu geografía? Como no puedes fijar la ubicación, el diseño tiene que cubrir todas las regiones que abarca tu geografía de Power Platform. Algunas geografías se corresponden con una sola región de Azure; las más grandes se corresponden con un par, y necesitas una VNet delegada en cada una. Consulta la [lista oficial de regiones soportadas](https://learn.microsoft.com/en-us/power-platform/admin/vnet-support-overview) antes de trazar un solo subnet — ese mapeo es el input de todo tu plan de IP. | Geografía Power Platform | Regiones de Azure (ilustrativo) | VNets necesarias | |---|---|---| | Europe | West Europe + North Europe | 2 (una por región) | | United States | East US + West US | 2 (una por región) | | Geografías de una sola región | una región | 1 | El patrón que hay que interiorizar: **dos o más regiones soportadas significa dos VNets, y aplica también a los entornos que no son de producción** — no solo a producción. Los equipos habitualmente planifican el par para producción y una sola VNet para dev, y luego se topan con un muro cuando la Enterprise Policy de dev no se puede crear. ## ¿Qué necesita realmente el failover de VNet injection? Como no puedes fijar la región, todo el diseño tiene que asumir que Microsoft puede colocar el entorno en cualquiera de los dos lados. Eso significa que ambas VNets deben ser de primera clase, no una primary grande y una secondary testimonial. ![What VNet-injection failover actually needs](https://hxpwtqrwvrlzxdcrcwbv.supabase.co/storage/v1/object/public/blog-images/posts/power-platform-vnet-injection-primary-secondary-myth-needs.webp) - **Dos VNets en regiones emparejadas.** Para cualquier geografía con dos o más regiones soportadas, necesitas una VNet en cada una — y aplica también a entornos que no son de producción. - **Subnets delegados de igual tamaño y adecuadamente dimensionados.** Ambos subnets delegados deben tener el mismo número de direcciones IP, y la recomendación de Microsoft es /24, no el /27 al que muchos equipos recurren. Ver [subnet delegation](https://learn.microsoft.com/en-us/azure/virtual-network/subnet-delegation-overview). - **[Peering entre las dos VNets](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview).** El failover solo funciona si el par puede comunicarse entre sí. - **[Private DNS Zones vinculadas a ambas](https://learn.microsoft.com/en-us/azure/dns/private-dns-overview) VNets** — no solo a la que llamaste "primary". - **Ubicación verificada.** Ejecuta `Get-EnvironmentRegion` sobre el entorno real antes de cerrar la capacidad. Si falta cualquiera de estos elementos, el failover silenciosamente no funciona — algo que descubres en el peor momento posible. ## Cómo configurarlo: el camino de PowerShell Todo el flujo vive en el módulo `Microsoft.PowerPlatform.EnterprisePolicies`, y es corto una vez que el diseño está bien planteado. Instálalo e impórtalo primero: ```powershell Install-Module Microsoft.PowerPlatform.EnterprisePolicies Import-Module Microsoft.PowerPlatform.EnterprisePolicies ``` Delega un subnet a Power Platform en **cada** región. Ejecuta esto una vez por cada VNet del par: ```powershell New-VnetForSubnetDelegation ` -SubscriptionId "" ` -VirtualNetworkName "vnet-pp-dev-we" ` -SubnetName "snet-powerplatform" ``` Luego crea una única Enterprise Policy que vincule **ambas** VNets — esta es la forma de dos regiones, y es el paso en el que los equipos creen erróneamente que están eligiendo una "primary": ```powershell New-SubnetInjectionEnterprisePolicy ` -SubscriptionId "" -ResourceGroupName "rg-pp-dev" ` -PolicyName "ep-pp-dev" -PolicyLocation "europe" ` -VirtualNetworkId "" -SubnetName "snet-powerplatform" ` -VirtualNetworkId2 "" -SubnetName2 "snet-powerplatform" ` -TenantId "" ``` Las dos VNets aquí son pares, no una jerarquía. Después de vincular la policy al entorno (consulta la [guía de setup and configure](https://learn.microsoft.com/en-us/power-platform/admin/vnet-support-setup-configure) para el comando exacto de vinculación y el permiso de lectura que requiere), confirma la realidad con `Get-EnvironmentRegion` y diseña en función de lo que devuelva. La referencia completa de parámetros está en la [documentación de `New-SubnetInjectionEnterprisePolicy`](https://learn.microsoft.com/en-us/powershell/module/microsoft.powerplatform.enterprisepolicies/new-subnetinjectionenterprisepolicy). ## ¿De qué tamaño deben ser los subnets delegados? Más grandes de lo que piensas, e iguales en ambos lados. La recomendación de Microsoft es /24 por subnet delegado. Los equipos habitualmente proponen /27 para "ahorrar espacio de direcciones", y luego el entorno escala, el subnet agota sus IPs, y no hay una solución limpia — porque una vez que un subnet está delegado, cambiar su rango requiere una llamada a Microsoft Support y, en la práctica, una reconstrucción del binding de la Enterprise Policy. Un subnet tampoco se puede reutilizar en varias Enterprise Policies — es un subnet delegado por policy. El coste de sobredimensionar un subnet son unos cientos de IPs privadas desperdiciadas. El coste de infradimensionarlo es una reconstrucción bajo presión. Esa asimetría debería decidir el número siempre. ## La arquitectura que realmente escala El instinto en un tenant grande es una VNet por app, o por unidad de negocio — y así es como acabas con un plan de más de 30 VNets que nadie puede operar. El patrón que aguanta es hub-and-spoke empresarial con un **par de VNets por entorno de Azure**, no por app. Da a cada entorno su propio par, direccionado con claridad para que el plan se lea de un vistazo: | Entorno | VNet Región A | VNet Región B | Subnet delegado | |---|---|---|---| | Dev | `10.10.0.0/16` | `10.11.0.0/16` | `/24` en cada una | | Test | `10.20.0.0/16` | `10.21.0.0/16` | `/24` en cada una | | Producción | `10.30.0.0/16` | `10.31.0.0/16` | `/24` en cada una | El aislamiento viene del límite del entorno, no de multiplicar VNets. Esa disciplina por entorno es la misma que hay detrás de [Copilot Studio ALM](/blog/copilot-studio-alm-pipelines-environments-solutions) — los entornos son la unidad de separación, y todo lo demás cuelga de ellos. Ese es exactamente el movimiento que convirtió una propuesta de 33 VNets en dos VNets, dieciséis subnets y ocho Enterprise Policies — el mismo aislamiento, con una fracción de la superficie operativa. Configúralo una vez con el [flujo de configuración en PowerShell](https://learn.microsoft.com/en-us/power-platform/admin/vnet-support-setup-configure) y a partir de ahí es aburrido de operar, que es el objetivo.

Gratis — Ficha de campo de VNet Injection

La referencia de una página detrás de este artículo: el checklist de failover, los tres malentendidos que cuestan una reconstrucción, y las reglas del plan de IP que hay que fijar antes de delegar un solo subnet.

Consigue la ficha de campo →
## Cómo saber si tu VNet injection está mal configurada La mayoría de las configuraciones rotas fallan de una de tres formas, y cada una se corresponde con una de las palancas anteriores: - **Latencia intermitente o timeouts que "se mueven" entre entornos.** Señal clásica de que el tráfico está aterrizando en la VNet infra-aprovisionada porque la capacidad se concentró en la "primary" declarada. Solución: pares de igual capacidad, y dejar de confiar en la etiqueta. - **Las conexiones fallan por completo tras un cambio de ubicación.** Normalmente falta el peering entre las dos VNets, o las Private DNS Zones están vinculadas solo a una de ellas. El failover no tiene ruta. Solución: haz peering de ambas VNets y vincula las zonas DNS a ambas. - **El entorno deja de aprovisionar recursos a medida que crece.** El subnet delegado ha agotado sus IPs — el impuesto del /27. Solución: no hay redimensionamiento in situ; planifica /24 desde el principio y reconstruye si ya estás atascado. El hilo conductor: nada de esto aparece en el entorno de demo. Surge bajo carga de producción, o la primera vez que Microsoft mueve tu ubicación — que es exactamente por qué el diseño tiene que estar bien antes de comprometer el plan de IP. ## El plan antes de comprometer tu plan de IP 1. **Confirma las regiones de la geografía.** Comprueba cuántas regiones de Azure usa tu geografía de Power Platform. Dos o más significa que necesitas un par de VNets. 2. **Dimensiona para /24, igual en ambos lados.** Planifica capacidad para el crecimiento ahora — redimensionar después significa Support y una reconstrucción. 3. **Haz peering de las dos VNets y vincula las Private DNS Zones a ambas.** Hazlo antes de crear la Enterprise Policy, no después. 4. **Crea una Enterprise Policy por par de entorno**, y luego vincúlala al entorno. 5. **Ejecuta `Get-EnvironmentRegion`** y diseña en función de la ubicación real — nunca de la etiqueta. Hazlo en ese orden y las palabras "primary" y "secondary" se convierten en lo que siempre fueron: etiquetas, no arquitectura. ## Preguntas frecuentes ### ¿La VNet "primary" en una Enterprise Policy de Power Platform transporta el tráfico? No. "Primary" y "secondary" son etiquetas declarativas en la Enterprise Policy; no enrutan tráfico ni seleccionan una región. Microsoft coloca físicamente el entorno en una de las regiones de Azure de la geografía, y confirmas la región real con `Get-EnvironmentRegion`. Diseña ambas VNets como iguales. ### ¿Qué tamaño de subnet necesita Power Platform VNet injection? La recomendación de Microsoft es /24 por subnet delegado, y ambos subnets de un par deben tener el mismo número de direcciones IP. Evita el /27 — se agota bajo carga, y una vez que un subnet está delegado no puedes redimensionarlo sin contactar con Microsoft Support y, en la práctica, reconstruir el binding de la Enterprise Policy. ### ¿Por qué falla el failover aunque haya declarado una VNet secondary? Porque declarar una secondary no es suficiente. El failover necesita que las dos VNets tengan peering entre sí y que las Private DNS Zones estén vinculadas a ambas — no solo a la "primary". Si falta cualquiera de las dos, el tráfico hacia la región en la que Microsoft te haya colocado no tiene una ruta funcional. ### ¿Necesito una VNet por app o por entorno? Por entorno. Hub-and-spoke empresarial con un par de VNets por entorno de Azure te da aislamiento sin disparar el número de VNets. Un plan de VNet por app se infla en decenas de redes difíciles de operar; un plan de par por entorno se mantiene ligero y escala. ### ¿Puedo reutilizar un subnet delegado en varias Enterprise Policies? No. Un subnet delegado se corresponde con una única Enterprise Policy. Si tienes tres pares de entorno, necesitas tres pares de subnets delegados — otra razón más por la que el modelo por entorno es más limpio que intentar compartir redes entre entornos.