Forem: ramiayoub-priv

Azure Networking from Zero to Enterprise — Part 2: Bicep & Azure Verified Modules

ramiayoub-priv — Wed, 15 Apr 2026 16:34:33 +0000

Azure Networking from Zero to Enterprise — Part 2: Bicep & Azure Verified Modules

This is Part 2 of the series. In Part 1, we covered VNets, Subnets, NSGs, Route Tables, DNS, and Private Endpoints. Now we're picking up the tool we'll use to deploy all of it: Bicep.

What you'll learn in this part:

What Bicep is and why it exists
Bicep vs ARM templates vs Terraform — an honest comparison
Azure Verified Modules (AVM) — Microsoft's official module library
Writing and deploying your first VNet with subnets and NSGs in Bicep
Structuring a Bicep project for a multi-part series

What is Bicep?

Bicep is Azure's domain-specific language (DSL) for deploying Azure resources. It compiles down to ARM templates (JSON), but you never have to write or read that JSON yourself.

If you've ever opened a 500-line ARM template and felt your soul leave your body — Bicep is the fix.

// This is Bicep. Clean, readable, no curly-brace hell.
resource vnet 'Microsoft.Network/virtualNetworks@2024-01-01' = {
  name: 'vnet-hub'
  location: 'eastus2'
  properties: {
    addressSpace: {
      addressPrefixes: ['10.10.0.0/16']
    }
  }
}

The equivalent ARM JSON is roughly 3x longer. Bicep gives you:

Type safety — intellisense and compile-time validation in VS Code
Modules — split your deployment into reusable pieces
No state file — unlike Terraform, Bicep is stateless. Azure IS the state.
Day-zero support — new Azure features are available in Bicep immediately. Terraform providers can lag weeks or months.

Installing Bicep

Bicep ships with the Azure CLI. If you have az installed:

az bicep install
az bicep upgrade
az bicep version
# Should show v0.30+ (as of 2026)

Install the Bicep VS Code extension — it gives you autocomplete, error highlighting, and resource snippet generation. It's essential.

Bicep vs Terraform — An Honest Take

This is a hot topic, so let me be direct:

Factor	Bicep	Terraform
Multi-cloud	Azure only	Multi-cloud
State management	None (Azure is the state)	State file required (local, S3, blob, etc.)
New Azure feature support	Immediate (same day as ARM)	Delayed (depends on provider release)
Learning curve	Lower (if you know Azure)	Moderate
Module ecosystem	AVM (growing fast)	Terraform Registry (massive)
Drift detection	What-if deployments	`terraform plan`
Language	Declarative DSL	HCL (declarative DSL)
Tooling	VS Code extension, Azure CLI	VS Code extension, Terraform CLI

When to use Bicep:

You're Azure-only (most enterprises with Microsoft EA agreements)
You want no state file headaches (no backend config, no state locking, no state corruption)
You need day-zero support for new Azure features
Your team already knows Azure and ARM concepts

When to use Terraform:

You deploy to multiple clouds (AWS + Azure + GCP)
You need to manage non-Azure resources (GitHub repos, Datadog monitors, PagerDuty, etc.)
Your team already knows HCL

My take:

For Azure-native networking (which is what this series is about), Bicep wins. No state file means fewer things to break, and you get new networking features the same day Microsoft releases them. I've seen Terraform's AzureRM provider lag behind on features like Private Endpoint subnet-level policies, DNS Private Resolver, and Virtual Network Manager — features we'll use in this series.

Azure Verified Modules (AVM)

Here's where it gets interesting. Microsoft maintains an official library of production-ready Bicep modules called Azure Verified Modules.

Why AVM matters:

Without AVM, deploying a VNet with subnets, NSGs, and route tables means writing 200+ lines of Bicep. With AVM, it's ~30 lines.

AVM modules are:

Microsoft-maintained and regularly updated
Well-tested with CI/CD pipelines
Best-practice by default — they include diagnostic settings, locks, RBAC, tags
Published to the Bicep public registry — you reference them with a one-liner

Using an AVM module:

// Reference the AVM Virtual Network module from the public registry
module vnet 'br/public:avm/res/network/virtual-network:0.5.2' = {
  name: 'deploy-vnet-hub'
  params: {
    name: 'vnet-hub'
    location: 'eastus2'
    addressPrefixes: ['10.10.0.0/16']
    subnets: [
      {
        name: 'AzureFirewallSubnet'
        addressPrefix: '10.10.1.0/26'
      }
      {
        name: 'AzureBastionSubnet'
        addressPrefix: '10.10.2.0/26'
      }
      {
        name: 'snet-shared-services'
        addressPrefix: '10.10.4.0/24'
      }
    ]
  }
}

That's it. The module handles the rest — creating the VNet, subnets, applying default diagnostic settings, supporting optional parameters for peering, DNS servers, encryption, and more.

Finding AVM modules:

AVM website: https://aka.ms/avm — browse all available modules
Bicep Registry: br/public:avm/res/<provider>/<resource-type>:<version>
GitHub: https://github.com/Azure/bicep-registry-modules — source code, examples, and docs

Key networking modules we'll use in this series:

Module	Registry Path	Used In
Virtual Network	`br/public:avm/res/network/virtual-network`	Part 2, 3
NSG	`br/public:avm/res/network/network-security-group`	Part 2, 3
Route Table	`br/public:avm/res/network/route-table`	Part 3, 4
VNet Peering	(part of VNet module)	Part 3
Azure Firewall	`br/public:avm/res/network/azure-firewall`	Part 4
ExpressRoute Gateway	`br/public:avm/res/network/virtual-network-gateway`	Part 5
Bastion	`br/public:avm/res/network/bastion-host`	Part 6

Hands-On: Your First Bicep Deployment

Let's deploy the hub VNet from Part 1's design. We'll do it two ways: raw Bicep and then with AVM.

Option A: Raw Bicep

Create a file called main.bicep:

// ============================================
// Part 2: Hub VNet with Subnets and NSGs
// ============================================

targetScope = 'resourceGroup'

@description('Azure region for all resources')
param location string = resourceGroup().location

@description('Environment name used for naming')
param environment string = 'dev'

// --- NSG for shared services subnet ---
resource nsgSharedServices 'Microsoft.Network/networkSecurityGroups@2024-01-01' = {
  name: 'nsg-${environment}-shared-services'
  location: location
  properties: {
    securityRules: [
      {
        name: 'Allow-DNS-Inbound'
        properties: {
          priority: 100
          direction: 'Inbound'
          access: 'Allow'
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '53'
          sourceAddressPrefix: '10.0.0.0/8'
          destinationAddressPrefix: '*'
        }
      }
    ]
  }
}

// --- NSG for management subnet ---
resource nsgManagement 'Microsoft.Network/networkSecurityGroups@2024-01-01' = {
  name: 'nsg-${environment}-management'
  location: location
  properties: {
    securityRules: [
      {
        name: 'Deny-All-Inbound'
        properties: {
          priority: 4096
          direction: 'Inbound'
          access: 'Deny'
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '*'
          sourceAddressPrefix: '*'
          destinationAddressPrefix: '*'
        }
      }
    ]
  }
}

// --- Hub VNet ---
resource vnetHub 'Microsoft.Network/virtualNetworks@2024-01-01' = {
  name: 'vnet-${environment}-hub'
  location: location
  properties: {
    addressSpace: {
      addressPrefixes: ['10.10.0.0/16']
    }
    subnets: [
      {
        name: 'GatewaySubnet'
        properties: {
          addressPrefix: '10.10.0.0/26'
        }
      }
      {
        name: 'AzureFirewallSubnet'
        properties: {
          addressPrefix: '10.10.1.0/26'
        }
      }
      {
        name: 'AzureBastionSubnet'
        properties: {
          addressPrefix: '10.10.2.0/26'
        }
      }
      {
        name: 'snet-management'
        properties: {
          addressPrefix: '10.10.3.0/24'
          networkSecurityGroup: {
            id: nsgManagement.id
          }
        }
      }
      {
        name: 'snet-shared-services'
        properties: {
          addressPrefix: '10.10.4.0/24'
          networkSecurityGroup: {
            id: nsgSharedServices.id
          }
        }
      }
    ]
  }
}

// --- Outputs ---
output vnetId string = vnetHub.id
output vnetName string = vnetHub.name
output subnetIds array = [for subnet in vnetHub.properties.subnets: subnet.id]

Deploy it:

# Create a resource group
az group create --name rg-networking-dev --location eastus2

# Deploy
az deployment group create \
  --resource-group rg-networking-dev \
  --template-file main.bicep \
  --parameters environment=dev

# What-if (preview changes without deploying)
az deployment group what-if \
  --resource-group rg-networking-dev \
  --template-file main.bicep

Option B: The AVM Way (Recommended)

Same result, less code, more features out of the box:

// ============================================
// Part 2: Hub VNet using AVM Module
// ============================================

targetScope = 'resourceGroup'

param location string = resourceGroup().location
param environment string = 'dev'

// --- NSGs ---
module nsgSharedServices 'br/public:avm/res/network/network-security-group:0.5.0' = {
  name: 'deploy-nsg-shared-services'
  params: {
    name: 'nsg-${environment}-shared-services'
    location: location
    securityRules: [
      {
        name: 'Allow-DNS-Inbound'
        properties: {
          priority: 100
          direction: 'Inbound'
          access: 'Allow'
          protocol: '*'
          sourcePortRange: '*'
          destinationPortRange: '53'
          sourceAddressPrefix: '10.0.0.0/8'
          destinationAddressPrefix: '*'
        }
      }
    ]
  }
}

module nsgManagement 'br/public:avm/res/network/network-security-group:0.5.0' = {
  name: 'deploy-nsg-management'
  params: {
    name: 'nsg-${environment}-management'
    location: location
  }
}

// --- Hub VNet ---
module vnetHub 'br/public:avm/res/network/virtual-network:0.5.2' = {
  name: 'deploy-vnet-hub'
  params: {
    name: 'vnet-${environment}-hub'
    location: location
    addressPrefixes: ['10.10.0.0/16']
    subnets: [
      {
        name: 'GatewaySubnet'
        addressPrefix: '10.10.0.0/26'
      }
      {
        name: 'AzureFirewallSubnet'
        addressPrefix: '10.10.1.0/26'
      }
      {
        name: 'AzureBastionSubnet'
        addressPrefix: '10.10.2.0/26'
      }
      {
        name: 'snet-management'
        addressPrefix: '10.10.3.0/24'
        networkSecurityGroupResourceId: nsgManagement.outputs.resourceId
      }
      {
        name: 'snet-shared-services'
        addressPrefix: '10.10.4.0/24'
        networkSecurityGroupResourceId: nsgSharedServices.outputs.resourceId
      }
    ]
  }
}

output vnetId string = vnetHub.outputs.resourceId
output vnetName string = vnetHub.outputs.name

What's different with AVM?

Notice we didn't configure:

Diagnostic settings
Resource locks
Tags
RBAC

The AVM module supports all of these as optional parameters. When you need them, you add one line. When you don't, the module does the right thing by default.

Compare: the raw Bicep version is 100+ lines and only covers the basics. The AVM version is ~60 lines and gives you access to every feature the VNet resource supports — diagnostic settings, DNS servers, peering, encryption, flow timeout — all as optional params.

Project Structure for This Series

Here's how I organize the companion repo:

azure-networking-series/
├── part2-bicep/
│   ├── main.bicep           # Hub VNet deployment
│   ├── main.bicepparam      # Parameter file
│   └── README.md
├── part3-hub-spoke/
│   ├── main.bicep           # Hub + Spoke VNets + Peering
│   └── ...
├── part4-firewall/
│   ├── main.bicep           # NVA/Firewall + UDRs
│   └── ...
├── full-architecture/
│   ├── main.bicep           # Complete deployment
│   ├── modules/
│   │   ├── hub.bicep
│   │   ├── spoke.bicep
│   │   └── connectivity.bicep
│   └── README.md
└── README.md                # Series overview + architecture diagram

Each part's folder is self-contained — you can az deployment group create from any part folder and get a working deployment.

Bicep Tips That'll Save You Time

1. Always use `what-if` before deploying

az deployment group what-if --resource-group rg-networking-dev --template-file main.bicep

This shows you exactly what will be created, modified, or deleted — without touching anything. Use it every single time.

2. Use `.bicepparam` files instead of inline parameters

// main.bicepparam
using './main.bicep'

param location = 'eastus2'
param environment = 'prod'

az deployment group create --resource-group rg-networking-prod --parameters main.bicepparam

Cleaner than --parameters environment=prod location=eastus2 and you can commit them to Git per environment.

3. Use the VS Code extension's resource snippet

Type res- in VS Code and you'll get autocomplete for every Azure resource type. It generates the full resource skeleton with the latest API version.

4. Leverage `dependsOn` only when Bicep can't infer it

Bicep automatically detects dependencies when you reference one resource in another (like we did with nsgManagement.id in the subnet). You only need explicit dependsOn for implicit dependencies.

5. Use `@description` decorators

@description('The environment name (dev, staging, prod)')
@allowed(['dev', 'staging', 'prod'])
param environment string

These show up in the Azure Portal when someone deploys your template manually. Good practice, zero effort.

Summary

Concept	Key Takeaway
Bicep	Azure's native IaC language. Clean syntax, no state file, day-zero feature support
Bicep vs Terraform	Use Bicep for Azure-only. Use Terraform for multi-cloud
AVM	Microsoft's official module library. Production-ready, well-tested, saves you 50-70% of code
what-if	Always preview before deploying. Always
Project structure	One folder per part, self-contained, with parameter files per environment

What's Next

Part 3 and Part 4 are live!

Part 3: Hub/Spoke Architecture Deep Dive — VNet peering, transit routing, shared services, and why hub/spoke is the default enterprise topology — deployed with Bicep and AVM.
Part 4: Firewalling with Azure Firewall & NVAs — Azure Firewall vs Palo Alto NVAs, routing through the firewall, SNAT/DNAT, security policies, and cost optimization.

Read the full series at routetozero.dev/blog.

Resources

About the Author

I'm a cloud network engineer specializing in Azure enterprise architectures — hub/spoke, ExpressRoute, NVAs, and infrastructure-as-code with Bicep. If you're building something similar in your org and want a second pair of eyes, feel free to reach out.

Found this useful? Follow this blog to get notified when Part 3 drops — we're building the hub/spoke topology. Drop your questions in the comments, I read every one.

Azure Networking from Zero to Enterprise — Part 1: Networking Basics

ramiayoub-priv — Wed, 15 Apr 2026 15:31:08 +0000

Azure Networking from Zero to Enterprise — Part 1: Networking Basics

This is Part 1 of a multi-part series where we'll go from the absolute basics of Azure networking all the way to deploying a production-grade hub/spoke architecture with a firewall NVA, on-premises connectivity via ExpressRoute, and full DNS integration — all deployed with Bicep.

What you'll learn in this part:

What a Virtual Network (VNet) is and how it differs from on-prem networking
Subnets, address spaces, and CIDR planning
Network Security Groups (NSGs) — the first line of defense
Route Tables and User-Defined Routes (UDRs)
Azure DNS basics — what resolves where and why it matters
Service Endpoints vs Private Endpoints — when to use which

Why Azure Networking Matters

If you're a cloud engineer, solutions architect, or DevOps professional working with Azure, networking is the foundation everything else sits on. Get it wrong, and you'll spend months untangling routing issues, firewall misconfigurations, and DNS headaches. Get it right from the start, and everything else — compute, databases, security — just clicks into place.

The problem? Azure networking has a lot of moving pieces, and Microsoft's documentation, while comprehensive, is scattered across hundreds of pages. This series aims to give you the complete picture in one place, with real-world opinions and working code.

Virtual Networks (VNets)

A Virtual Network is Azure's fundamental networking construct. Think of it as your private, isolated network in the cloud — similar to a VLAN or a dedicated IP segment in your on-premises data center, but software-defined.

Key properties of a VNet:

Region-scoped: A VNet lives in a single Azure region. You can't stretch a VNet across regions (you'd peer two VNets for that).
Address space: You assign one or more CIDR blocks (e.g., 10.0.0.0/16). This is the total IP range available to the VNet.
Isolation: VNets are completely isolated from each other by default. Two VNets with the same address space won't conflict — they simply can't talk to each other unless you explicitly connect them.
Free: VNets themselves are free. You pay for what goes through them (gateways, peering traffic, etc.).

Creating a VNet — what you need to decide:

Address space size. Use RFC 1918 ranges: 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. For enterprise, I recommend using a /16 per VNet (65,536 addresses) which gives you room to grow. Don't be stingy with IP space in the cloud — running out of addresses in a VNet is a pain to fix later.
Avoid overlaps. If you plan to connect to on-premises networks (via VPN or ExpressRoute), your Azure address space must NOT overlap with your on-prem ranges. This is the number one mistake I see in enterprise deployments. Map out all your address spaces across on-prem and cloud before you create a single VNet.
Region placement. Deploy the VNet in the same region as your workloads. Cross-region traffic costs money and adds latency.

Example:
On-prem range:    10.1.0.0/16
Azure Hub VNet:   10.10.0.0/16
Azure Spoke 1:    10.20.0.0/16
Azure Spoke 2:    10.30.0.0/16

Subnets

A subnet is a subdivision of your VNet's address space. Every resource you deploy (VMs, load balancers, private endpoints) goes into a subnet.

Subnet design principles:

Plan ahead. You can resize subnets later, but only if they're empty. Moving resources between subnets is disruptive.
Separate by function, not by team. Create subnets like snet-workload, snet-data, snet-privateendpoints, snet-appgw — not snet-teamalpha.
Azure reserves 5 IPs per subnet. The first 4 and the last IP address in every subnet are reserved. A /28 gives you 16 addresses minus 5 = 11 usable. Keep this in mind for small subnets.
Some services need dedicated subnets. Azure Application Gateway, Azure Firewall, VPN Gateway, Azure Bastion, and several others require their own dedicated subnet, often with specific naming (like AzureBastionSubnet or GatewaySubnet).

Common subnet layout for a hub VNet:

10.10.0.0/16 (Hub VNet)
├── GatewaySubnet:          10.10.0.0/26    (VPN/ExpressRoute Gateway)
├── AzureFirewallSubnet:    10.10.1.0/26    (Azure Firewall or NVA)
├── AzureBastionSubnet:     10.10.2.0/26    (Azure Bastion)
├── snet-management:        10.10.3.0/24    (Jump boxes, monitoring)
├── snet-shared-services:   10.10.4.0/24    (DNS forwarders, AD DCs)
└── snet-privateendpoints:  10.10.5.0/24    (Private Endpoints for shared services)

Common subnet layout for a spoke VNet:

10.20.0.0/16 (Spoke VNet - Workload A)
├── snet-app:               10.20.1.0/24    (Application tier)
├── snet-data:              10.20.2.0/24    (Database tier)
├── snet-privateendpoints:  10.20.3.0/24    (Private Endpoints)
└── snet-integration:       10.20.4.0/24    (App Service VNet integration)

Network Security Groups (NSGs)

NSGs are Azure's stateful firewall at the subnet (or NIC) level. They're your first line of defense and should be applied to every subnet (except for those that don't support them, like GatewaySubnet).

How NSGs work:

An NSG contains inbound and outbound rules.
Each rule has a priority (100–4096, lower = processed first), source, destination, port, protocol, and action (Allow or Deny).
Azure has default rules you can't delete (allow VNet-to-VNet, allow outbound internet, deny all inbound from internet, etc.). You can override them with higher-priority rules.
NSGs are stateful — if you allow inbound traffic on port 443, the response traffic is automatically allowed.

NSG best practices:

Apply NSGs at the subnet level, not individual NICs (unless you have a very specific reason). Subnet-level NSGs are easier to manage and audit.
Use Application Security Groups (ASGs) to group VMs by role instead of using IP addresses in rules. E.g., create an ASG called asg-webservers and reference it in rules — when you add a new web server, it inherits the rules automatically.
Don't rely solely on NSGs for east-west traffic control in enterprise. They're great for basic segmentation, but for advanced inspection (IDS/IPS, URL filtering, threat intelligence), you need a firewall NVA — which we'll cover in Part 4.
Enable NSG flow logs for troubleshooting and compliance. Send them to a Log Analytics workspace.

Example NSG rule:

Priority: 100
Name: Allow-HTTPS-Inbound
Source: Internet
Destination: asg-webservers
Port: 443
Protocol: TCP
Action: Allow

Route Tables and User-Defined Routes (UDRs)

By default, Azure routes traffic between subnets within a VNet automatically (system routes). It also routes to the internet via a default 0.0.0.0/0 route. But in enterprise architectures, you almost always need to override these defaults.

Why UDRs matter:

In a hub/spoke model (which we'll build in Part 3), you want all traffic to flow through a central firewall. Without UDRs, traffic between spoke VNets would go directly via peering — bypassing your firewall entirely. UDRs let you force traffic through a specific next hop.

Key concepts:

Route Table: A collection of routes that you associate with one or more subnets.
User-Defined Route (UDR): A custom route you create to override Azure's default routing.
Next Hop Types:
- VirtualAppliance — send traffic to a specific IP (your firewall NVA)
- VirtualNetworkGateway — send to VPN/ExpressRoute gateway
- VnetLocal — keep within the VNet
- Internet — route to internet
- None — drop the traffic (black hole)

Example: Force all internet-bound traffic through a firewall

Route Table: rt-spoke-workload
├── Route: to-internet
│   Prefix: 0.0.0.0/0
│   Next Hop: VirtualAppliance → 10.10.1.4 (firewall NVA IP)
├── Route: to-onprem
│   Prefix: 10.1.0.0/16
│   Next Hop: VirtualAppliance → 10.10.1.4
└── Route: to-hub-shared
    Prefix: 10.10.0.0/16
    Next Hop: VirtualAppliance → 10.10.1.4

Important: When you associate a route table with a subnet, it only affects traffic leaving that subnet. The firewall's own subnet should NOT have a UDR pointing to itself (routing loop). This is a common mistake.

Azure DNS Basics

DNS in Azure is one of those things that seems simple until you start dealing with hybrid environments. Let me break down the layers:

1. Azure-provided DNS (default)

Every VNet gets Azure's built-in DNS (168.63.129.16) for free. It resolves:

Public DNS names (google.com, etc.)
Azure internal names (vmname.internal.cloudapp.net)
Private Endpoint DNS (if integrated correctly)

For simple deployments, this is fine. For enterprise with on-prem connectivity, you'll need more.

2. Azure DNS Public Zones

This is Azure's managed DNS for public domains you own. Instead of using GoDaddy/Cloudflare for DNS hosting, you can point your domain's nameservers to Azure DNS. Not directly relevant to networking architecture, but useful to know.

3. Azure DNS Private Zones

This is where it gets important for enterprise:

A Private DNS Zone (e.g., privatelink.database.windows.net) allows you to create DNS records that are only resolvable within your VNets.
When you create a Private Endpoint for an Azure service (like SQL Database), Azure can auto-create a DNS record in the linked Private Zone so mydb.database.windows.net resolves to the private IP.
You link Private DNS Zones to VNets. Linked VNets can resolve records in the zone.

4. The Hybrid DNS Problem

When you connect on-premises to Azure:

On-prem servers need to resolve Azure private DNS names (e.g., mydb.privatelink.database.windows.net)
Azure VMs might need to resolve on-prem DNS names (e.g., dc01.corp.local)

Solution: Conditional Forwarders

On-prem DNS Server:
  "For *.privatelink.database.windows.net → forward to 10.10.5.10" (DNS forwarder VM in Azure)

Azure DNS Forwarder (10.10.5.10):
  "For *.corp.local → forward to 10.1.0.5" (on-prem DC)
  "Everything else → forward to 168.63.129.16" (Azure DNS)

We'll set this up properly in Part 5 with actual configuration.

Note: Azure now offers DNS Private Resolver as a managed service that replaces the need for DNS forwarder VMs. We'll cover both approaches.

Service Endpoints vs Private Endpoints

Both are designed to let your VNet resources access Azure PaaS services (Storage, SQL, Key Vault, etc.) privately. But they work very differently.

Service Endpoints

Enables a direct route from your subnet to the Azure service over Microsoft's backbone network.
The PaaS service still has a public IP, but traffic from your subnet takes an optimized private path.
Free to use.
Limitations: Only works from the VNet with the service endpoint enabled. Doesn't work from on-premises or peered VNets (without extra config). The PaaS service's public endpoint still exists.

Private Endpoints

Creates a private IP address in your subnet that maps to a specific PaaS resource.
Traffic goes entirely over your private network. The PaaS service effectively gets a NIC in your VNet.
Works from anywhere that can reach the private IP — other VNets, on-prem via VPN/ExpressRoute.
Costs money: ~$7.30/month per endpoint + $0.01/GB processed.
Requires DNS configuration (Private DNS Zones) to resolve the service name to the private IP.

When to use which:

Scenario	Use
Simple workload, single VNet, no on-prem	Service Endpoint (free, easy)
Enterprise, hub/spoke, on-prem connectivity	Private Endpoint (more secure, works everywhere)
Compliance requires no public IP on PaaS	Private Endpoint + disable public access

In this series, we'll primarily use Private Endpoints because we're building an enterprise architecture.

Summary

Here's what we covered:

Concept	What It Does	Key Takeaway
VNet	Isolated private network in Azure	Use /16 per VNet, avoid address space overlaps
Subnet	Segment within a VNet	Plan by function, remember Azure reserves 5 IPs
NSG	Stateful firewall at subnet/NIC level	Apply to every subnet, use ASGs, enable flow logs
Route Table / UDR	Override default routing	Essential for forcing traffic through a firewall
Azure DNS	Name resolution	Private Zones + conditional forwarding for hybrid
Service Endpoints	Optimized path to PaaS	Free, simple, limited to local VNet
Private Endpoints	Private IP for PaaS services	Enterprise-grade, works with on-prem, needs DNS

What's Next

In Part 2, we'll cover Bicep and Azure Verified Modules (AVM) — the infrastructure-as-code language we'll use to deploy everything in this series. You'll learn why Bicep over Terraform (for Azure-native work), how AVM modules save you from reinventing the wheel, and we'll deploy our first VNet with subnets and NSGs in code.

If you want to follow along with the code, the companion repo will be linked here once Part 2 drops.

Resources

If you're studying for the AZ-700 (Azure Network Engineer Associate) certification, this series covers most of the exam objectives. Here's the official study path:

📘 Microsoft Learn: AZ-700 Study Guide
🛠️ diagrams.net — Free tool for drawing Azure network diagrams (I use it for all my architecture work)

About the Author

Found this useful? Follow this blog to get notified when Part 2 drops — we're building all of this in Bicep. Drop your questions in the comments, I read every one.

Forem: ramiayoub-priv

Azure Networking from Zero to Enterprise — Part 2: Bicep & Azure Verified Modules

Azure Networking from Zero to Enterprise — Part 2: Bicep & Azure Verified Modules

What is Bicep?

Installing Bicep

Bicep vs Terraform — An Honest Take

When to use Bicep:

When to use Terraform:

My take:

Azure Verified Modules (AVM)

Why AVM matters:

Using an AVM module:

Finding AVM modules:

Hands-On: Your First Bicep Deployment

Option A: Raw Bicep

Deploy it:

Option B: The AVM Way (Recommended)

What's different with AVM?

Project Structure for This Series

Bicep Tips That'll Save You Time

1. Always use what-if before deploying

2. Use .bicepparam files instead of inline parameters

3. Use the VS Code extension's resource snippet

4. Leverage dependsOn only when Bicep can't infer it

5. Use @description decorators

Summary

What's Next

Resources

About the Author

Azure Networking from Zero to Enterprise — Part 1: Networking Basics

Azure Networking from Zero to Enterprise — Part 1: Networking Basics

Why Azure Networking Matters

Virtual Networks (VNets)

Key properties of a VNet:

Creating a VNet — what you need to decide:

Subnets

Subnet design principles:

Common subnet layout for a hub VNet:

Common subnet layout for a spoke VNet:

Network Security Groups (NSGs)

How NSGs work:

NSG best practices:

Example NSG rule:

Route Tables and User-Defined Routes (UDRs)

Why UDRs matter:

Key concepts:

Example: Force all internet-bound traffic through a firewall

Azure DNS Basics

1. Azure-provided DNS (default)

2. Azure DNS Public Zones

3. Azure DNS Private Zones

4. The Hybrid DNS Problem

Service Endpoints vs Private Endpoints

Service Endpoints

Private Endpoints

When to use which:

Summary

What's Next

Resources

About the Author

1. Always use `what-if` before deploying

2. Use `.bicepparam` files instead of inline parameters

4. Leverage `dependsOn` only when Bicep can't infer it

5. Use `@description` decorators