Design Azure network architecture, connectivity, delivery, and protection
Turn workload evidence into IP, segmentation, routing, hybrid connectivity, application delivery, and defense-in-depth decisions.
Suggested study time: 82 minutes • Intermediate • Complete original rewrite with a concise summary for every topic
By João Ricardo Dutra••Complete original content
1. Translate workload evidence into network decisions
A global retailer moving internal and internet-facing applications to several Azure regions needs more than connectivity. Architects must preserve access for employees and customers, connect application and data dependencies, support AI-ready services, and make latency, availability, security, operations, and cost measurable.
Recommend connectivity from Azure resources to the internet and to on-premises networks.
Select a topology and services that improve network performance and security.
Choose load-balancing and traffic-routing services at the correct scope and protocol layer.
Protect public, private, east-west, and management flows with complementary controls.
Topic summary
Begin with users, locations, protocols, dependencies, trust boundaries, scale, failure objectives, and operating ownership; a product name is the result, not the starting point.
2. Establish the network requirements baseline
Create a durable naming convention and place resources in regions close to consumers while respecting data, service, and resiliency constraints. A virtual network belongs to one region, but peering and transit services can connect regions. Decide how subscriptions, resource groups, and tenants divide ownership before deploying network resources.
Define private address spaces, subnet segmentation, interface and private-IP demand, filtering, DNS, routing, egress, ingress, observability, and quotas. Network security groups and network virtual appliances control flows, while Azure system routes provide initial subnet connectivity that custom routes can override.
Topic summary
A complete baseline covers organization, location, addressing, segmentation, filtering, routing, DNS, scale limits, observability, and ownership.
3. Plan address space and subnet capacity
Every subnet uses one nonoverlapping CIDR range inside its virtual-network address space. Reserve capacity for platform addresses, growth, private endpoints, gateways, scale sets, and future regions. A three-tier workload can isolate front end, application, and database tiers in separate subnets and attach different policies to each boundary.
Illustrative segmentation of 10.245.16.0/20.
Subnet
CIDR
Usable addresses
Purpose
DEV-FE-EUS2
10.245.16.0/22
1,019
Front-end or web-tier virtual machines
DEV-APP-EUS2
10.245.20.0/22
1,019
Application-tier virtual machines
DEV-DB-EUS2
10.245.24.0/23
507
Database virtual machines
Avoid allocating more than /16 to one virtual network because Azure supports up to 65,536 addresses per VNet and excess space cannot be used there. Never overlap Azure and on-premises ranges. Redesign overlaps whenever possible; NAT is a constrained workaround, not the preferred address plan.
Topic summary
Allocate nonoverlapping CIDR blocks with realistic growth and service reservations; an address plan must remain routable across every future hybrid and regional connection.
4. Hub-spoke centralizes shared connectivity and security
A hub virtual network hosts shared services such as VPN or ExpressRoute gateways, firewalls, DNS, and management. Peered spoke virtual networks isolate individual workloads and can contain several application subnets and internal load balancers. Hubs and spokes can live in different resource groups or subscriptions, including subscriptions associated with different tenants when peering is authorized.
Centralize shared transit and security in hubs while delegating each spoke workload to its owning team.
Topic summary
Hub-spoke balances decentralized workload ownership with centralized transit, inspection, and shared services.
5. Pattern one: a single virtual network
A single VNet can contain the entire workload when it operates in one region and the scale and ownership model remain manageable. Subnets create tiers; NSGs limit allowed flows; application security groups simplify rules around logical groups of interfaces. An Azure Marketplace NVA or can add stronger segmentation and inspection.
Topology should grow only as isolation, regional, ownership, or transit requirements justify it.
Topic summary
Choose one VNet for a bounded single-region footprint, then enforce tier boundaries with subnets, NSGs, ASGs, and any required firewall.
6. Pattern two: multiple peered virtual networks
Separate VNets isolate applications or regions and communicate only after explicit peering. System routes connect address ranges across the peering and NSGs add finer controls inside each VNet. Peering is not transitive: if VNet A peers with B and B peers with C, A does not automatically reach C.
This pattern distributes management cleanly but multiplies peerings, policy, logging, and route coordination as the estate grows. Add a transit hub when point-to-point relationships become hard to govern.
Topic summary
Peering gives low-latency private connectivity and strong VNet boundaries, but every required relationship and transit path must be designed explicitly.
7. Pattern three: regional hubs with workload spokes
Each region can use a hub that peers with its spokes and connects to other regional hubs. Traffic that must cross spokes is steered through a Layer-3 transit component such as . Security policy and accepted or denied traffic logging concentrate at the hubs, so adding a spoke does not require duplicating the complete security stack.
A spoke that accidentally exposes a port should still be protected by the intended stateful transit path, but architects must validate routing symmetry. Manager can apply global policies across firewalls while allowing controlled local policy extensions for workload teams.
Topic summary
Multi-hub-and-spoke scales regional isolation and centralized inspection, provided transit, route symmetry, and policy inheritance are deliberately engineered.
8. Compare connectivity and segmentation controls
Topology comparison.
Concern
Single VNet
Peered VNets
Hub-spoke
Connectivity
System routing connects subnets.
Peering connects selected VNets; no transitivity.
Spokes need transit through the hub for spoke-to-spoke flows.
Filtering
Traffic is initially allowed; use NSGs/firewall.
Use NSGs per VNet and boundary.
Deny or inspect transit centrally with /NVA.
Logging
Collect VNet and NSG evidence.
Aggregate evidence across VNets.
Central firewall logs accepted and denied transit to .
Application protection
NSGs operate at the network layer.
NSGs operate at the network layer.
Firewall adds Layer 3–7 controls and FQDN-based egress policies.
Operating model
Simplest, least isolated.
Distributed ownership with peering overhead.
Central platform team plus delegated spokes.
Topic summary
Use the smallest topology that meets isolation, regional, transit, security, and team-boundary requirements without creating unmanageable relationships.
9. Understand route sources and route tables
Azure creates system routes that support traffic inside a VNet, toward the internet, and for supported gateway scenarios. You cannot edit system routes, but a user-defined route (UDR) can override or extend them. Peering adds routes for the peer address spaces; a virtual network gateway can propagate routes learned through BGP; enabling a service endpoint adds service address routes to the selected subnet and Azure maintains those prefixes.
Effective routing is the result of every applicable route source, not just the custom route table.
Topic summary
Inventory system, UDR, BGP, peering, and service-endpoint routes when explaining the effective next hop.
10. Longest prefix and source priority select the route
Azure first chooses the most specific destination prefix. If routes with the same prefix compete, the general precedence is UDR, then BGP, then system route. Effective routes on a network interface reveal the combined result and should be checked during validation and incident response.
Use UDRs to steer subnet traffic through or an NVA, to define explicit next hops, or to force internet-bound traffic through a security path or an on-premises gateway. Enable IP forwarding on a forwarding NVA and preserve symmetric return paths.
Topic summary
Route selection is longest-prefix first and UDR-over-BGP-over-system for equal prefixes; always validate the effective route and return path.
11. Design explicit outbound connectivity
For APIs created after March 31, 2026, new VNets default to private subnets and require an explicit outbound method to reach public endpoints. Do not depend on an implicit Microsoft-owned address that can change. Choose Azure , or another NVA, a public IP on the resource, or outbound rules according to security and operating requirements.
Explicit egress provides predictable addresses, capacity, policy, monitoring, and ownership.
: scalable outbound-only source NAT with static public IPs or prefixes, idle-timeout control, and TCP reset.
/NVA: centralized inspection, filtering, logging, and optionally forced tunneling.
Public IP: direct exposure and lifecycle per resource; use only when the workload requires it.
outbound rules: bind egress to a load-balancing design and allocate SNAT deliberately.
Topic summary
Every production subnet should have an intentional egress policy, address, capacity model, route, inspection decision, and failure plan.
12. encrypts hybrid traffic over the internet
Azure is a virtual network gateway that carries encrypted traffic between Azure and remote networks. Site-to-site connects a datacenter or branch, point-to-site connects individual users, and VNet-to-VNet connects virtual networks through IPsec/IKE. Select the gateway SKU, active-active or active-standby mode, availability-zone design, BGP, protocol, and throughput from the workload.
Topic summary
is the managed encrypted internet path for sites, users, or VNets; resilience and performance depend on the selected topology and SKU.
extends an on-premises network into Microsoft cloud services through a connectivity provider without traversing the public internet. It supplies Layer-3 connectivity, dynamic BGP routing, and redundant Microsoft edge connections, with more consistent latency and throughput than an internet VPN for demanding workloads.
Redundancy inside one circuit is not complete site resilience. Critical solutions can use circuits in separate peering locations and combine ExpressRoute with so an encrypted internet path is available if the private circuit fails. Test route preference, convergence, bandwidth, and failure regularly.
Select private or encrypted-internet connectivity from availability, performance, security, provider, and cost requirements.
Topic summary
ExpressRoute is private provider connectivity; resilient architecture still needs redundant locations, edge equipment, routing, and a tested fallback where required.
14. provides Microsoft-managed global transit
Azure replaces customer-managed regional hubs with managed virtual hubs. It brings site-to-site VPN, point-to-site user VPN, ExpressRoute, VNet connections, routing, and supported security services into one operating interface. Standard automatically connects hubs over the Microsoft backbone and enables branch-to-VNet, branch-to-branch, VNet-to-VNet, and mixed connection scenarios.
Use when many branches, regions, or connection types justify automated global transit and centralized management. A conventional hub-spoke design can remain more economical or more controllable for a smaller estate. Secured virtual hubs and routing intent can steer private and internet traffic through or a supported security provider.
turns hubs and global transit into a Microsoft-managed service.
Topic summary
is a scale and operations choice: prefer it when managed any-to-any transit across many branches and regions offsets its service and processing cost.
15. Frame the application-delivery decision
Classify traffic as HTTP/HTTPS, TCP/UDP, or DNS-directed; public or private; regional or global. Then compare SLA, latency, failover, TLS termination, WAF, path routing, session affinity, endpoint health, network isolation, service limits, operating cost, and service cost. Evaluate each workload separately because one application can require several delivery layers.
Topic summary
Protocol layer, exposure, geographic scope, acceleration, security processing, availability, and cost narrow the delivery-service choice.
16. Use a decision flow, then validate the complete design
A decision tree creates a shortlist; architecture validation decides the final combination.
A private regional web application points toward ; regional non-HTTP traffic points toward . Global public web traffic that needs edge acceleration points toward . Global DNS redirection without a proxy can use Azure Traffic Manager, often in combination with regional services. can participate when an existing API gateway needs backend balancing, but should not be purchased solely as a generic load balancer.
Topic summary
Treat the flowchart as a starting hypothesis and validate each candidate against the real workload, regional design, limits, security, and failure tests.
17. delivers global web applications at the edge
Standard and Premium are global Layer-7 services for HTTP/HTTPS applications, APIs, dynamic content, and delivery. Anycast edge ingress, health probes, latency-, priority-, and weight-aware routing, rapid global failover, TLS offload, URL/path routing, session affinity, and WAF can improve worldwide availability and performance. Premium can connect privately to supported origins through .
classic retires on March 31, 2027 and should be migrated to Standard or Premium. Protect origins so clients cannot bypass the edge policy, and measure cache behavior, probe design, failover, certificates, WAF, rules, and data-processing cost.
Topic summary
Choose Front Door for globally distributed web delivery, acceleration, failover, and edge security; migrate classic profiles before retirement.
18. Azure Traffic Manager directs clients through DNS
Azure Traffic Manager is a global DNS-based traffic load balancer. It returns the selected public endpoint according to priority, weighted, performance, geographic, multivalue, or subnet routing and monitors endpoint health. The client then connects directly to that endpoint; Traffic Manager is not a traffic proxy and provides no Layer-7 payload processing.
It can combine Azure and external endpoints for availability, performance, hybrid migration, maintenance, and complex nested profiles. DNS caching and TTL affect failover time, so health probes, resolver behavior, endpoint capacity, and regional services must be tested together.
Topic summary
Use Traffic Manager for global DNS redirection across public Azure or external endpoints when direct client-to-endpoint traffic is acceptable.
19. handles high-performance Layer-4 flows
Azure distributes TCP and UDP connections with low latency across healthy backend instances. Public and internal frontends support internet-facing or private applications; health probes and rules map frontend addresses and ports to backend pools. It can also participate in inbound and explicit outbound connectivity.
does not inspect URLs, terminate application-aware WAF policy, or make content-based routing decisions. For HTTP applications that need Layer-7 behavior, compare and Front Door.
Topic summary
Choose for regional or cross-region Layer-4 TCP/UDP distribution and private internal balancing without HTTP-aware processing.
20. controls regional application traffic
Azure is a regional application delivery controller for Layer-7 web traffic and supports HTTP/HTTPS capabilities such as TLS termination, URL/path routing, multiple-site hosting, session affinity, redirects, autoscaling, and . A private frontend can deliver an internal web application without making it internet-facing.
Path-based routing sends different URL paths to different pools, while multisite routing uses host names to serve several applications. Combine regional gateways with or Traffic Manager when global routing is also required.
Global and regional delivery products can cooperate at different protocol layers.
Topic summary
Choose for regional HTTP/HTTPS routing, TLS, multisite hosting, private web ingress, and optional WAF.
21. Build application protection as layers
No single control covers volumetric attacks, application exploits, network flows, private service access, and administrative exposure. Combine ,,,, NSGs, identity, encryption, monitoring, and secure application code according to each flow.
Defense in depth assigns a clear threat and traffic scope to each layer.
Topic summary
Layer protection by threat and protocol scope, and verify that routing cannot bypass the intended controls.
22. mitigates Layer-3 and Layer-4 attacks
continuously monitors supported public IP resources and automatically tunes mitigation. DDoS Network Protection associates a plan with VNets and covers supported resources across subscriptions and regions; it includes Rapid Response, cost protection, and WAF discounts. DDoS IP Protection uses a per-protected-IP model with the same core mitigation but without those added services.
Use redundancy, minimize public exposure, layer WAF for Layer-7 attacks, collect metrics, alerts, reports, and flow logs, and rehearse incident response. Confirm supported resource types before assuming a public IP is covered.
Topic summary
Select Network Protection for plan-level coverage and response benefits, or IP Protection for targeted per-IP protection, then combine it with application-layer defenses.
23. Private Link removes public exposure to supported services
uses a private endpoint—an interface with a private address in a VNet—to reach supported Azure PaaS, customer-owned, or partner services over the Microsoft backbone. It supports access from the VNet, peered VNets, and hybrid networks without publishing the service on the public internet.
A sound design also configures private DNS, disables or restricts public network access, validates data-exfiltration controls, and plans endpoint approvals and lifecycle. Private routing alone does not replace identity and authorization.
Topic summary
Private Link creates private service reachability; complete it with DNS, public-access restriction, identity, authorization, and endpoint governance.
24. , WAF, and NSGs protect different scopes
Complementary protection controls.
Control
Primary scope
Important capabilities
Centralized north-south and east-west network traffic.
Stateful rules, SNAT/DNAT, FQDN filtering, threat intelligence, logging; Standard adds DNS proxy and richer controls; Premium adds TLS inspection, IDPS, URL filtering, and up to 100-Gbps scale.
Layer-7 HTTP/HTTPS applications.
Managed OWASP rules, SQL injection and cross-site scripting protection, plus custom rules based on IP and request attributes. Deploy with or Front Door as applicable.
Network security group
Subnet and network-interface Layer-3/4 flows.
Priority-ordered inbound and outbound allow/deny ACL rules by protocol, address, port, direction, and access. Default rules remain but can be overridden.
Basic is designed for essential small-environment protection rather than being categorically unsuitable for production. Use Standard for broader enterprise filtering and Premium for sensitive inspection requirements; Premium includes TLS inspection, URL filtering, PCI DSS support, and an IDPS with more than 67,000 rules. Combine firewall or NSG rules with just-in-time VM access to reduce management-port exposure, and centralize firewall policy with Manager when operating many firewalls.
Azure Bastion provides managed browser-based RDP and SSH access to VMs through private IP addresses without publishing those management ports. NSGs filter data-plane packets; they do not decide which administrators may change network resources, so use Azure RBAC and least privilege for management-plane authorization.
Topic summary
Use NSGs for local subnet/NIC boundaries, for centralized network policy and inspection, and WAF for web exploit protection; most production designs combine them.
25. Assessment, decision record, and next study steps
Resolve the production-network scenario.
Requirement
Recommended service
Reason
Private web app needing inbound load balancing.
Azure with a private frontend
Regional Layer-7 web delivery without an internet-facing endpoint.
Filter HTTP(S) from Azure to on-premises and outbound internet traffic.
Centralized stateful network and application rules across hybrid and internet flows.
Global VNet and multi-branch connectivity with centralized management.
Azure
Managed hubs, global transit, VPN/ExpressRoute integration, and centralized routing.
For each recommendation, record address ranges, subnets, DNS, route sources, next hops, egress addresses, ingress protocol, probes, certificates, identities, filtering layers, logs, quotas, regions, SLA, cost, failure behavior, and test evidence. Revisit official limits and retirement notices before implementation because network services continue to evolve. can help compare and explain candidates, but its recommendation still requires workload evidence and architectural review.
Practice with architecture prompts
Compare , ExpressRoute, and by security, topology, performance, failure, and cost.
Build a decision tree for regional and global HTTP and non-HTTP delivery.
List ten Azure network performance practices and the metrics that would expose a problem.
Explain how DDoS Protection, WAF, , Private Link, and NSGs cooperate without duplicating ownership.
A defensible AZ-305 network design connects every selected service to a workload requirement and proves how traffic enters, exits, is routed, protected, observed, and recovered.
