{"id":503,"date":"2026-04-14T07:23:11","date_gmt":"2026-04-14T07:23:11","guid":{"rendered":"https:\/\/www.devopsschool.com\/tutorials\/azure-virtual-network-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/"},"modified":"2026-04-14T07:23:11","modified_gmt":"2026-04-14T07:23:11","slug":"azure-virtual-network-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking","status":"publish","type":"post","link":"https:\/\/www.devopsschool.com\/tutorials\/azure-virtual-network-tutorial-architecture-pricing-use-cases-and-hands-on-guide-for-networking\/","title":{"rendered":"Azure Virtual Network Tutorial: Architecture, Pricing, Use Cases, and Hands-On Guide for Networking"},"content":{"rendered":"\n<h2 class=\"wp-block-heading\">Category<\/h2>\n\n\n\n<p>Networking<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">1. Introduction<\/h2>\n\n\n\n<p><strong>What this service is<\/strong><br\/>\nAzure Virtual Network is Azure\u2019s fundamental private networking service for building isolated, IP-based networks in the cloud. It is commonly shortened to \u201cVNet,\u201d but the official service name is <strong>Azure Virtual Network<\/strong>.<\/p>\n\n\n\n<p><strong>Simple explanation (one paragraph)<\/strong><br\/>\nThink of Azure Virtual Network as your own private network inside Azure, where you choose IP address ranges, split them into subnets, and decide what can talk to what\u2014whether that\u2019s virtual machines, Kubernetes nodes, platform services via private endpoints, or your on-premises network over VPN or ExpressRoute.<\/p>\n\n\n\n<p><strong>Technical explanation (one paragraph)<\/strong><br\/>\nAzure Virtual Network is a regional, software-defined networking construct that provides IP address space, subnetting, routing, and integration points for security and connectivity services (Network Security Groups, Azure Firewall, NAT Gateway, VPN Gateway, ExpressRoute, Private Link, service endpoints, and VNet peering). It uses Azure\u2019s SDN fabric to deliver east-west traffic flow inside a VNet and north-south connectivity to on-premises networks and the internet, subject to explicit routing and security controls.<\/p>\n\n\n\n<p><strong>What problem it solves<\/strong><br\/>\nAzure Virtual Network solves the problem of safely and predictably networking cloud workloads: isolating environments, controlling connectivity, enabling secure private access to Azure services, connecting to on-premises, and scaling network architecture without physically managing switches, routers, and firewalls.<\/p>\n\n\n\n<blockquote>\n<p>Service status and naming: <strong>Azure Virtual Network<\/strong> is the current, active service name (often shown as \u201cVirtual network\u201d in the portal). It has not been retired. Related capabilities may appear as separate services (for example, NAT Gateway, Azure Firewall, VPN Gateway), but Azure Virtual Network is the foundational network boundary they attach to.<\/p>\n<\/blockquote>\n\n\n\n<h2 class=\"wp-block-heading\">2. What is Azure Virtual Network?<\/h2>\n\n\n\n<p><strong>Official purpose<\/strong><br\/>\nAzure Virtual Network provides <strong>private IP networking<\/strong> for Azure resources. It lets you create a logically isolated network, define address spaces, create subnets, and control routing and traffic flow.<\/p>\n\n\n\n<p><strong>Core capabilities<\/strong>\n&#8211; Create private networks with your chosen RFC1918 address ranges (or other routable ranges when appropriate).\n&#8211; Segment the network into subnets for tiering and isolation.\n&#8211; Control traffic with <strong>Network Security Groups (NSGs)<\/strong> and routing with <strong>route tables (UDRs)<\/strong>.\n&#8211; Connect networks with <strong>VNet peering<\/strong> and connect to on-premises with <strong>VPN Gateway<\/strong> or <strong>ExpressRoute<\/strong>.\n&#8211; Access Azure PaaS services privately using <strong>Private Endpoints (Azure Private Link)<\/strong> or restrict public exposure via <strong>service endpoints<\/strong>.\n&#8211; Provide outbound internet egress control with <strong>NAT Gateway<\/strong> (and other supported egress methods).\n&#8211; Integrate with monitoring and diagnostics via <strong>Azure Network Watcher<\/strong> and <strong>NSG flow logs<\/strong> (where applicable).<\/p>\n\n\n\n<p><strong>Major components<\/strong>\n&#8211; <strong>Virtual network (VNet):<\/strong> The top-level network container with one or more address spaces.\n&#8211; <strong>Address space:<\/strong> One or more CIDR ranges assigned to the VNet.\n&#8211; <strong>Subnets:<\/strong> Sub-ranges of the VNet address space; resources are placed into subnets.\n&#8211; <strong>Network interfaces (NICs):<\/strong> Attached to compute resources; have private IPs from a subnet.\n&#8211; <strong>DNS configuration:<\/strong> Azure-provided DNS by default, or custom DNS servers \/ Azure DNS Private Resolver patterns.\n&#8211; <strong>Network Security Groups (NSGs):<\/strong> Stateless (rule-based) L3\/L4 filtering at subnet and\/or NIC.\n&#8211; <strong>Route tables (UDRs):<\/strong> Custom routes controlling next hop selection.\n&#8211; <strong>Peering and gateways:<\/strong> Connectivity constructs that link VNets or connect to external networks.<\/p>\n\n\n\n<p><strong>Service type<\/strong><br\/>\nFoundational <strong>IaaS networking<\/strong> (software-defined network boundary) with strong integration into Azure platform services.<\/p>\n\n\n\n<p><strong>Scope and geography<\/strong>\n&#8211; <strong>Resource scope:<\/strong> Created within an <strong>Azure subscription<\/strong> and <strong>resource group<\/strong>.\n&#8211; <strong>Geographic scope:<\/strong> A VNet is a <strong>regional<\/strong> resource (tied to a region like East US).<br\/>\n  &#8211; It can span <strong>Availability Zones within the same region<\/strong>.\n  &#8211; It cannot natively span multiple regions as a single VNet; multi-region designs use peering, hubs, or Virtual WAN.\n&#8211; <strong>Global connectivity:<\/strong> <strong>Global VNet peering<\/strong> can connect VNets across regions (subject to constraints and costs).<\/p>\n\n\n\n<p><strong>How it fits into the Azure ecosystem<\/strong>\nAzure Virtual Network is the network \u201clanding zone\u201d for many Azure resources:\n&#8211; Compute: Azure Virtual Machines, VM Scale Sets, AKS (Azure Kubernetes Service), Azure Bastion\n&#8211; Security: NSGs, Azure Firewall, DDoS Protection\n&#8211; Connectivity: VPN Gateway, ExpressRoute Gateway, NAT Gateway, Load Balancer\n&#8211; Private access to PaaS: Private Endpoints (Private Link), service endpoints\n&#8211; Observability: Network Watcher, flow logs, traffic analytics (depending on configuration)<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">3. Why use Azure Virtual Network?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Business reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Consistent network boundaries<\/strong> for environments (dev\/test\/prod) and business units.<\/li>\n<li><strong>Faster provisioning<\/strong> than on-prem network changes; network is infrastructure-as-code friendly.<\/li>\n<li><strong>Supports compliance needs<\/strong> by enabling segmentation, private access, and logging patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Technical reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>IP control:<\/strong> You choose address spaces and subnet boundaries, enabling predictable routing and integration with on-prem.<\/li>\n<li><strong>Layered security:<\/strong> Use NSGs, Azure Firewall, Private Link, and routing controls to minimize exposure.<\/li>\n<li><strong>Hybrid and multi-network patterns:<\/strong> Hub-spoke, peering, and gateway-based designs are standard and well-supported.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Standardization:<\/strong> Repeatable network patterns (spoke VNets, shared services subnets, naming conventions).<\/li>\n<li><strong>Centralized troubleshooting:<\/strong> Tools like Network Watcher, NSG flow logs, and connection troubleshooting help reduce MTTR.<\/li>\n<li><strong>Governance:<\/strong> Azure Policy and role-based access can prevent misconfigurations at scale.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/compliance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Private connectivity:<\/strong> Avoid public endpoints using Private Endpoints and private DNS patterns.<\/li>\n<li><strong>Segmentation:<\/strong> Separate tiers\/subnets (web\/app\/data) and restrict flows with least privilege.<\/li>\n<li><strong>Auditability:<\/strong> Diagnostic settings + logs (where available) can feed SIEM\/SOAR.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Scalability\/performance reasons<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Scale-out friendly:<\/strong> VNets can host large numbers of interfaces\/resources (subject to limits).<\/li>\n<li><strong>High bandwidth within Azure:<\/strong> Intra-VNet and zonal traffic is typically high throughput; exact throughput depends on VM sizes and architecture. Verify performance constraints for specific SKUs in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should choose it<\/h3>\n\n\n\n<p>Choose Azure Virtual Network when you need:\n&#8211; Private IP networking for Azure compute\n&#8211; Segmentation and traffic control\n&#8211; Hybrid connectivity to on-premises\n&#8211; Private access to PaaS services\n&#8211; A foundation for standard Azure landing zone network architectures<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">When teams should not choose it (or should reconsider)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>If you only use <strong>serverless PaaS<\/strong> and don\u2019t need private networking or VNet integration, a VNet may add complexity (private DNS, egress, routing).<\/li>\n<li>If you need <strong>global transit routing<\/strong> and centrally managed branch\/user connectivity, consider <strong>Azure Virtual WAN<\/strong> as the primary connectivity framework (it still uses VNets but changes how you manage connectivity).<\/li>\n<li>If you require features like third-party advanced routing appliances across many regions, you may prefer a dedicated network virtual appliance strategy\u2014still attached to VNets, but not \u201cjust VNet.\u201d<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">4. Where is Azure Virtual Network used?<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Industries<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Finance and insurance (segmentation, audit controls, private connectivity)<\/li>\n<li>Healthcare (PHI systems needing private access and strict boundaries)<\/li>\n<li>Retail and e-commerce (multi-tier apps, PCI segmentation patterns)<\/li>\n<li>Manufacturing and IoT (hybrid connectivity to plants; private endpoints to data services)<\/li>\n<li>Public sector (regulated environments, network isolation)<\/li>\n<li>SaaS providers (multi-environment deployments, hub-spoke designs)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Team types<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud platform\/landing zone teams<\/li>\n<li>Network engineering and cloud networking teams<\/li>\n<li>DevOps\/SRE teams managing infrastructure and connectivity<\/li>\n<li>Security engineering teams implementing segmentation and private access<\/li>\n<li>Application teams needing reliable private service-to-service communication<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Multi-tier applications (web\/app\/data)<\/li>\n<li>AKS clusters with private API server and egress controls<\/li>\n<li>Microservices architectures requiring private east-west flows<\/li>\n<li>Data platforms using Private Link to storage, databases, and analytics services<\/li>\n<li>Hybrid apps extending on-prem networks<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Architectures<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Single VNet with multiple subnets (small deployments)<\/li>\n<li><strong>Hub-spoke topology<\/strong> (enterprise standard)<\/li>\n<li>Shared services VNet (DNS, firewall, identity, management)<\/li>\n<li>Multi-region active\/active with global peering and regional hubs (advanced)<\/li>\n<li>Secure-by-default architectures using private endpoints + forced tunneling<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Production vs dev\/test usage<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Production:<\/strong> Typically uses hub-spoke, Azure Firewall (or NVA), private endpoints, central DNS, DDoS protection (where needed), strict NSGs, and logging.<\/li>\n<li><strong>Dev\/test:<\/strong> Often uses fewer controls, but still benefits from consistent IP plans and basic segmentation; cost savings may drive simpler egress and less logging.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">5. Top Use Cases and Scenarios<\/h2>\n\n\n\n<p>Below are realistic scenarios where Azure Virtual Network is the core building block.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">1) Multi-tier application segmentation<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A web tier must be reachable from the internet, but app and database tiers must remain private.<\/li>\n<li><strong>Why Azure Virtual Network fits:<\/strong> Subnets + NSGs allow tier separation and least-privilege flows.<\/li>\n<li><strong>Example:<\/strong> Web subnet allows inbound HTTPS; app subnet only accepts traffic from web subnet; database subnet only accepts from app subnet.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">2) Private access to Azure PaaS with Private Endpoints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You must prevent data exfiltration via public endpoints to Storage\/SQL.<\/li>\n<li><strong>Why it fits:<\/strong> Azure Virtual Network hosts <strong>Private Endpoints<\/strong>, giving PaaS services private IPs.<\/li>\n<li><strong>Example:<\/strong> Storage account accessed only via private endpoint; public network access disabled.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">3) Hub-spoke shared services networking<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Many app teams need consistent outbound control, DNS, and inspection.<\/li>\n<li><strong>Why it fits:<\/strong> Spoke VNets peer into a hub VNet hosting firewall\/DNS; UDRs steer traffic.<\/li>\n<li><strong>Example:<\/strong> All spokes send internet-bound traffic to Azure Firewall in hub.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">4) Hybrid connectivity to on-premises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Cloud workloads must talk to on-prem databases and identity services.<\/li>\n<li><strong>Why it fits:<\/strong> VPN Gateway \/ ExpressRoute Gateway attaches to a VNet gateway subnet.<\/li>\n<li><strong>Example:<\/strong> Site-to-site VPN provides encrypted tunnel to on-prem; routes propagate into subnets.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">5) Secure administrative access (jump host \/ Bastion pattern)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Admins need SSH\/RDP without exposing VMs via public IPs.<\/li>\n<li><strong>Why it fits:<\/strong> Place admin access components inside Azure Virtual Network; control with NSGs.<\/li>\n<li><strong>Example:<\/strong> Use Azure Bastion (paid) or a locked-down jump VM (lower cost but more ops).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6) AKS with controlled egress<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Kubernetes nodes need outbound access but must use a fixed public IP for allowlists.<\/li>\n<li><strong>Why it fits:<\/strong> NAT Gateway on AKS subnet provides stable egress IPs.<\/li>\n<li><strong>Example:<\/strong> NAT Gateway ensures outbound traffic originates from a known public IP.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">7) Shared private DNS for multiple VNets<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Private endpoints require private DNS names to resolve correctly from multiple networks.<\/li>\n<li><strong>Why it fits:<\/strong> VNets link to private DNS zones; hub-spoke can centralize DNS forwarding.<\/li>\n<li><strong>Example:<\/strong> <code>privatelink.blob.core.windows.net<\/code> zone linked to spokes.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">8) Controlled east-west traffic between workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Lateral movement risk: compromise of one VM should not allow scanning all networks.<\/li>\n<li><strong>Why it fits:<\/strong> NSG rules + subnet design restrict east-west flows.<\/li>\n<li><strong>Example:<\/strong> Only specific ports allowed between subnets; deny broad intra-VNet access.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">9) Multi-region disaster recovery connectivity<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> Apps fail over to another region and must maintain private connectivity.<\/li>\n<li><strong>Why it fits:<\/strong> Global VNet peering can link regions; routing and DNS can be designed for failover.<\/li>\n<li><strong>Example:<\/strong> Active\/passive setup with paired regions and controlled replication flows.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">10) Network isolation per tenant or environment<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A SaaS platform needs strong isolation between tenants or between dev\/test\/prod.<\/li>\n<li><strong>Why it fits:<\/strong> Separate VNets with peering only where needed; policy can enforce separation.<\/li>\n<li><strong>Example:<\/strong> Each tenant gets its own spoke VNet; shared services in hub.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">11) Private service publishing to consumers (Private Link Service)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You want to offer a service privately to other VNets\/subscriptions without public exposure.<\/li>\n<li><strong>Why it fits:<\/strong> VNets can host internal load balancers and Private Link Service.<\/li>\n<li><strong>Example:<\/strong> Internal API behind Standard Load Balancer exposed via Private Link.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">12) NVA-based advanced routing\/security<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> You require vendor firewall features not provided by native services.<\/li>\n<li><strong>Why it fits:<\/strong> VNets allow insertion of NVAs and route control via UDRs.<\/li>\n<li><strong>Example:<\/strong> Palo Alto\/Fortinet NVAs deployed in hub; spokes route through them.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">6. Core Features<\/h2>\n\n\n\n<p>This section focuses on Azure Virtual Network capabilities and the most important integrated networking features you commonly use with it.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">6.1 VNet address space (CIDR)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Defines one or more IP ranges for the VNet (IPv4, and in many cases IPv6\u2014verify IPv6 support per scenario in official docs).<\/li>\n<li><strong>Why it matters:<\/strong> Your IP plan affects peering, hybrid routing, and future growth.<\/li>\n<li><strong>Practical benefit:<\/strong> Predictable addressing and easier integration with on-premises.<\/li>\n<li><strong>Caveats:<\/strong> Overlapping address spaces prevent many connectivity options (peering, gateways). Plan for expansion early.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.2 Subnets<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Segments the VNet into smaller ranges where resources are placed.<\/li>\n<li><strong>Why it matters:<\/strong> Subnets are the unit for many controls: NSG association, route table association, NAT Gateway association.<\/li>\n<li><strong>Practical benefit:<\/strong> Clear separation of tiers and responsibilities (web\/app\/data, shared services, gateways).<\/li>\n<li><strong>Caveats:<\/strong> Subnet resizing can be constrained once resources exist; gateway-related subnets have special requirements (for example, <strong>GatewaySubnet<\/strong> naming for VPN\/ExpressRoute gateways).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.3 Private IP addressing and NICs<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Assigns private IPs to network interfaces attached to VMs and other resources.<\/li>\n<li><strong>Why it matters:<\/strong> Private IPs are stable identifiers for internal communication.<\/li>\n<li><strong>Practical benefit:<\/strong> Enables service-to-service traffic without traversing the public internet.<\/li>\n<li><strong>Caveats:<\/strong> Effective throughput depends on VM size and acceleration features; verify per SKU.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.4 Built-in system routing + custom routes (UDRs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Azure provides default system routes within and beyond the VNet; you can override\/extend with route tables.<\/li>\n<li><strong>Why it matters:<\/strong> Correct routing is essential for hub-spoke, forced tunneling, and NVA insertion.<\/li>\n<li><strong>Practical benefit:<\/strong> You can steer traffic through firewalls, proxies, or gateways.<\/li>\n<li><strong>Caveats:<\/strong> Routing is not \u201cdynamic routing everywhere.\u201d Some next-hop behaviors and propagation rules are specific; verify route precedence and propagation rules in docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.5 Network Security Groups (NSGs)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Filters inbound\/outbound traffic with L3\/L4 rules at subnet or NIC level.<\/li>\n<li><strong>Why it matters:<\/strong> NSGs are the baseline micro-segmentation mechanism for many architectures.<\/li>\n<li><strong>Practical benefit:<\/strong> You can allow only required ports and sources\/destinations.<\/li>\n<li><strong>Caveats:<\/strong> NSGs are stateful, rule order matters, and service tags simplify rules but must be used thoughtfully. For deep inspection, use Azure Firewall or NVAs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.6 VNet peering (including global peering)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Connects VNets so they can route traffic privately using Azure backbone.<\/li>\n<li><strong>Why it matters:<\/strong> Enables modular network design (hub-spoke, shared services).<\/li>\n<li><strong>Practical benefit:<\/strong> Lower latency than VPN overlay; straightforward connectivity.<\/li>\n<li><strong>Caveats:<\/strong> Peering is <strong>not transitive<\/strong> (spoke A doesn\u2019t automatically reach spoke B via hub unless you design for it). Data transfer costs can apply.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.7 Private Endpoints (Azure Private Link integration)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Places a private IP in your subnet that maps to an Azure PaaS resource.<\/li>\n<li><strong>Why it matters:<\/strong> Strongly reduces public exposure and supports \u201cno public internet\u201d policies.<\/li>\n<li><strong>Practical benefit:<\/strong> PaaS traffic stays private; easier compliance story.<\/li>\n<li><strong>Caveats:<\/strong> Requires correct private DNS resolution design. Private endpoint and DNS zone usage incur costs (verify pricing).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.8 Service endpoints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Extends your VNet identity to Azure services over Azure backbone; service remains publicly addressed but access can be restricted to the VNet\/subnet.<\/li>\n<li><strong>Why it matters:<\/strong> Simpler than Private Endpoints in some cases.<\/li>\n<li><strong>Practical benefit:<\/strong> Quick restriction of access to supported services.<\/li>\n<li><strong>Caveats:<\/strong> Not equivalent to Private Link; traffic still targets public endpoints (though kept on backbone). Service endpoint policies and service support vary.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.9 DNS options (Azure-provided, custom DNS, and private DNS patterns)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> VNets can use Azure-provided DNS or custom DNS servers; private endpoints commonly require private DNS zone integration.<\/li>\n<li><strong>Why it matters:<\/strong> DNS is critical for service discovery and private endpoint usability.<\/li>\n<li><strong>Practical benefit:<\/strong> Centralized name resolution for hybrid and multi-VNet setups.<\/li>\n<li><strong>Caveats:<\/strong> DNS misconfiguration is one of the most common causes of \u201cPrivate Link doesn\u2019t work.\u201d<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.10 Outbound connectivity controls (NAT Gateway integration)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Provides managed SNAT with static egress public IPs for a subnet.<\/li>\n<li><strong>Why it matters:<\/strong> Many services require allowlisted egress IPs; it also helps avoid SNAT port exhaustion patterns.<\/li>\n<li><strong>Practical benefit:<\/strong> Stable outbound identity, scalable outbound.<\/li>\n<li><strong>Caveats:<\/strong> NAT Gateway is a separate billed resource; design egress intentionally. Also note Azure\u2019s \u201cdefault outbound access\u201d behavior may vary over time\u2014verify current guidance in official docs for your scenario.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.11 DDoS Protection integration<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> DDoS Protection (especially the Standard plan) can be enabled to protect public endpoints associated with resources in a VNet.<\/li>\n<li><strong>Why it matters:<\/strong> Reduces risk from volumetric attacks.<\/li>\n<li><strong>Practical benefit:<\/strong> Enhanced protection and telemetry for internet-exposed workloads.<\/li>\n<li><strong>Caveats:<\/strong> DDoS Standard has cost; evaluate based on threat model.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">6.12 Monitoring and diagnostics (Network Watcher integration)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>What it does:<\/strong> Offers packet capture, connection troubleshoot, IP flow verify, topology, and NSG flow logs (where available\/configured).<\/li>\n<li><strong>Why it matters:<\/strong> Networking issues are often the hardest to debug; these tools shorten MTTR.<\/li>\n<li><strong>Practical benefit:<\/strong> Visibility into effective security and connectivity.<\/li>\n<li><strong>Caveats:<\/strong> Some logging\/analytics features incur additional charges (Log Analytics ingestion, storage).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">7. Architecture and How It Works<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">High-level service architecture<\/h3>\n\n\n\n<p>Azure Virtual Network is implemented using Azure\u2019s SDN. From a user perspective:\n&#8211; You define VNets\/subnets (control plane).\n&#8211; Azure programs the underlying fabric to enforce routing and security (data plane).\n&#8211; Resources attach via NICs and receive private IP configurations.\n&#8211; NSGs and route tables influence packet processing.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Control flow vs data flow<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Control plane:<\/strong> Azure Resource Manager (ARM) API operations create\/update VNets, subnets, NSGs, and routes.<\/li>\n<li><strong>Data plane:<\/strong> Packets between NICs traverse Azure\u2019s virtualized network fabric. NSGs evaluate flows; routing determines next hops.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Integrations with related services<\/h3>\n\n\n\n<p>Common integrations (not all are \u201cpart of\u201d Azure Virtual Network, but they attach to it):\n&#8211; <strong>Azure Load Balancer (public\/internal):<\/strong> Frontends for L4 load distribution.\n&#8211; <strong>Application Gateway:<\/strong> L7 ingress for web apps.\n&#8211; <strong>Azure Firewall:<\/strong> Central egress\/ingress inspection; often placed in a hub VNet.\n&#8211; <strong>VPN Gateway \/ ExpressRoute Gateway:<\/strong> Hybrid connectivity from a VNet.\n&#8211; <strong>NAT Gateway:<\/strong> Subnet-level outbound SNAT.\n&#8211; <strong>Private Endpoints (Private Link):<\/strong> Private IP mapping to PaaS.\n&#8211; <strong>Azure DNS Private Resolver \/ custom DNS VMs:<\/strong> Name resolution across networks.\n&#8211; <strong>Network Watcher:<\/strong> Troubleshooting and diagnostics.\n&#8211; <strong>DDoS Protection:<\/strong> Protection for public endpoints.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Dependency services<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Resource Manager<\/strong> for deployment and policy.<\/li>\n<li><strong>Azure platform networking fabric<\/strong> for packet forwarding (managed by Azure).<\/li>\n<li>Often <strong>Log Analytics \/ Storage<\/strong> if you enable flow logs or diagnostics.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Security\/authentication model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Management-plane access:<\/strong> Controlled by <strong>Azure RBAC<\/strong> on VNets\/subnets\/NSGs\/route tables.<\/li>\n<li><strong>Data-plane access:<\/strong> Controlled by NSGs, firewalls\/NVAs, and routing.<\/li>\n<li><strong>Privileged operations:<\/strong> Creating peerings, gateways, route tables, and private endpoints usually requires elevated permissions on both networking and target resources.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Networking model essentials<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Subnet-level policy:<\/strong> Many network services attach at subnet scope (NSGs, UDRs, NAT Gateway).<\/li>\n<li><strong>East-west traffic:<\/strong> Subnet-to-subnet and VM-to-VM inside a VNet is private by default, but must be allowed by NSGs\/firewalls.<\/li>\n<li><strong>North-south traffic:<\/strong> Internet ingress\/egress depends on public IPs, load balancers, NAT, and firewall architecture.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Monitoring\/logging\/governance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use <strong>Azure Policy<\/strong> to enforce:<\/li>\n<li>No public IPs on NICs (except approved)<\/li>\n<li>NSG required on all subnets<\/li>\n<li>Approved DNS settings<\/li>\n<li>Required tags and naming<\/li>\n<li>Use <strong>Network Watcher<\/strong> for operational troubleshooting.<\/li>\n<li>Use <strong>NSG flow logs<\/strong> plus Log Analytics\/Sentinel for security visibility (verify the latest recommended flow log version and region support in official docs).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Simple architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart LR\n  Internet((Internet))\n  subgraph VNet[Azure Virtual Network]\n    subgraph S1[Subnet: web 10.10.1.0\/24]\n      WebVM[Web VM\\nNIC: 10.10.1.4]\n      NSG1[NSG: web-nsg]\n    end\n    subgraph S2[Subnet: app 10.10.2.0\/24]\n      AppVM[App VM\\nNIC: 10.10.2.4]\n      NSG2[NSG: app-nsg]\n    end\n  end\n\n  Internet --&gt;|SSH\/HTTPS allowed| NSG1 --&gt; WebVM\n  WebVM --&gt;|SSH allowed| NSG2 --&gt; AppVM\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Production-style architecture diagram (Mermaid)<\/h3>\n\n\n\n<pre><code class=\"language-mermaid\">flowchart TB\n  OnPrem[On-premises Network] --- VPN[VPN\/ExpressRoute]\n  Internet((Internet))\n\n  subgraph Hub[Hub VNet (Shared Services)]\n    HubFW[Azure Firewall or NVA]\n    HubDNS[DNS (Azure DNS Private Resolver or custom)]\n    HubGW[GatewaySubnet\\nVPN\/ER Gateway]\n  end\n\n  subgraph Spoke1[Spoke VNet: App1]\n    S1Web[Web Subnet]\n    S1App[App Subnet]\n    S1Data[Data Subnet]\n    PE1[Private Endpoints]\n  end\n\n  subgraph Spoke2[Spoke VNet: App2]\n    S2App[App Subnet]\n    PE2[Private Endpoints]\n  end\n\n  Internet --&gt;|Ingress via App Gateway\/Front Door (optional)| S1Web\n  Spoke1 &lt;--&gt;|VNet Peering| Hub\n  Spoke2 &lt;--&gt;|VNet Peering| Hub\n\n  Spoke1 --&gt;|UDR forced tunneling| HubFW --&gt; Internet\n  Spoke2 --&gt;|UDR forced tunneling| HubFW --&gt; Internet\n\n  Spoke1 --&gt; HubDNS\n  Spoke2 --&gt; HubDNS\n\n  OnPrem --- VPN --- HubGW\n  HubGW --- Hub\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">8. Prerequisites<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Account\/subscription requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>An active <strong>Azure subscription<\/strong>.<\/li>\n<li>Ability to create resources in a resource group.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Permissions (IAM\/RBAC)<\/h3>\n\n\n\n<p>You typically need one of the following (exact roles depend on your organization):\n&#8211; <strong>Contributor<\/strong> on the resource group (simple labs)\n&#8211; Or least-privilege:\n  &#8211; <code>Microsoft.Network\/virtualNetworks\/*<\/code>\n  &#8211; <code>Microsoft.Network\/networkSecurityGroups\/*<\/code>\n  &#8211; <code>Microsoft.Network\/publicIPAddresses\/*<\/code> (if you create public IPs)\n  &#8211; <code>Microsoft.Compute\/*<\/code> (if creating VMs for testing)<\/p>\n\n\n\n<p>For production, consider using:\n&#8211; <strong>Network Contributor<\/strong> for network operators\n&#8211; <strong>Virtual Machine Contributor<\/strong> for compute operators<br\/>\nAnd restrict who can:\n&#8211; Create peerings\n&#8211; Create\/update route tables\n&#8211; Create private endpoints (which can impact data exfiltration controls)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Billing requirements<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Virtual Network itself is generally not billed as a standalone resource, but many attached capabilities are billed (see Pricing section).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Tools<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure CLI<\/strong> (recommended for repeatable labs): https:\/\/learn.microsoft.com\/cli\/azure\/install-azure-cli  <\/li>\n<li>Optional: Azure PowerShell, Terraform, or Bicep (not required for this lab).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Region availability<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Virtual Network is available in all\/most Azure regions. Verify any specific feature availability (for example, certain diagnostics, DDoS plans, or private link options) in official docs for your region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas\/limits<\/h3>\n\n\n\n<p>Azure enforces limits such as:\n&#8211; Number of VNets per region per subscription\n&#8211; Number of subnets per VNet\n&#8211; Number of peerings per VNet\n&#8211; NSG rule limits\n&#8211; Route table limits<\/p>\n\n\n\n<p>These limits can change. <strong>Verify current networking limits<\/strong> here:\n&#8211; https:\/\/learn.microsoft.com\/azure\/azure-resource-manager\/management\/azure-subscription-service-limits#networking-limits<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Prerequisite services for the lab<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Virtual Machines (for connectivity testing)<\/li>\n<li>(Optional but recommended) Network Watcher for validation and troubleshooting<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">9. Pricing \/ Cost<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing model (what you actually pay for)<\/h3>\n\n\n\n<p>Azure Virtual Network is a foundational service; the <strong>VNet resource itself is typically free<\/strong>, but you pay for:\n&#8211; <strong>Data transfer<\/strong> (bandwidth\/egress) in certain cases\n&#8211; <strong>Attached networking services<\/strong>\n&#8211; <strong>Logging and monitoring<\/strong> storage\/ingestion<\/p>\n\n\n\n<p>Always confirm the latest pricing here:\n&#8211; Virtual Network pricing: https:\/\/azure.microsoft.com\/pricing\/details\/virtual-network\/<br\/>\n&#8211; Azure Pricing Calculator: https:\/\/azure.microsoft.com\/pricing\/calculator\/<br\/>\n&#8211; Bandwidth (data transfer) pricing: https:\/\/azure.microsoft.com\/pricing\/details\/bandwidth\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Common pricing dimensions (by capability)<\/h3>\n\n\n\n<p>Costs you might encounter in Azure Virtual Network designs:<\/p>\n\n\n\n<p>1) <strong>VNet peering<\/strong>\n&#8211; Often billed based on <strong>data processed<\/strong> and region pairing (intra-region vs inter-region).\n&#8211; Intra-region peering and inter-region peering can have different costs; exact rates vary by region.<\/p>\n\n\n\n<p>2) <strong>VPN Gateway<\/strong>\n&#8211; Hourly cost for the gateway + data transfer. SKU selection affects throughput and features.<\/p>\n\n\n\n<p>3) <strong>ExpressRoute<\/strong>\n&#8211; ExpressRoute circuits are billed separately; gateway may be billed too depending on architecture.<\/p>\n\n\n\n<p>4) <strong>NAT Gateway<\/strong>\n&#8211; Hourly + data processed. Used for outbound SNAT at scale.<\/p>\n\n\n\n<p>5) <strong>Azure Firewall<\/strong>\n&#8211; Hourly + data processed; plus logs in Log Analytics.<\/p>\n\n\n\n<p>6) <strong>Private Endpoints \/ Private Link<\/strong>\n&#8211; Private endpoint resources are billed; data processing may apply. DNS and resolver components can add cost.<\/p>\n\n\n\n<p>7) <strong>Public IP addresses<\/strong>\n&#8211; Public IPs, particularly Standard SKU, can incur charges depending on allocation and usage model.<\/p>\n\n\n\n<p>8) <strong>Logging\/monitoring<\/strong>\n&#8211; NSG flow logs and other diagnostic logs can incur:\n  &#8211; Storage account costs (if archived)\n  &#8211; Log Analytics ingestion\/retention costs\n  &#8211; Traffic analytics costs (if enabled)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cost drivers (practical)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Egress to the internet:<\/strong> outbound bandwidth is a major driver.<\/li>\n<li><strong>Inter-region traffic:<\/strong> replication and cross-region peering flows can be expensive.<\/li>\n<li><strong>Centralized inspection:<\/strong> firewall\/NVA data processing costs scale with throughput.<\/li>\n<li><strong>Logging volume:<\/strong> flow logs at scale produce a lot of data.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Hidden or indirect costs to watch<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>NAT + Firewall double processing:<\/strong> If all traffic egresses through a firewall and you also use NAT, you may pay for multiple layers of processing depending on design.<\/li>\n<li><strong>Private DNS and resolver patterns:<\/strong> Private endpoint adoption often leads to additional DNS infrastructure and associated costs.<\/li>\n<li><strong>Operational overhead:<\/strong> Jump hosts, NVAs, and custom DNS servers add compute cost and patching burden.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">How to optimize cost (without weakening security)<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep traffic <strong>in-region<\/strong> when possible; use zonal resiliency rather than cross-region for non-DR flows.<\/li>\n<li>Right-size inspection: not every subnet needs deep inspection if you can segment appropriately.<\/li>\n<li>Use <strong>Private Endpoints<\/strong> strategically (most sensitive data paths first) and standardize DNS early.<\/li>\n<li>Control logging:<\/li>\n<li>Enable flow logs where needed (internet-facing or regulated subnets).<\/li>\n<li>Set retention policies and avoid excessive analytics if not used.<\/li>\n<li>Use NAT Gateway only where you need <strong>stable egress<\/strong> or scale; otherwise consider alternate supported egress patterns.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Example low-cost starter estimate (no fabricated prices)<\/h3>\n\n\n\n<p>A minimal lab environment can be very low cost if you:\n&#8211; Create a VNet, subnets, NSGs (typically no direct cost)\n&#8211; Deploy 1\u20132 small Linux VMs for a short time (compute + managed disks cost)\n&#8211; Use a single public IP temporarily for SSH (public IP may cost depending on SKU\/region)\n&#8211; Avoid paid services like Azure Firewall, VPN Gateway, Bastion, DDoS Standard<\/p>\n\n\n\n<p>Use the <strong>Azure Pricing Calculator<\/strong> to estimate VM + disk + public IP + bandwidth for your region.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Example production cost considerations<\/h3>\n\n\n\n<p>A typical production hub-spoke design may include:\n&#8211; Azure Firewall (or third-party NVA) for inspection\n&#8211; NAT Gateway for stable egress in multiple spokes\n&#8211; VPN\/ExpressRoute for hybrid connectivity\n&#8211; Private Endpoints for key PaaS services\n&#8211; Log Analytics + Sentinel ingestion for flow logs and firewall logs<\/p>\n\n\n\n<p>In these designs, the VNet remains foundational, but the <strong>real cost<\/strong> is in:\n&#8211; <strong>Traffic volume<\/strong> (data processed\/egress)\n&#8211; <strong>Gateway and firewall hourly charges<\/strong>\n&#8211; <strong>Logging ingestion<\/strong><\/p>\n\n\n\n<h2 class=\"wp-block-heading\">10. Step-by-Step Hands-On Tutorial<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Objective<\/h3>\n\n\n\n<p>Build a secure, two-tier network using <strong>Azure Virtual Network<\/strong>:\n&#8211; One VNet with two subnets: <code>web<\/code> and <code>app<\/code>\n&#8211; A \u201cjump\u201d VM in <code>web<\/code> subnet with a public IP restricted to your IP\n&#8211; A private VM in <code>app<\/code> subnet with <strong>no public IP<\/strong>\n&#8211; NSGs enforcing:\n  &#8211; SSH from your IP to the jump VM only\n  &#8211; SSH from jump VM subnet to app VM only\n&#8211; Validate connectivity using SSH and (optionally) Azure Network Watcher\n&#8211; Clean up all resources at the end<\/p>\n\n\n\n<p>This lab is designed to be <strong>beginner-friendly<\/strong>, realistic, and relatively low cost.<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Lab Overview<\/h3>\n\n\n\n<p>You will create:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Resource group: <code>rg-vnet-lab<\/code><\/li>\n<li>VNet: <code>vnet-lab<\/code> (<code>10.10.0.0\/16<\/code>)<\/li>\n<li>Subnets:<\/li>\n<li><code>snet-web<\/code> (<code>10.10.1.0\/24<\/code>)<\/li>\n<li><code>snet-app<\/code> (<code>10.10.2.0\/24<\/code>)<\/li>\n<li>NSGs:<\/li>\n<li><code>nsg-web<\/code> (allow SSH only from your public IP)<\/li>\n<li><code>nsg-app<\/code> (allow SSH only from <code>10.10.1.0\/24<\/code>)<\/li>\n<li>VMs:<\/li>\n<li><code>vm-web<\/code> in <code>snet-web<\/code> with public IP (SSH entry point)<\/li>\n<li><code>vm-app<\/code> in <code>snet-app<\/code> with no public IP<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Step 1: Set variables and log in<\/h3>\n\n\n\n<p><strong>Expected outcome:<\/strong> Azure CLI is authenticated and set to the correct subscription.<\/p>\n\n\n\n<pre><code class=\"language-bash\">az login\naz account show\n# If needed:\n# az account set --subscription \"&lt;SUBSCRIPTION_ID&gt;\"\n<\/code><\/pre>\n\n\n\n<p>Set environment variables (Bash). Change <code>LOCATION<\/code> to a region you use.<\/p>\n\n\n\n<pre><code class=\"language-bash\">LOCATION=\"eastus\"\nRG=\"rg-vnet-lab\"\nVNET=\"vnet-lab\"\nVNET_PREFIX=\"10.10.0.0\/16\"\nSNET_WEB=\"snet-web\"\nSNET_WEB_PREFIX=\"10.10.1.0\/24\"\nSNET_APP=\"snet-app\"\nSNET_APP_PREFIX=\"10.10.2.0\/24\"\nNSG_WEB=\"nsg-web\"\nNSG_APP=\"nsg-app\"\nVM_WEB=\"vm-web\"\nVM_APP=\"vm-app\"\nADMIN_USER=\"azureuser\"\n<\/code><\/pre>\n\n\n\n<p>Create the resource group:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group create -n \"$RG\" -l \"$LOCATION\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 2: Create the Azure Virtual Network and subnets<\/h3>\n\n\n\n<p><strong>Expected outcome:<\/strong> One VNet with two subnets exists.<\/p>\n\n\n\n<p>Create the VNet and the first subnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet create \\\n  -g \"$RG\" -n \"$VNET\" -l \"$LOCATION\" \\\n  --address-prefixes \"$VNET_PREFIX\" \\\n  --subnet-name \"$SNET_WEB\" --subnet-prefixes \"$SNET_WEB_PREFIX\"\n<\/code><\/pre>\n\n\n\n<p>Add the app subnet:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet subnet create \\\n  -g \"$RG\" --vnet-name \"$VNET\" \\\n  -n \"$SNET_APP\" --address-prefixes \"$SNET_APP_PREFIX\"\n<\/code><\/pre>\n\n\n\n<p>Verify:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet subnet list -g \"$RG\" --vnet-name \"$VNET\" -o table\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 3: Create NSGs and rules (least privilege)<\/h3>\n\n\n\n<p><strong>Expected outcome:<\/strong> NSGs exist and are associated to the correct subnets.<\/p>\n\n\n\n<p>Create NSGs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network nsg create -g \"$RG\" -n \"$NSG_WEB\" -l \"$LOCATION\"\naz network nsg create -g \"$RG\" -n \"$NSG_APP\" -l \"$LOCATION\"\n<\/code><\/pre>\n\n\n\n<p>Associate NSGs to subnets:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet subnet update -g \"$RG\" --vnet-name \"$VNET\" -n \"$SNET_WEB\" --network-security-group \"$NSG_WEB\"\naz network vnet subnet update -g \"$RG\" --vnet-name \"$VNET\" -n \"$SNET_APP\" --network-security-group \"$NSG_APP\"\n<\/code><\/pre>\n\n\n\n<p>Add inbound rule to allow SSH <strong>only from your current public IP<\/strong> to the web subnet. First, fetch your public IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">MYIP=$(curl -s https:\/\/ifconfig.me)\necho \"$MYIP\"\n<\/code><\/pre>\n\n\n\n<p>Create the rule:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network nsg rule create \\\n  -g \"$RG\" --nsg-name \"$NSG_WEB\" -n \"Allow-SSH-From-MyIP\" \\\n  --priority 100 \\\n  --direction Inbound --access Allow --protocol Tcp \\\n  --source-address-prefixes \"${MYIP}\/32\" --source-port-ranges \"*\" \\\n  --destination-address-prefixes \"*\" --destination-port-ranges 22\n<\/code><\/pre>\n\n\n\n<p>Optionally, explicitly deny SSH from other sources (NSGs already include default deny inbound, but an explicit deny can make intent clearer):<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network nsg rule create \\\n  -g \"$RG\" --nsg-name \"$NSG_WEB\" -n \"Deny-SSH-From-Internet\" \\\n  --priority 200 \\\n  --direction Inbound --access Deny --protocol Tcp \\\n  --source-address-prefixes \"Internet\" --source-port-ranges \"*\" \\\n  --destination-address-prefixes \"*\" --destination-port-ranges 22\n<\/code><\/pre>\n\n\n\n<p>Now allow SSH to the app subnet <strong>only from the web subnet CIDR<\/strong>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network nsg rule create \\\n  -g \"$RG\" --nsg-name \"$NSG_APP\" -n \"Allow-SSH-From-WebSubnet\" \\\n  --priority 100 \\\n  --direction Inbound --access Allow --protocol Tcp \\\n  --source-address-prefixes \"$SNET_WEB_PREFIX\" --source-port-ranges \"*\" \\\n  --destination-address-prefixes \"*\" --destination-port-ranges 22\n<\/code><\/pre>\n\n\n\n<p>Verify effective NSG rules:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network nsg rule list -g \"$RG\" --nsg-name \"$NSG_WEB\" -o table\naz network nsg rule list -g \"$RG\" --nsg-name \"$NSG_APP\" -o table\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 4: Create SSH keys (or use existing)<\/h3>\n\n\n\n<p><strong>Expected outcome:<\/strong> You have an SSH key pair to access the VMs.<\/p>\n\n\n\n<p>If you already have <code>~\/.ssh\/id_rsa.pub<\/code> or an Ed25519 key, you can reuse it. To generate a new key:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh-keygen -t ed25519 -f ~\/.ssh\/id_ed25519_azure_vnet_lab -C \"azure-vnet-lab\" -N \"\"\nPUBKEY=$(cat ~\/.ssh\/id_ed25519_azure_vnet_lab.pub)\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 5: Create the web VM (public) and app VM (private)<\/h3>\n\n\n\n<p><strong>Expected outcome:<\/strong> <code>vm-web<\/code> has a public IP; <code>vm-app<\/code> has only a private IP in <code>snet-app<\/code>.<\/p>\n\n\n\n<p>Create the web VM in the web subnet with a public IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az vm create \\\n  -g \"$RG\" -n \"$VM_WEB\" -l \"$LOCATION\" \\\n  --image \"Ubuntu2204\" \\\n  --admin-username \"$ADMIN_USER\" \\\n  --ssh-key-values \"$PUBKEY\" \\\n  --vnet-name \"$VNET\" --subnet \"$SNET_WEB\" \\\n  --public-ip-sku Standard\n<\/code><\/pre>\n\n\n\n<p>Create the app VM in the app subnet <strong>without<\/strong> a public IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az vm create \\\n  -g \"$RG\" -n \"$VM_APP\" -l \"$LOCATION\" \\\n  --image \"Ubuntu2204\" \\\n  --admin-username \"$ADMIN_USER\" \\\n  --ssh-key-values \"$PUBKEY\" \\\n  --vnet-name \"$VNET\" --subnet \"$SNET_APP\" \\\n  --public-ip-address \"\"\n<\/code><\/pre>\n\n\n\n<p>Get the IPs:<\/p>\n\n\n\n<pre><code class=\"language-bash\">WEB_PUBLIC_IP=$(az vm show -g \"$RG\" -n \"$VM_WEB\" -d --query publicIps -o tsv)\nWEB_PRIVATE_IP=$(az vm show -g \"$RG\" -n \"$VM_WEB\" -d --query privateIps -o tsv)\nAPP_PRIVATE_IP=$(az vm show -g \"$RG\" -n \"$VM_APP\" -d --query privateIps -o tsv)\n\necho \"vm-web public IP:   $WEB_PUBLIC_IP\"\necho \"vm-web private IP:  $WEB_PRIVATE_IP\"\necho \"vm-app private IP:  $APP_PRIVATE_IP\"\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 6: SSH to the web VM, then to the app VM (jump pattern)<\/h3>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can SSH to <code>vm-web<\/code> from your machine; and from <code>vm-web<\/code> to <code>vm-app<\/code>.<\/p>\n\n\n\n<p>SSH to the web VM:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh -i ~\/.ssh\/id_ed25519_azure_vnet_lab ${ADMIN_USER}@${WEB_PUBLIC_IP}\n<\/code><\/pre>\n\n\n\n<p>Once on <code>vm-web<\/code>, SSH to <code>vm-app<\/code> using its private IP (you may need to copy your private key securely or use agent forwarding). A safer pattern is SSH agent forwarding:<\/p>\n\n\n\n<p>From your local machine:<\/p>\n\n\n\n<pre><code class=\"language-bash\">eval \"$(ssh-agent -s)\"\nssh-add ~\/.ssh\/id_ed25519_azure_vnet_lab\nssh -A ${ADMIN_USER}@${WEB_PUBLIC_IP}\n<\/code><\/pre>\n\n\n\n<p>Then from <code>vm-web<\/code>:<\/p>\n\n\n\n<pre><code class=\"language-bash\">ssh ${ADMIN_USER}@${APP_PRIVATE_IP}\n<\/code><\/pre>\n\n\n\n<p>If successful, you have validated:\n&#8211; Inbound SSH is permitted only to the web subnet from your IP\n&#8211; App subnet is not exposed publicly\n&#8211; East-west SSH is allowed only from web subnet to app subnet<\/p>\n\n\n\n<p>Exit sessions:<\/p>\n\n\n\n<pre><code class=\"language-bash\">exit\nexit\n<\/code><\/pre>\n\n\n\n<h3 class=\"wp-block-heading\">Step 7 (Optional): Validate with Azure Network Watcher<\/h3>\n\n\n\n<p><strong>Expected outcome:<\/strong> You can programmatically test connectivity and validate NSG decisions.<\/p>\n\n\n\n<p>Network Watcher is typically enabled per region in many subscriptions, but not always. If commands fail, create\/enable it:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network watcher configure -g \"$RG\" -l \"$LOCATION\" --enabled true\n<\/code><\/pre>\n\n\n\n<p>Test TCP connectivity from web VM to app VM on port 22:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az network watcher test-connectivity \\\n  -g \"$RG\" -l \"$LOCATION\" \\\n  --source-resource \"$VM_WEB\" \\\n  --dest-address \"$APP_PRIVATE_IP\" \\\n  --dest-port 22\n<\/code><\/pre>\n\n\n\n<p>If you want to validate NSG flow decisions, you can use <strong>IP flow verify<\/strong>. This requires NIC IDs.<\/p>\n\n\n\n<pre><code class=\"language-bash\">WEB_NIC_ID=$(az vm show -g \"$RG\" -n \"$VM_WEB\" --query \"networkProfile.networkInterfaces[0].id\" -o tsv)\nAPP_NIC_ID=$(az vm show -g \"$RG\" -n \"$VM_APP\" --query \"networkProfile.networkInterfaces[0].id\" -o tsv)\n\naz network watcher show-topology -g \"$RG\" -l \"$LOCATION\"\n<\/code><\/pre>\n\n\n\n<blockquote>\n<p>Note: Some Network Watcher features and logs can incur costs (for example, storing packet captures, sending logs to Log Analytics). Use them intentionally.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Validation<\/h3>\n\n\n\n<p>Use this checklist:<\/p>\n\n\n\n<p>1) <strong>Resource validation<\/strong><\/p>\n\n\n\n<pre><code class=\"language-bash\">az network vnet show -g \"$RG\" -n \"$VNET\" --query \"{name:name, location:location, addressSpace:addressSpace.addressPrefixes}\" -o yaml\naz network vnet subnet list -g \"$RG\" --vnet-name \"$VNET\" -o table\n<\/code><\/pre>\n\n\n\n<p>2) <strong>Security validation<\/strong>\n&#8211; Confirm you can SSH to <code>vm-web<\/code> only from your public IP.\n&#8211; Confirm <code>vm-app<\/code> has <strong>no<\/strong> public IP:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az vm show -g \"$RG\" -n \"$VM_APP\" -d --query publicIps -o tsv\n# Should be empty\n<\/code><\/pre>\n\n\n\n<p>3) <strong>Connectivity validation<\/strong>\n&#8211; SSH <code>local -&gt; vm-web<\/code> works\n&#8211; SSH <code>vm-web -&gt; vm-app<\/code> works\n&#8211; SSH <code>local -&gt; vm-app<\/code> fails (no public IP)<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Troubleshooting<\/h3>\n\n\n\n<p><strong>Issue: SSH to vm-web times out<\/strong>\n&#8211; Check NSG rule source IP: your ISP IP may have changed. Re-run the <code>MYIP<\/code> command and update the rule.\n&#8211; Confirm <code>vm-web<\/code> public IP is correct.\n&#8211; Confirm your local network allows outbound TCP\/22.\n&#8211; Verify NSG association to the subnet:\n  <code>bash\n  az network vnet subnet show -g \"$RG\" --vnet-name \"$VNET\" -n \"$SNET_WEB\" --query networkSecurityGroup.id -o tsv<\/code><\/p>\n\n\n\n<p><strong>Issue: SSH from vm-web to vm-app fails<\/strong>\n&#8211; Confirm the <code>Allow-SSH-From-WebSubnet<\/code> rule exists on <code>nsg-app<\/code>.\n&#8211; Confirm <code>vm-app<\/code> is in the correct subnet:\n  <code>bash\n  az vm show -g \"$RG\" -n \"$VM_APP\" --query \"networkProfile.networkInterfaces[0].id\" -o tsv<\/code>\n&#8211; Confirm the app VM is listening on SSH (Ubuntu images typically are by default).\n&#8211; Use Network Watcher test-connectivity if available.<\/p>\n\n\n\n<p><strong>Issue: \u201cOperation failed because resource provider is not registered\u201d<\/strong>\n&#8211; Register the network provider:\n  <code>bash\n  az provider register --namespace Microsoft.Network\n  az provider show --namespace Microsoft.Network --query registrationState -o tsv<\/code><\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Cleanup<\/h3>\n\n\n\n<p><strong>Expected outcome:<\/strong> All lab resources are deleted to stop charges.<\/p>\n\n\n\n<p>Delete the entire resource group:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group delete -n \"$RG\" --yes --no-wait\n<\/code><\/pre>\n\n\n\n<p>Optionally verify deletion:<\/p>\n\n\n\n<pre><code class=\"language-bash\">az group exists -n \"$RG\"\n<\/code><\/pre>\n\n\n\n<h2 class=\"wp-block-heading\">11. Best Practices<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Architecture best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Start with an IP plan<\/strong>:<\/li>\n<li>Allocate separate address spaces for dev\/test\/prod.<\/li>\n<li>Reserve ranges for shared services, gateways, and future growth.<\/li>\n<li>Avoid overlaps with on-prem and other cloud networks to keep peering\/hybrid options open.<\/li>\n<li>Prefer <strong>hub-spoke<\/strong> for organizations with multiple workloads:<\/li>\n<li>Centralize outbound inspection and DNS<\/li>\n<li>Standardize shared services<\/li>\n<li>Use <strong>Availability Zones<\/strong> for resiliency within a region where supported and appropriate.<\/li>\n<li>Design for <strong>route clarity<\/strong>:<\/li>\n<li>Document UDRs and next hops<\/li>\n<li>Keep routing as simple as possible while meeting requirements<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">IAM\/security best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Apply <strong>least privilege<\/strong>:<\/li>\n<li>Separate network operators (VNet, peering, routing) from app operators (VMs, PaaS).<\/li>\n<li>Protect high-impact operations:<\/li>\n<li>Peering, route tables, private endpoints, and gateway changes can affect many workloads.<\/li>\n<li>Use Azure Policy to enforce:<\/li>\n<li>NSG required on subnets<\/li>\n<li>Restrict\/deny public IP creation<\/li>\n<li>Allowed locations and naming\/tagging<\/li>\n<li>Private endpoint requirements for sensitive services (where applicable)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Cost best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Minimize <strong>inter-region traffic<\/strong> unless required for DR.<\/li>\n<li>Centralize NAT\/firewall only where justified; avoid \u201cinspection everywhere\u201d if segmentation suffices.<\/li>\n<li>Right-size logging:<\/li>\n<li>Enable NSG flow logs only for subnets that need visibility.<\/li>\n<li>Use retention policies and sampling strategies (where available).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Performance best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Keep chatty workloads <strong>in the same region<\/strong> and preferably same zone set to reduce latency.<\/li>\n<li>Choose the right load balancing layer (L4 vs L7) for your traffic.<\/li>\n<li>Avoid unnecessary hairpin routing (for example, forcing all east-west traffic through a firewall) unless required.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Reliability best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use redundant designs for gateways\/firewalls where required.<\/li>\n<li>For hybrid connectivity, consider dual tunnels \/ dual circuits and tested failover.<\/li>\n<li>Document and test DR runbooks, including DNS failover behavior.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operations best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Standardize:<\/li>\n<li>Subnet naming (<code>snet-web<\/code>, <code>snet-app<\/code>, <code>snet-data<\/code>, <code>GatewaySubnet<\/code>, <code>AzureFirewallSubnet<\/code> where required)<\/li>\n<li>NSG naming (<code>nsg-&lt;app&gt;-&lt;tier&gt;-&lt;env&gt;<\/code>)<\/li>\n<li>Route table naming (<code>rt-&lt;spoke&gt;-default<\/code>)<\/li>\n<li>Maintain a <strong>network diagram<\/strong> and a routing\/port matrix.<\/li>\n<li>Use Network Watcher and logs as part of incident response and change validation.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Governance\/tagging\/naming best practices<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use tags such as:<\/li>\n<li><code>env<\/code>, <code>owner<\/code>, <code>costCenter<\/code>, <code>app<\/code>, <code>dataClassification<\/code><\/li>\n<li>Enforce with Azure Policy where possible.<\/li>\n<li>Use consistent resource group structure:<\/li>\n<li><code>rg-net-hub-prod<\/code>, <code>rg-net-spoke-foo-prod<\/code>, etc.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">12. Security Considerations<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Identity and access model<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Azure Virtual Network is managed via <strong>Azure RBAC<\/strong>.<\/li>\n<li>Typical roles:<\/li>\n<li><strong>Network Contributor<\/strong>: manage VNets, subnets, NSGs, route tables (broad)<\/li>\n<li><strong>Reader<\/strong>: visibility without changes<\/li>\n<li>For sensitive orgs, restrict:<\/li>\n<li><strong>Private endpoint creation<\/strong> (can bypass perimeter controls if misused)<\/li>\n<li><strong>Route table changes<\/strong> (can redirect traffic to malicious appliances)<\/li>\n<li><strong>Peering changes<\/strong> (can broaden blast radius)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Encryption<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Traffic inside a VNet is on Azure backbone; encryption is not automatic for all protocols.<\/li>\n<li>Use <strong>TLS<\/strong> for application traffic.<\/li>\n<li>Use IPsec for <strong>VPN<\/strong> connectivity.<\/li>\n<li>For traffic inspection and compliance, consider application-layer encryption and key management (Key Vault), plus mTLS where appropriate.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Network exposure<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Minimize public exposure:<\/li>\n<li>Avoid public IPs on VMs when possible.<\/li>\n<li>Prefer load balancers\/app gateways with WAF for inbound web traffic.<\/li>\n<li>Use Private Endpoints for PaaS services and disable public network access when feasible.<\/li>\n<li>Control outbound:<\/li>\n<li>Use NAT Gateway + firewall\/proxy where required.<\/li>\n<li>Explicitly design outbound connectivity; don\u2019t rely on implicit behaviors. Verify current \u201cdefault outbound access\u201d guidance in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secrets handling<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Do not embed credentials in VM images or scripts.<\/li>\n<li>Use Managed Identities + Key Vault for secrets.<\/li>\n<li>Restrict NSG management to prevent accidental exposure.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Audit\/logging<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Enable diagnostic logging where appropriate:<\/li>\n<li>NSG flow logs (as required)<\/li>\n<li>Firewall logs (if used)<\/li>\n<li>Activity logs for change tracking<\/li>\n<li>Centralize logs into Log Analytics\/Sentinel for correlation.<\/li>\n<li>Use Azure Monitor alerts for unexpected changes:<\/li>\n<li>New public IPs<\/li>\n<li>NSG rules allowing 0.0.0.0\/0 inbound<\/li>\n<li>Route table changes<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compliance considerations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Use segmentation aligned with data classification.<\/li>\n<li>Use private access patterns for regulated data services.<\/li>\n<li>Document network controls and evidence sources (logs, policy compliance).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Common security mistakes<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Overly permissive NSG rules (e.g., SSH\/RDP open to the world).<\/li>\n<li>Mixing prod and dev in the same VNet\/subnet without boundaries.<\/li>\n<li>Implementing Private Endpoints without correct private DNS (leading to fallback to public endpoints).<\/li>\n<li>Allowing uncontrolled outbound internet from sensitive subnets.<\/li>\n<li>Overlapping IP ranges that prevent future secure connectivity (forcing unsafe workarounds).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Secure deployment recommendations<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Adopt a <strong>reference architecture<\/strong> (hub-spoke) for enterprise.<\/li>\n<li>Enforce policy-as-code for:<\/li>\n<li>NSG baseline<\/li>\n<li>No-public-IP baseline<\/li>\n<li>Approved outbound paths<\/li>\n<li>Implement a formal change process for:<\/li>\n<li>Route tables<\/li>\n<li>Peerings<\/li>\n<li>Gateway changes<\/li>\n<li>Private endpoint approvals<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">13. Limitations and Gotchas<\/h2>\n\n\n\n<blockquote>\n<p>This section highlights recurring issues; always confirm the latest constraints in official documentation.<\/p>\n<\/blockquote>\n\n\n\n<h3 class=\"wp-block-heading\">Known limitations \/ design constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Overlapping address spaces<\/strong> block many connectivity options (peering\/hybrid). IP planning is non-negotiable.<\/li>\n<li><strong>VNet peering is not transitive<\/strong> by default; you must design routing intentionally for spoke-to-spoke patterns.<\/li>\n<li>Some gateway and firewall subnets have <strong>special naming and sizing requirements<\/strong> (for example, <code>GatewaySubnet<\/code>). Verify exact requirements for the service you attach.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Quotas and scale<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Limits exist for:<\/li>\n<li>NSG rules per NSG<\/li>\n<li>Routes per route table<\/li>\n<li>Peerings per VNet<\/li>\n<li>VNets per subscription\/region<\/li>\n<li>Check: https:\/\/learn.microsoft.com\/azure\/azure-resource-manager\/management\/azure-subscription-service-limits#networking-limits<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Regional constraints<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>A VNet is regional; multi-region requires additional VNets and connectivity.<\/li>\n<li>Feature availability can vary by region (diagnostics, certain Private Link offerings). Verify for your region.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Pricing surprises<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Cross-region peering traffic<\/strong> can add up quickly.<\/li>\n<li><strong>Firewall data processing<\/strong> scales with throughput.<\/li>\n<li><strong>Log Analytics ingestion<\/strong> for flow logs can become a major cost if enabled broadly.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Compatibility issues<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Private endpoints require correct DNS; otherwise clients may resolve public endpoints and fail (or worse, bypass intended private access).<\/li>\n<li>Forced tunneling with UDRs can break PaaS dependencies if you don\u2019t allow required service tags or routes (depends on architecture).<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Operational gotchas<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Changing subnet prefixes after deploying resources can be disruptive or blocked.<\/li>\n<li>\u201cIt pings but the app doesn\u2019t work\u201d often indicates NSG rules allow ICMP\/port but the app uses different ports or requires DNS.<\/li>\n<li>Outbound internet behavior differs depending on whether you have public IPs, NAT, load balancer outbound rules, or firewall egress. Verify current recommended outbound patterns in official docs.<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Migration challenges<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Migrating on-prem IP plans that overlap with existing VNets is painful; often requires NAT or readdressing.<\/li>\n<li>Replacing legacy flat networks with segmented VNets requires application dependency mapping.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">14. Comparison with Alternatives<\/h2>\n\n\n\n<p>Azure Virtual Network is foundational, but you may compare it to adjacent Azure services or other cloud equivalents.<\/p>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Option<\/th>\n<th>Best For<\/th>\n<th>Strengths<\/th>\n<th>Weaknesses<\/th>\n<th>When to Choose<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td><strong>Azure Virtual Network<\/strong><\/td>\n<td>Core private networking for Azure workloads<\/td>\n<td>Subnetting, NSGs, routing, peering, private endpoints integration<\/td>\n<td>Requires careful IP\/DNS\/routing design; troubleshooting can be complex<\/td>\n<td>Default choice for networking Azure compute and private access patterns<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Virtual WAN<\/strong><\/td>\n<td>Large-scale connectivity (branches, users, many sites)<\/td>\n<td>Centralized connectivity and routing framework; simplifies large networks<\/td>\n<td>Different operational model; still uses VNets; can introduce additional cost\/complexity<\/td>\n<td>When you need managed transit routing at scale across many sites\/VNets<\/td>\n<\/tr>\n<tr>\n<td><strong>Azure Firewall<\/strong> (with VNets)<\/td>\n<td>Central inspection and policy enforcement<\/td>\n<td>Managed stateful firewall; integrates with routing and logs<\/td>\n<td>Additional cost; may add latency<\/td>\n<td>When you need central egress\/ingress inspection beyond NSGs<\/td>\n<\/tr>\n<tr>\n<td><strong>VPN Gateway \/ ExpressRoute<\/strong> (with VNets)<\/td>\n<td>Hybrid connectivity<\/td>\n<td>Secure tunnels (VPN) or private circuits (ExpressRoute)<\/td>\n<td>Cost + operational complexity<\/td>\n<td>When you must connect VNets to on-premises or colocation<\/td>\n<\/tr>\n<tr>\n<td><strong>AWS VPC<\/strong><\/td>\n<td>AWS equivalent of VNet<\/td>\n<td>Mature ecosystem; similar primitives<\/td>\n<td>Different defaults, constructs, and service integrations<\/td>\n<td>Choose when you\u2019re in AWS; concepts map but implementations differ<\/td>\n<\/tr>\n<tr>\n<td><strong>Google Cloud VPC<\/strong><\/td>\n<td>GCP equivalent networking<\/td>\n<td>Global VPC model (different from Azure)<\/td>\n<td>Different routing and project model<\/td>\n<td>Choose when you\u2019re in GCP; don\u2019t assume Azure behavior<\/td>\n<\/tr>\n<tr>\n<td><strong>OpenStack Neutron (self-managed)<\/strong><\/td>\n<td>Private cloud<\/td>\n<td>Full control; on-prem placement<\/td>\n<td>High ops burden; upgrades\/HA are your responsibility<\/td>\n<td>When you must run a private cloud and accept operational overhead<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">15. Real-World Example<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">Enterprise example: Hub-spoke network for regulated workloads<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A financial services company needs dozens of application environments with strict separation, centralized inspection, private access to databases, and hybrid connectivity to on-prem systems.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Hub VNet:<ul>\n<li>Azure Firewall for egress\/ingress inspection<\/li>\n<li>VPN\/ExpressRoute gateway in <code>GatewaySubnet<\/code><\/li>\n<li>Central DNS forwarding (Azure DNS Private Resolver or managed DNS pattern)<\/li>\n<\/ul>\n<\/li>\n<li>Spoke VNets per app or domain:<ul>\n<li>Separate subnets (web\/app\/data)<\/li>\n<li>NSGs per subnet<\/li>\n<li>UDRs forcing internet-bound traffic to firewall<\/li>\n<li>Private Endpoints to Storage\/SQL\/Key Vault; public access disabled<\/li>\n<\/ul>\n<\/li>\n<li>Central monitoring:<ul>\n<li>Firewall logs + NSG flow logs to Log Analytics\/Sentinel<\/li>\n<\/ul>\n<\/li>\n<li><strong>Why Azure Virtual Network was chosen:<\/strong><\/li>\n<li>It is the foundational network boundary enabling segmentation, private endpoints, and standardized connectivity patterns.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Reduced public exposure<\/li>\n<li>Consistent audit controls and evidence<\/li>\n<li>Faster onboarding of new applications with repeatable templates<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Startup\/small-team example: Secure two-tier app with minimal overhead<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Problem:<\/strong> A small team is moving a web app to Azure and wants basic segmentation and safe admin access without a complex enterprise hub.<\/li>\n<li><strong>Proposed architecture:<\/strong><\/li>\n<li>Single Azure Virtual Network with:<ul>\n<li>Web subnet hosting a single VM or App Gateway<\/li>\n<li>App subnet hosting private compute<\/li>\n<li>NSGs limiting inbound access<\/li>\n<\/ul>\n<\/li>\n<li>Optional NAT Gateway if stable egress IP is needed (for third-party allowlists)<\/li>\n<li>Private Endpoint for the database if the team wants to disable public DB access<\/li>\n<li><strong>Why Azure Virtual Network was chosen:<\/strong><\/li>\n<li>Provides immediate private networking and security boundaries without large overhead.<\/li>\n<li><strong>Expected outcomes:<\/strong><\/li>\n<li>Safer default posture (private app tier)<\/li>\n<li>Clear path to scale into hub-spoke later if needed<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">16. FAQ<\/h2>\n\n\n\n<p>1) <strong>Is Azure Virtual Network the same as \u201cVNet\u201d?<\/strong><br\/>\nYes. \u201cVNet\u201d is the common abbreviation; the service name is Azure Virtual Network.<\/p>\n\n\n\n<p>2) <strong>Is Azure Virtual Network global?<\/strong><br\/>\nA VNet is <strong>regional<\/strong>. You can connect VNets across regions using <strong>global VNet peering<\/strong> or other architectures.<\/p>\n\n\n\n<p>3) <strong>Do VNets cost money by themselves?<\/strong><br\/>\nTypically, the VNet resource is not billed directly, but <strong>attached services<\/strong> (VPN Gateway, NAT Gateway, Firewall, Private Endpoints) and <strong>data transfer<\/strong> can cost money. Confirm on the official pricing page.<\/p>\n\n\n\n<p>4) <strong>Can two VNets with overlapping CIDRs be peered?<\/strong><br\/>\nGenerally no\u2014overlapping IP ranges prevent peering and many routing scenarios. Plan IP ranges to avoid overlaps.<\/p>\n\n\n\n<p>5) <strong>Do NSGs act like firewalls?<\/strong><br\/>\nNSGs provide stateful L3\/L4 filtering (allow\/deny rules). For advanced inspection (FQDN filtering, TLS inspection, threat intel), use Azure Firewall or an NVA.<\/p>\n\n\n\n<p>6) <strong>What\u2019s the difference between service endpoints and Private Endpoints?<\/strong><br\/>\n&#8211; <strong>Service endpoints<\/strong> restrict access to a service\u2019s public endpoint from a VNet\/subnet identity.<br\/>\n&#8211; <strong>Private Endpoints<\/strong> assign a private IP in your VNet to the service (Private Link).<br\/>\nPrivate Endpoints are typically stronger for \u201cno public exposure\u201d architectures, but require DNS planning.<\/p>\n\n\n\n<p>7) <strong>Do I need a public IP to SSH\/RDP to a VM in a VNet?<\/strong><br\/>\nNot necessarily. You can use Azure Bastion (paid), a jump host, or private connectivity (VPN\/ExpressRoute).<\/p>\n\n\n\n<p>8) <strong>Can I control outbound internet access from a subnet?<\/strong><br\/>\nYes, using NAT Gateway, Azure Firewall\/NVA with UDR forced tunneling, or other supported outbound patterns. Verify the current official guidance for outbound connectivity because defaults can change over time.<\/p>\n\n\n\n<p>9) <strong>Is VNet peering transitive?<\/strong><br\/>\nNo. If VNet A is peered to Hub and Hub is peered to VNet B, A does not automatically reach B unless you design routing and allow forwarded traffic (and meet constraints). Hub-and-spoke requires deliberate configuration.<\/p>\n\n\n\n<p>10) <strong>How do I troubleshoot \u201ccan\u2019t connect\u201d issues inside a VNet?<\/strong><br\/>\nCheck in this order:\n&#8211; DNS resolution\n&#8211; NSG effective rules\n&#8211; Route table effective routes\n&#8211; OS firewall on the VM\n&#8211; Network Watcher test-connectivity \/ connection troubleshoot<\/p>\n\n\n\n<p>11) <strong>Can I use IPv6 in Azure Virtual Network?<\/strong><br\/>\nAzure supports IPv6 in many networking scenarios, but not all combinations of services do. Verify IPv6 support for your specific resource types and region in official docs.<\/p>\n\n\n\n<p>12) <strong>How do Private Endpoints affect DNS?<\/strong><br\/>\nPrivate Endpoints require private DNS resolution to map the service name to the private IP. Without correct DNS, clients may resolve the public endpoint and fail (or bypass intended private access).<\/p>\n\n\n\n<p>13) <strong>What\u2019s the role of <code>GatewaySubnet<\/code>?<\/strong><br\/>\nIt\u2019s a dedicated subnet required for VPN\/ExpressRoute gateways in a VNet. It must follow Azure requirements (naming and sizing). Verify current requirements in the gateway documentation.<\/p>\n\n\n\n<p>14) <strong>Can I share a VNet across subscriptions?<\/strong><br\/>\nA VNet is a resource in one subscription, but you can connect across subscriptions using peering, and you can delegate access via RBAC. Some shared service patterns use hub VNets in a central subscription.<\/p>\n\n\n\n<p>15) <strong>How do I prevent accidental public exposure?<\/strong><br\/>\nUse Azure Policy to deny public IP creation, require NSGs, restrict inbound rules, and require Private Endpoints for sensitive services. Combine policy with change control and monitoring alerts.<\/p>\n\n\n\n<p>16) <strong>Do I need Azure Firewall if I already have NSGs?<\/strong><br\/>\nNot always. NSGs handle basic segmentation. Use Azure Firewall\/NVAs when you need centralized inspection, advanced outbound control, or regulatory requirements for firewall logging and policy.<\/p>\n\n\n\n<p>17) <strong>What\u2019s the biggest design mistake with Azure Virtual Network?<\/strong><br\/>\nPoor IP planning and DNS planning. These two issues commonly cause painful migrations and broken private endpoint scenarios later.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">17. Top Online Resources to Learn Azure Virtual Network<\/h2>\n\n\n\n<figure class=\"wp-block-table\"><table>\n<thead>\n<tr>\n<th>Resource Type<\/th>\n<th>Name<\/th>\n<th>Why It Is Useful<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Official documentation<\/td>\n<td>Azure Virtual Network documentation \u2014 https:\/\/learn.microsoft.com\/azure\/virtual-network\/<\/td>\n<td>Core concepts, how-to guides, and reference documentation<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Virtual network traffic routing \u2014 https:\/\/learn.microsoft.com\/azure\/virtual-network\/virtual-networks-udr-overview<\/td>\n<td>Explains system routes, UDRs, and routing behavior<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Network Security Groups overview \u2014 https:\/\/learn.microsoft.com\/azure\/virtual-network\/network-security-groups-overview<\/td>\n<td>NSG concepts, rule processing, and best practices<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>VNet peering overview \u2014 https:\/\/learn.microsoft.com\/azure\/virtual-network\/virtual-network-peering-overview<\/td>\n<td>Peering behavior, constraints, and scenarios<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Private Link overview \u2014 https:\/\/learn.microsoft.com\/azure\/private-link\/private-link-overview<\/td>\n<td>Private Endpoints, Private Link Service, DNS considerations<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Service endpoints overview \u2014 https:\/\/learn.microsoft.com\/azure\/virtual-network\/virtual-network-service-endpoints-overview<\/td>\n<td>When to use service endpoints and how they differ from Private Link<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>NAT Gateway overview \u2014 https:\/\/learn.microsoft.com\/azure\/virtual-network\/nat-gateway\/nat-overview<\/td>\n<td>Outbound design and NAT Gateway fundamentals<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Azure VPN Gateway documentation \u2014 https:\/\/learn.microsoft.com\/azure\/vpn-gateway\/<\/td>\n<td>Hybrid connectivity patterns and gateway requirements<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>ExpressRoute documentation \u2014 https:\/\/learn.microsoft.com\/azure\/expressroute\/<\/td>\n<td>Private circuit connectivity and design guidance<\/td>\n<\/tr>\n<tr>\n<td>Official documentation<\/td>\n<td>Network Watcher documentation \u2014 https:\/\/learn.microsoft.com\/azure\/network-watcher\/<\/td>\n<td>Tooling for topology, flow verification, and troubleshooting<\/td>\n<\/tr>\n<tr>\n<td>Official pricing page<\/td>\n<td>Virtual Network pricing \u2014 https:\/\/azure.microsoft.com\/pricing\/details\/virtual-network\/<\/td>\n<td>Shows billable dimensions tied to VNet usage (peering, etc.)<\/td>\n<\/tr>\n<tr>\n<td>Official pricing tool<\/td>\n<td>Azure Pricing Calculator \u2014 https:\/\/azure.microsoft.com\/pricing\/calculator\/<\/td>\n<td>Build region-specific estimates without guessing<\/td>\n<\/tr>\n<tr>\n<td>Official architecture center<\/td>\n<td>Azure Architecture Center \u2014 https:\/\/learn.microsoft.com\/azure\/architecture\/<\/td>\n<td>Reference architectures including hub-spoke and hybrid patterns<\/td>\n<\/tr>\n<tr>\n<td>Official landing zone guidance<\/td>\n<td>Azure Cloud Adoption Framework (CAF) \u2014 https:\/\/learn.microsoft.com\/azure\/cloud-adoption-framework\/<\/td>\n<td>Enterprise-scale governance and networking patterns<\/td>\n<\/tr>\n<tr>\n<td>Official videos<\/td>\n<td>Microsoft Azure YouTube channel \u2014 https:\/\/www.youtube.com\/@MicrosoftAzure<\/td>\n<td>Networking sessions and walkthroughs (verify latest playlists)<\/td>\n<\/tr>\n<\/tbody>\n<\/table><\/figure>\n\n\n\n<h2 class=\"wp-block-heading\">18. Training and Certification Providers<\/h2>\n\n\n\n<p>The following institutes are presented as training resources (verify current course catalogs on their sites):<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>DevOpsSchool.com<\/strong>\n   &#8211; <strong>Suitable audience:<\/strong> DevOps engineers, SREs, cloud engineers, beginners to intermediate\n   &#8211; <strong>Likely learning focus:<\/strong> Azure fundamentals, cloud networking basics, DevOps workflows\n   &#8211; <strong>Mode:<\/strong> Check website\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.devopsschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>ScmGalaxy.com<\/strong>\n   &#8211; <strong>Suitable audience:<\/strong> DevOps and build\/release engineers, students\n   &#8211; <strong>Likely learning focus:<\/strong> SCM\/CI\/CD foundations, DevOps practices, related cloud tooling\n   &#8211; <strong>Mode:<\/strong> Check website\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.scmgalaxy.com\/<\/p>\n<\/li>\n<li>\n<p><strong>CLoudOpsNow.in<\/strong>\n   &#8211; <strong>Suitable audience:<\/strong> Cloud operations teams, platform engineers\n   &#8211; <strong>Likely learning focus:<\/strong> Cloud ops, monitoring, automation, operational readiness\n   &#8211; <strong>Mode:<\/strong> Check website\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.cloudopsnow.in\/<\/p>\n<\/li>\n<li>\n<p><strong>SreSchool.com<\/strong>\n   &#8211; <strong>Suitable audience:<\/strong> SREs, reliability engineers, operations teams\n   &#8211; <strong>Likely learning focus:<\/strong> Reliability engineering, observability, incident response, production operations\n   &#8211; <strong>Mode:<\/strong> Check website\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.sreschool.com\/<\/p>\n<\/li>\n<li>\n<p><strong>AiOpsSchool.com<\/strong>\n   &#8211; <strong>Suitable audience:<\/strong> Operations and SRE teams exploring AIOps\n   &#8211; <strong>Likely learning focus:<\/strong> AIOps concepts, automation, monitoring analytics\n   &#8211; <strong>Mode:<\/strong> Check website\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.aiopsschool.com\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">19. Top Trainers<\/h2>\n\n\n\n<p>These are listed as training resources\/platforms (verify current offerings and credentials directly on the sites):<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>RajeshKumar.xyz<\/strong>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps and cloud training (verify current scope on site)\n   &#8211; <strong>Suitable audience:<\/strong> Beginners to intermediate engineers\n   &#8211; <strong>Website URL:<\/strong> https:\/\/rajeshkumar.xyz\/<\/p>\n<\/li>\n<li>\n<p><strong>devopstrainer.in<\/strong>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps tooling and practices; may include cloud modules (verify)\n   &#8211; <strong>Suitable audience:<\/strong> DevOps learners and practitioners\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.devopstrainer.in\/<\/p>\n<\/li>\n<li>\n<p><strong>devopsfreelancer.com<\/strong>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps consulting\/training resources (verify current services)\n   &#8211; <strong>Suitable audience:<\/strong> Teams seeking practical DevOps guidance\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.devopsfreelancer.com\/<\/p>\n<\/li>\n<li>\n<p><strong>devopssupport.in<\/strong>\n   &#8211; <strong>Likely specialization:<\/strong> DevOps support and learning resources (verify)\n   &#8211; <strong>Suitable audience:<\/strong> Working engineers needing hands-on support\n   &#8211; <strong>Website URL:<\/strong> https:\/\/www.devopssupport.in\/<\/p>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">20. Top Consulting Companies<\/h2>\n\n\n\n<p>The following companies are presented neutrally as consulting resources; verify service specifics, case studies, and references directly with them.<\/p>\n\n\n\n<ol class=\"wp-block-list\">\n<li>\n<p><strong>cotocus.com<\/strong>\n   &#8211; <strong>Likely service area:<\/strong> Cloud\/DevOps consulting (verify current offerings)\n   &#8211; <strong>Where they may help:<\/strong> Network design review, migration planning, operational readiness\n   &#8211; <strong>Consulting use case examples:<\/strong><\/p>\n<ul>\n<li>Hub-spoke Azure Virtual Network rollout<\/li>\n<li>NSG\/route governance and policy implementation<\/li>\n<li>Hybrid connectivity planning (VPN\/ExpressRoute patterns)<\/li>\n<li><strong>Website URL:<\/strong> https:\/\/cotocus.com\/<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>DevOpsSchool.com<\/strong>\n   &#8211; <strong>Likely service area:<\/strong> DevOps and cloud consulting\/training services (verify current scope)\n   &#8211; <strong>Where they may help:<\/strong> Implementation support, platform enablement, skills development\n   &#8211; <strong>Consulting use case examples:<\/strong><\/p>\n<ul>\n<li>Landing zone networking baselines (VNet, subnets, NSGs)<\/li>\n<li>IaC enablement (Bicep\/Terraform) for network stacks<\/li>\n<li>Cost and security review for private endpoint adoption<\/li>\n<li><strong>Website URL:<\/strong> https:\/\/www.devopsschool.com\/<\/li>\n<\/ul>\n<\/li>\n<li>\n<p><strong>DEVOPSCONSULTING.IN<\/strong>\n   &#8211; <strong>Likely service area:<\/strong> DevOps and cloud consulting (verify current offerings)\n   &#8211; <strong>Where they may help:<\/strong> Architecture design, CI\/CD enablement, operations automation\n   &#8211; <strong>Consulting use case examples:<\/strong><\/p>\n<ul>\n<li>Secure Azure Virtual Network patterns for multi-environment deployments<\/li>\n<li>Observability and troubleshooting playbooks (Network Watcher, logs)<\/li>\n<li>Governance controls for public exposure reduction<\/li>\n<li><strong>Website URL:<\/strong> https:\/\/www.devopsconsulting.in\/<\/li>\n<\/ul>\n<\/li>\n<\/ol>\n\n\n\n<h2 class=\"wp-block-heading\">21. Career and Learning Roadmap<\/h2>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn before Azure Virtual Network<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Networking fundamentals:<\/li>\n<li>IP addressing, CIDR, subnetting<\/li>\n<li>Routing concepts (default routes, next hops)<\/li>\n<li>TCP\/UDP ports, stateful vs stateless filtering<\/li>\n<li>DNS fundamentals<\/li>\n<li>Basic Azure foundations:<\/li>\n<li>Subscriptions, resource groups, Azure RBAC<\/li>\n<li>Azure Resource Manager concepts<\/li>\n<li>Security basics:<\/li>\n<li>Principle of least privilege<\/li>\n<li>Network segmentation concepts<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">What to learn after Azure Virtual Network<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Advanced Azure Networking:<\/li>\n<li>Azure Firewall design and policy<\/li>\n<li>VPN Gateway and ExpressRoute (BGP concepts, redundancy)<\/li>\n<li>Private Link and private DNS architecture<\/li>\n<li>Azure Front Door \/ Application Gateway for ingress<\/li>\n<li>Virtual WAN for large-scale connectivity<\/li>\n<li>Operations and governance:<\/li>\n<li>Network Watcher tooling and workflows<\/li>\n<li>Azure Policy for network guardrails<\/li>\n<li>Log Analytics and Microsoft Sentinel for detection\/response<\/li>\n<li>Infrastructure as Code:<\/li>\n<li>Bicep or Terraform modules for network stacks<\/li>\n<li>CI\/CD for network changes with approvals<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Job roles that use it<\/h3>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Cloud Engineer \/ Cloud Administrator<\/li>\n<li>Cloud Network Engineer<\/li>\n<li>Solutions Architect<\/li>\n<li>DevOps Engineer \/ Platform Engineer<\/li>\n<li>Site Reliability Engineer (SRE)<\/li>\n<li>Security Engineer (cloud security \/ network security)<\/li>\n<\/ul>\n\n\n\n<h3 class=\"wp-block-heading\">Certification path (Azure)<\/h3>\n\n\n\n<p>Microsoft certifications change over time; verify the current list in official Microsoft Learn. Commonly relevant certification tracks include:\n&#8211; Azure Fundamentals (baseline)\n&#8211; Azure Administrator (practical operations)\n&#8211; Azure Network Engineer \/ specialty paths (if available\u2014verify current certification names)\n&#8211; Azure Solutions Architect (design-level)<\/p>\n\n\n\n<p>Start here:\n&#8211; https:\/\/learn.microsoft.com\/credentials\/<\/p>\n\n\n\n<h3 class=\"wp-block-heading\">Project ideas for practice<\/h3>\n\n\n\n<p>1) Build a hub-spoke topology with:\n   &#8211; Hub firewall\n   &#8211; Spoke workloads\n   &#8211; Forced tunneling UDRs\n2) Implement Private Endpoints for Storage + SQL and design private DNS resolution.\n3) Create an AKS cluster with controlled egress using NAT Gateway.\n4) Simulate hybrid connectivity with a VPN Gateway to a lab environment (cost-aware).\n5) Build a \u201cno public IP\u201d environment with Bastion and private-only workloads.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">22. Glossary<\/h2>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>Azure Virtual Network (VNet):<\/strong> A private, regional network boundary in Azure containing address space and subnets.<\/li>\n<li><strong>Address space:<\/strong> CIDR ranges assigned to a VNet (e.g., <code>10.10.0.0\/16<\/code>).<\/li>\n<li><strong>Subnet:<\/strong> A CIDR range within a VNet used to place resources (e.g., <code>10.10.1.0\/24<\/code>).<\/li>\n<li><strong>NIC (Network Interface):<\/strong> Virtual interface attached to a VM or other compute, holding private IP configuration.<\/li>\n<li><strong>NSG (Network Security Group):<\/strong> Stateful L3\/L4 packet filtering rules applied to subnets and\/or NICs.<\/li>\n<li><strong>UDR (User Defined Route):<\/strong> Custom route in a route table to control next hop.<\/li>\n<li><strong>Route table:<\/strong> Collection of routes associated to a subnet.<\/li>\n<li><strong>Next hop:<\/strong> Where Azure forwards traffic next (e.g., Virtual appliance, Internet, VNet local).<\/li>\n<li><strong>VNet peering:<\/strong> Private connection between VNets using Azure backbone routing.<\/li>\n<li><strong>Hub-spoke:<\/strong> Architecture with a central hub VNet providing shared services and multiple spoke VNets for workloads.<\/li>\n<li><strong>Private Endpoint:<\/strong> A private IP in your subnet that connects to an Azure service via Private Link.<\/li>\n<li><strong>Private Link:<\/strong> Technology enabling private connectivity to services via private endpoints.<\/li>\n<li><strong>Service endpoint:<\/strong> Extends VNet identity to supported services to restrict access to the VNet\/subnet.<\/li>\n<li><strong>NAT Gateway:<\/strong> Managed outbound SNAT service for a subnet with stable public IP egress.<\/li>\n<li><strong>VPN Gateway:<\/strong> Azure-managed gateway for site-to-site or point-to-site VPN connectivity.<\/li>\n<li><strong>ExpressRoute:<\/strong> Private connectivity using a dedicated circuit from on-premises to Microsoft.<\/li>\n<li><strong>Network Watcher:<\/strong> Azure service for network diagnostics and troubleshooting.<\/li>\n<li><strong>Forced tunneling:<\/strong> Routing pattern where internet-bound traffic is routed to an on-prem\/firewall next hop.<\/li>\n<li><strong>DDoS Protection:<\/strong> Azure service to protect against distributed denial-of-service attacks (typically for public endpoints).<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\">23. Summary<\/h2>\n\n\n\n<p>Azure Virtual Network is Azure\u2019s foundational <strong>Networking<\/strong> service for building private, IP-based networks in the cloud. It matters because it defines your isolation boundary, segmentation strategy, routing behavior, and the attachment point for critical capabilities like NSGs, VNet peering, private endpoints, and hybrid gateways.<\/p>\n\n\n\n<p>Cost-wise, the VNet itself is usually not the main expense\u2014<strong>traffic, gateways, firewalls, NAT, private endpoints, and logging<\/strong> are the real cost drivers. Security-wise, strong designs combine <strong>least-privilege RBAC<\/strong>, careful <strong>NSG and routing<\/strong>, and private access patterns (Private Endpoints + correct DNS), while minimizing public exposure.<\/p>\n\n\n\n<p>Use Azure Virtual Network whenever you need private connectivity, segmentation, hybrid integration, or private access to platform services. Next, deepen your skills by learning <strong>routing (UDRs), Private Link + private DNS<\/strong>, and <strong>hub-spoke architecture<\/strong> patterns from Microsoft Learn and the Azure Architecture Center.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Networking<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[40,50],"tags":[],"class_list":["post-503","post","type-post","status-publish","format-standard","hentry","category-azure","category-networking"],"_links":{"self":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/503","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/comments?post=503"}],"version-history":[{"count":0,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/posts\/503\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/media?parent=503"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/categories?post=503"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.devopsschool.com\/tutorials\/wp-json\/wp\/v2\/tags?post=503"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}