Captions are on by default; turn them off from the player menu. The narration uses a synthetic voice.
Transcript
Azure foundation deployment: Standard vs hub-and-spoke
Welcome to HubDat AI. In this video we deploy an Azure foundation, step by step. First the governance layer that every design needs: management groups, subscriptions and policy. Then the network, built two ways: the Standard model, with one self-contained VNet per workload, and the hub-and-spoke model, with a shared hub, Azure Firewall and peered spokes. We finish with when to move from one to the other, and the problems people hit most often.
What an Azure foundation is
An Azure foundation, often called a landing zone, is the set of shared decisions that every workload lands on. It has four parts. Governance: management groups, subscriptions, policy and tags. Identity: Entra ID groups and role assignments at the right scope, with privileged identity management for admins. Network: the address plan, VNets, internet egress, DNS and hybrid connectivity. And management: logging, diagnostics, Defender for Cloud and budgets. Build it before the first workload arrives. Retrofitting policy and networking under running applications is much harder.
Standard model vs hub-and-spoke
So which network model? The Standard model gives each workload its own self-contained VNet, with network security groups and a NAT gateway for outbound internet. It suits one to three workloads, no on-premises connection, and a small team, and it is cheap and simple. Hub-and-spoke puts shared services in a hub VNet: Azure Firewall, the VPN or ExpressRoute gateway, Bastion and DNS. Each workload gets a spoke VNet peered to the hub, and route tables force traffic through the firewall. It costs more and needs more care, but it gives you central security, one hybrid connection and consistent DNS for many workloads.
Standard model: one self-contained VNet per workload
Here is the Standard model. Each workload has its own subscription and its own VNet, with tiered subnets for web, application and data, each protected by a network security group. Private endpoints for databases and storage sit in the data subnet. A NAT gateway gives a fixed outbound address, and Bastion gives admins access without public IPs on virtual machines. The two workloads are independent, with no peering between them. Note that the address ranges still do not overlap, so you can connect them later without re-addressing.
Hub-and-spoke: shared hub, peered spokes
And here is hub-and-spoke. The hub VNet lives in a connectivity subscription and holds the shared services: Azure Firewall, the VPN or ExpressRoute gateway, Bastion and a DNS resolver. Each workload gets a spoke VNet, peered to the hub. In every spoke, a route table sends all traffic, zero dot zero dot zero dot zero slash zero, to the firewall private IP, so internet, on-premises and spoke-to-spoke traffic is inspected in one place. Central private DNS zones are linked to the hub and spokes, so private endpoints resolve the same way everywhere.
Prerequisites and IP address plan
Before you start, check the prerequisites. You need rights at the tenant root to create management groups. Agree a naming and tagging standard, and choose your primary and secondary regions. Create Entra ID groups for the platform, network, security and application teams, because roles should go to groups, not people. And sign in with the Azure CLI. Most important is the IP plan. Reserve a block for the hub, give every spoke or Standard VNet its own non-overlapping range, and make sure none of them overlap on-premises networks. Even if you start with the Standard model, plan addresses as if you will move to hub-and-spoke later.
Management groups and subscriptions
Step one applies to both models. Create a management group hierarchy under the tenant root: an organisation group, then platform, landing zones and sandbox, with a corp group under landing zones for internal workloads. Then place subscriptions into it. Platform subscriptions hold shared services, such as management and connectivity. Workloads get their own subscriptions, one per application and environment. Policy and role assignments made on a management group flow down to every subscription inside it.
Baseline Azure Policy and role assignments
Step two, also for both models, is the policy and role baseline. Start with allowed locations on the whole organisation, using the built-in policy shown here. Add policies to require cost and owner tags, send diagnostic logs to Log Analytics, and, in the corp landing zone, deny public IP addresses. Then assign roles to groups at management group scope, for example Network Contributor for the network team on the platform group. Start policies in audit mode if you have existing resources, check the compliance results, then switch to deny.
Deploy a self-contained workload VNet
Step three is the Standard model network. Create a resource group and a VNet with a slash twenty two range, then web, application and data subnets. Create a network security group for each tier and attach it to its subnet. Then add a NAT gateway with a standard public IP and attach it to the application subnet, so outbound traffic uses one fixed address that partners can allow-list. Add Bastion if admins need virtual machine access. That is a complete, secure network for one workload, and you repeat it per workload with a new address range.
Create the hub VNet and its special subnets
Now the hub-and-spoke model. Step four: create the hub VNet in the connectivity subscription. Some subnets must have exact names. AzureFirewallSubnet for the firewall, GatewaySubnet for the VPN or ExpressRoute gateway, and AzureBastionSubnet for Bastion. Use at least the sizes shown, and check the current documented minimums. Add a small subnet for the DNS private resolver inbound endpoint. Keep the hub for shared services only. Application workloads never go in the hub.
Deploy Azure Firewall with a firewall policy
Step five: deploy Azure Firewall. Install the firewall CLI extension, create a firewall policy, a standard static public IP, and then the firewall itself, attached to the hub VNet. Note the firewall private IP address, because every spoke route table points at it. Rules live in the firewall policy as rule collection groups: network rules for ports and addresses, application rules for host names. Start with an explicit allow list for what workloads need, such as Windows Update and your package repositories. Everything else is denied by default.
Create spokes and peer them to the hub
Step six: create each spoke VNet with its own range, and peer it with the hub in both directions. On the hub side, allow forwarded traffic and gateway transit. On the spoke side, allow forwarded traffic and use remote gateways, so the spoke reaches on-premises through the hub gateway. The use remote gateways option fails if the hub has no gateway yet, so add it after the gateway is deployed. Remember that peering is not transitive. Spokes never talk to each other directly; they go through the firewall.
Force spoke traffic through the firewall (UDRs)
Step seven: force traffic through the firewall with user defined routes. In each spoke, create a route table with a default route, zero dot zero dot zero dot zero slash zero, whose next hop is the firewall private IP. Disable gateway route propagation, so routes learned from on-premises do not let traffic bypass the firewall. Associate the table with every workload subnet. Then check the effective routes on a virtual machine network card. For on-premises traffic, also add a route table on the gateway subnet that sends spoke ranges to the firewall, so return traffic is symmetric.
Central private DNS for private endpoints
Step eight: central private DNS. Create the private link DNS zones once, in a shared DNS resource group, for each service you use, such as blob storage and Azure SQL. Link each zone to the hub and to every spoke. When teams create private endpoints, the DNS record lands in the central zone, and every VNet resolves the private address. For on-premises users, configure a conditional forwarder for the private link zones, pointing at the DNS private resolver inbound endpoint in the hub. A policy can create the DNS records automatically when private endpoints are deployed.
Management baseline: logs, security, cost
Step nine applies to both models: the management baseline. Create a central Log Analytics workspace and send diagnostic logs to it, starting with the firewall, gateways and key network resources. Use policy to do this automatically for new resources. Put a delete lock on the hub and other shared resource groups. Turn on Defender for Cloud for the resource types you use, set a budget with alerts on every subscription, and add activity log alerts for changes to policy, routes and network security groups.
Moving from Standard to hub-and-spoke
Many teams start with the Standard model and grow into hub-and-spoke. The signs it is time are: you need an on-premises connection, you have four or more workloads, security wants central control of outbound traffic, or an audit asks for traffic inspection. Because you planned non-overlapping ranges, the move is gradual. Build the hub, then peer each existing VNet as a spoke. Move outbound traffic one VNet at a time by adding the firewall route, then removing the NAT gateway. Consolidate private DNS zones centrally. And for many regions or branch sites, look at Azure Virtual WAN as a managed hub.
Common problems and fixes
Finally, the problems we see most often. If a spoke virtual machine loses internet access after you add the route, the firewall has no allow rule for that destination, so check the firewall logs. Spoke-to-spoke traffic fails because peering is not transitive; both spokes must route through the firewall, and a rule must allow the flow. If a private endpoint resolves to a public address, the DNS zone is not linked to that VNet, or your custom DNS is not forwarding the private link zones. If peering fails with use remote gateways, the hub gateway does not exist yet. And if a deployment is blocked, the error names the policy, so fix the resource or request an exemption.
Full guides on HubDatAI
That is a complete Azure foundation, built the Standard way and the hub-and-spoke way. For the detailed written guides, including the landing zone foundation, the hub-and-spoke network, moving to Virtual WAN and resource locks, visit HubDat AI dot com. Thanks for watching.