One page, eleven building blocks. For each one, the definition and then the points that actually decide whether a design works. The last point under each heading is usually the one that catches people.

VNet

Your own isolated network inside Azure’s physical network. Nothing from another tenant can reach it.

  • Sized with CIDR. A /16 gives 65,536 addresses and is the usual default.
  • Spans every availability zone in the region by default. You do not build one per zone.
  • Must not overlap with any network you might later peer or connect by VPN. Starting at 10.20.0.0/16 instead of 10.0.0.0/16 avoids the most common collision.

Subnet

A slice of the VNet’s address range, used to separate tiers.

  • Azure reserves five addresses in every subnet: the first four and the last. A /24 gives you 251, not 256.
  • A subnet cannot be resized while anything is in it. Leave gaps in the plan.
  • A subnet does not isolate anything on its own. Traffic between subnets is allowed by default.

Network Security Group

Allow and deny rules, attached to a subnet or to a single NIC.

  • Stateful. If a request is allowed in, the reply goes out. You never write an outbound rule for a response.
  • Lower priority number wins. Your rules sit between 100 and 4096. Azure’s defaults sit at 65000 and above.
  • The default AllowVnetInBound rule is why a database with no rules is reachable from every other subnet. Closing it means writing a deny with a lower number.
  • With an NSG on both subnet and NIC, inbound is checked subnet first, outbound NIC first. A deny in either one stops the packet.

Application Security Group

A named group of NICs, referenced from an NSG rule instead of a list of IP addresses.

  • Solves the case where addresses change, such as a scale set that grows from two instances to ten.
  • Works with an NSG, not instead of one. The rule still lives in the NSG.

Route table

Directions for traffic leaving a subnet. Attached to a subnet and only a subnet.

  • One subnet holds at most one route table. One route table can serve many subnets.
  • System routes already exist. Every subnet can reach the VNet, the internet and any peered network without you doing anything. A route table exists to override a default, not to enable traffic.
  • The common override is 0.0.0.0/0 to a firewall’s private IP, so egress is inspected. Never put that route on the firewall’s own subnet.
  • Routes are evaluated per NIC. When traffic goes somewhere unexpected, read the effective routes on the NIC, not the table you wrote.

VNet peering

Connects two VNets so resources in each can reach the other over private addresses.

  • Needs admin rights on both networks, and the address spaces must not overlap.
  • Azure adds the peering routes for you. You do not hand-edit the route tables.

Azure Firewall

The gate for the whole VNet, for traffic in both directions.

  • Lives in a subnet that must be named AzureFirewallSubnet, at least a /26. NSGs are not supported there.
  • Inbound reaches it through a DNAT rule: firewall public IP and a port you choose, translated to a private IP and the application port.
  • Outbound reaches it only if a route table sends it there.

Bastion

Azure’s managed jump host, so you can SSH or RDP into a VM that has no public IP.

  • Subnet must be named AzureBastionSubnet, at least a /26. Exact spelling, or Azure will not find it.
  • You connect from the portal over HTTPS. The VM only needs to allow port 22 from the Bastion subnet’s range.
  • One Bastion serves the whole VNet, and access becomes a role assignment you can audit instead of a private key on someone’s laptop.

Public IP

A separate resource you create and attach to something. There is no internet gateway in Azure and no public or private setting on a subnet.

  • What makes a resource reachable from outside is a public IP on a frontend: Application Gateway, load balancer, NAT gateway, firewall or Bastion.
  • Attaching one directly to a VM’s NIC works, and is how test machines get scanned within minutes. Avoid it.
  • New VMs no longer get implicit outbound internet access. With no public IP and no NAT gateway, the firewall route is the way out.

Load Balancer vs Application Gateway

Two load balancers, at different layers.

  • Application Gateway works at layer 7. It reads the host and path, routes /login and /payment to different pools, and can run a WAF. Put it in front of the web tier.
  • Azure Load Balancer works at layer 4. No HTTP inspection, so it is fast. Put it between tiers, as an internal load balancer.
  • The Application Gateway subnet must allow inbound ports 65200 to 65535 from the GatewayManager service tag, or the gateway reports unhealthy forever.
  • A user never reaches a VM. They reach the gateway, and the gateway reaches the VM.

Azure DNS

Turns the domain name into the gateway’s public IP. It is a lookup, not a hop. No application traffic passes through it.

  • Creating the zone does nothing until you set Azure’s four name servers at the registrar.
  • Use an alias record pointing at the public IP resource, not a copied address. It survives a rebuild, and it is allowed at the zone apex where a CNAME is not.

The order I check them in, when something cannot be reached: is there a public IP on the frontend, does the NSG allow it from that source, does a route send it somewhere else, is the application actually listening on that port.