How does Azure networking work — VNet, NSG, Azure Firewall

Crisp answer: A VNet is your isolated network in Azure. Subnets divide it. NSGs filter traffic at subnet or NIC level. Azure Firewall sits at the perimeter and provides centralised, stateful, FQDN-aware filtering.

VNet:

- Region-scoped: a VNet exists in one region
- CIDR range: e.g. 10.0.0.0/16
- Contains subnets carved from the CIDR
- Isolated by default — no connectivity to other VNets or on-premises
  without explicit configuration
- Spans all availability zones in the region

Subnets:

- Public subnet: associated with a route table that has a route to
  an Internet Gateway (or has resources with public IPs)
- Private subnet: no direct internet access, outbound via NAT Gateway
  or Azure Firewall
- Service-dedicated subnets: some services require their own subnet
  (Azure Firewall, API Management, App Gateway, Bastion)
- Azure reserves 5 IPs per subnet (first 4 + last 1)

NSG — Network Security Group:

- Stateful packet filter (return traffic auto-allowed)
- Applied at subnet level or NIC level (or both)
- Rules: allow/deny by protocol, port, source/destination IP or service tag
- Evaluated in priority order (lower number = higher priority)
- Default rules: allow VNet inbound, allow Azure LB inbound, deny all
  other inbound; allow VNet outbound, allow internet outbound

Common service tags (no need to hardcode IPs):
  AzureMonitor    — Azure Monitor endpoints
  Storage         — Azure Storage endpoints
  Sql             — Azure SQL endpoints
  AzureCloud      — all Azure datacenter IPs
  Internet        — public internet

Azure Firewall:

- Managed, stateful, L7 network firewall
- Sits in its own subnet (AzureFirewallSubnet, minimum /26)
- Route table forces all subnet traffic through the firewall (UDR)
- Capabilities:
    FQDN filtering: allow *.ubuntu.com, deny *.malware.com
    Network rules: IP/port allow/deny (like NSG but centralised)
    Application rules: HTTP/HTTPS with TLS inspection (Premium SKU)
    Threat intelligence: block known malicious IPs and domains
    DNAT rules: inbound port forwarding

NSG vs Azure Firewall:

VNet Peering:

- Private connectivity between two VNets over Microsoft backbone
- Non-transitive: A-B and B-C does not mean A can reach C
- Works across regions (global peering) and across subscriptions
- No encryption overhead — traffic stays on Microsoft network
- Hub-and-spoke: one hub VNet peers with many spoke VNets;
  hub contains shared services (Firewall, Bastion, DNS)

Private Endpoint:

- Brings an Azure service (Storage, SQL, Key Vault, etc.) into your VNet
  with a private IP from your subnet
- Traffic to the service never leaves Microsoft network
- Requires a Private DNS Zone to resolve the service FQDN to the
  private IP instead of the public IP

DNS flow without Private Endpoint:
  myaccount.blob.core.windows.net → 20.150.x.x (public IP)

DNS flow with Private Endpoint:
  myaccount.blob.core.windows.net
  → myaccount.privatelink.blob.core.windows.net
  → 10.0.1.5 (private IP in your VNet)

What to say in the interview:

"For micro-segmentation within a VNet I use NSGs — they are free, stateful, and work at the subnet or NIC level. For centralised perimeter control across all workloads I use Azure Firewall with a hub VNet and UDRs forcing traffic through it. The key thing NSGs cannot do is FQDN filtering — I cannot write an NSG rule that allows traffic to ubuntu.com but blocks everything else on port 80. That is where Azure Firewall earns its cost. Private Endpoints are now standard for any service that holds sensitive data — storage, SQL, Key Vault — so it never traverses the public internet."