Microsoft Azure · Associate
Microsoft Certified: Azure Network Engineer Associate
Private Endpoints, reglas de VNet y CMK requieren namespaces Premium, que se cobran por messaging unit. Standard admite reglas de firewall por IP. Este patrón usa Standard con autenticación solo Entra ID: si el requisito es red privada, hay que pasar a Premium. En AWS, SQS se conecta por un interface VPC endpoint.
Inbound y outbound no pueden compartir subnet: cada uno va en una dedicada de /28 a /24, delegada a Microsoft.Network/dnsResolvers y sin ningún otro recurso. Hay un solo resolver por VNet, los rulesets solo se linkean a VNets de la misma región y no funciona con subnets IPv6 ni con VNets que tienen virtual network encryption. Reservá las dos /28 en el diseño del hub antes de que el espacio se llene.
Con el DNS de Azure en la VNet, primero se consultan las Private DNS zones vinculadas y recién si no hay match se evalúan las reglas del ruleset (gana el sufijo más largo). En Route 53 Resolver, una regla de forward le gana a una private hosted zone con el mismo nombre. Si migrás un diseño de "reenviar todo corp.example.com a on-prem" con una zona privada del mismo nombre, el comportamiento se invierte.
El diseño típico manda la zona privada desde los spokes al inbound endpoint del hub. Si ese mismo ruleset también se linkea a la VNet del hub, las consultas del hub vuelven al hub y se arma un loop. Por eso el módulo linkea solo spokes. Si los workloads del hub necesitan resolver corp.example.com, usá un segundo ruleset sin la regla al inbound endpoint.
Si reenviás todo con ".", el DNS destino tiene que resolver nombres públicos: varios servicios de Azure dependen de eso. Algunos dominios reservados de Azure se ignoran igual en la regla comodín. Además, 168.63.129.16 no se acepta como destino de una regla, y Microsoft desaconseja el comodín en una VNet con un gateway de ExpressRoute porque puede romper la conectividad de gestión.
Si un partner administra el tenant del cliente con Lighthouse, no puede operar el resolver por esa vía: hace falta acceso directo en el tenant. Tampoco soporta FastPath de ExpressRoute ni linkear rulesets entre tenants. Para un MSP es una decisión de diseño de día uno, no un detalle de implementación.
Crear el Private Endpoint no alcanza: el FQDN <cuenta>.blob.core.windows.net tiene que resolver a la IP privada vía la zona privatelink.blob.core.windows.net vinculada a la VNet (o a tu DNS híbrido). Si resuelve a la IP pública y la cuenta tiene firewall, este rechaza la request con 403 y parece un problema de permisos.
Un environment con workload profiles (el default) necesita una subnet dedicada de al menos /27 delegada a Microsoft.App/environments; uno Consumption-only (legacy) necesita /23 y NO puede estar delegada. El tamaño no se puede cambiar después de crear el environment, y en despliegues single-revision el consumo de IPs se duplica temporalmente. Dimensioná pensando en el pico de réplicas, no en el día uno.
Con el ILB, las apps quedan en <app>.<default_domain> pero nadie resuelve ese nombre hasta que creás una zona DNS privada con el nombre del default domain, registros A "*" y "@" al static IP del environment, y la vinculás a las VNets cliente. Sin eso, la API "no existe" aunque esté corriendo.
El modo de conectividad se define al crear el servidor y no se puede cambiar. Un servidor con VNet integration no admite Private Endpoints y no se puede mover a otra subnet o VNet. Este módulo usa modo "acceso público" con public_network_access_enabled = false + Private Endpoint, que es lo que permite consumirlo desde hub-and-spoke, peerings y on-premises con el mismo modelo que el resto de los PaaS.
Letra Chica