Microsoft Azure · Associate
Microsoft Certified: Azure Network Engineer Associate
Private Endpoints, VNet rules and CMK require Premium-tier namespaces, which are billed per messaging unit. Standard supports IP firewall rules. This pattern uses Standard with Entra ID-only auth: if the requirement is private networking, you have to move to Premium. In AWS, SQS connects through an interface VPC endpoint.
Inbound and outbound can't share a subnet: each goes in a dedicated /28 to /24, delegated to Microsoft.Network/dnsResolvers and with no other resources. There's one resolver per VNet, rulesets only link to VNets in the same region, and it doesn't work with IPv6 subnets or VNets with virtual network encryption. Reserve both /28s in the hub design before the address space fills up.
With Azure DNS on the VNet, linked Private DNS zones are checked first, and only if nothing matches are ruleset rules evaluated (longest suffix wins). In Route 53 Resolver, a forward rule beats a private hosted zone with the same name. If you migrate a "forward all of corp.example.com to on-prem" design with a private zone of the same name, the behavior flips.
The typical design sends the private zone from spokes to the hub's inbound endpoint. If that same ruleset is also linked to the hub VNet, the hub's queries come back to the hub and loop. That's why the module links only spokes. If hub workloads need to resolve corp.example.com, use a second ruleset without the rule to the inbound endpoint.
If you forward everything with ".", the target DNS must resolve public names: several Azure services depend on it. Some reserved Azure domains are ignored by the wildcard rule anyway. Also, 168.63.129.16 isn't accepted as a rule target, and Microsoft advises against the wildcard in a VNet with an ExpressRoute gateway because it can break management connectivity.
If a partner manages the customer's tenant with Lighthouse, it can't operate the resolver that way: it needs direct access in the tenant. It also doesn't support ExpressRoute FastPath or linking rulesets across tenants. For an MSP that's a day-one design decision, not an implementation detail.
Creating the Private Endpoint is not enough: the FQDN <account>.blob.core.windows.net must resolve to the private IP via the privatelink.blob.core.windows.net zone linked to the VNet (or your hybrid DNS). If it resolves to the public IP and the account has a firewall, it rejects the request with 403 and looks like a permissions issue.
A workload profiles environment (the default) needs a dedicated subnet of at least /27 delegated to Microsoft.App/environments; a Consumption-only (legacy) one needs /23 and must NOT be delegated. The size can't be changed after the environment is created, and single-revision deployments temporarily double IP usage. Size for peak replicas, not day one.
With the ILB, apps live at <app>.<default_domain> but nobody resolves that name until you create a private DNS zone named after the default domain, "*" and "@" A records pointing to the environment's static IP, and link it to the client VNets. Without it, the API "doesn't exist" even though it's running.
The connectivity mode is set at server creation and can't be changed. A VNet-integrated server doesn't support Private Endpoints and can't be moved to another subnet or VNet. This module uses "public access" mode with public_network_access_enabled = false + Private Endpoint, which lets it be consumed from hub-and-spoke, peerings and on-premises with the same model as other PaaS services.
Letra Chica