After this lesson, you will be able to: Build an Azure network: Virtual Networks and subnets, Network Security Groups, Azure Load Balancer vs Application Gateway, Azure DNS, and Azure CDN, and map each to its AWS equivalent.
Networking is where cloud architectures are won or lost, and Azure's model maps closely to AWS once you learn the vocabulary. This lesson covers the building blocks: the private network (VNet), the firewall rules (NSGs), the two load balancers and when to use each, and how traffic reaches your app through DNS and the CDN.
A Virtual Network (VNet) is your private, isolated network in Azure, the equivalent of an AWS VPC. You carve it into subnets (public-facing vs private/backend), exactly like AWS. Network Security Groups (NSGs) are the firewall rules: allow/deny lists by source, destination, port, and protocol, attached to a subnet or a NIC. They are Azure's answer to AWS security groups plus NACLs combined. The standard design is the same three-tier shape: a public subnet for the load balancer, a private subnet for app servers, and a locked-down subnet for the database, with NSGs only opening the ports each tier actually needs.
Azure gives you two load balancers and the choice matters. Azure Load Balancer is a layer-4 (TCP/UDP) balancer: fast, protocol-agnostic, no understanding of HTTP. Application Gateway is layer-7 (HTTP/HTTPS): it can route by URL path or hostname, terminate TLS, and includes an optional Web Application Firewall. Rule of thumb: if you are balancing HTTP traffic and want path-based routing, TLS termination, or a WAF, use Application Gateway; if you just need to spread raw TCP connections across backends, use Load Balancer. This parallels AWS's NLB (layer 4) vs ALB (layer 7) distinction.
The same three-tier network idea you'd build in AWS, in Azure vocabulary.
# Create a VNet with an app subnetaz network vnet create \--name app-vnet --resource-group myrg \--address-prefix 10.0.0.0/16 \--subnet-name app-subnet --subnet-prefix 10.0.1.0/24# Create an NSG and allow only HTTPS inaz network nsg create --name app-nsg --resource-group myrgaz network nsg rule create \--nsg-name app-nsg --resource-group myrg \--name allow-https --priority 100 \--destination-port-ranges 443 --access Allow --protocol Tcp# Attach the NSG to the subnet (rules now apply to everything in it)az network vnet subnet update \--vnet-name app-vnet --name app-subnet --resource-group myrg \--network-security-group app-nsg
Reaching for Application Gateway when a simple layer-4 Load Balancer would do, or vice versa (needing path routing/TLS/WAF and picking the layer-4 one). Over-permissive NSG rules (allowing 0.0.0.0/0 on SSH/RDP), the cloud equivalent of leaving the door open. Open only the ports each tier needs. Putting the database in a public subnet because it was easier. Backends belong in private subnets with no inbound internet route. Hardcoding resource IPs instead of using Azure DNS alias records, which break on resource recreation. Forgetting that NSG rules are priority-ordered; a broad allow at a low priority number can shadow a later deny.
Pick the right load balancer.
Sign in and purchase access to unlock this lesson.