Azure / Basic: scope, identity, location, and resources / Lesson 4

Virtual networks, subnets, and packet decisions

Reason about Azure Virtual Network addressing and traffic boundaries before choosing rules. Separate routing, network security, DNS, service exposure, and application authorization.

About 4 min readContent reviewed 2026-10-25

On this page

Lesson goals

Plan nonoverlapping address spaces and subnet capacity.
Distinguish a route from an allow rule.
Explain the limits of a static network model.

Addressing is a future connectivity constraint

Azure Virtual Network provides a logical private network context with address space and subnets. Plan nonoverlapping ranges for networks that may need peering or hybrid connectivity, including future growth rather than only the first application. A subnet is not automatically an application authorization boundary. Keep workload placement, delegated subnet requirements, service-specific reserved space, and IP demand documented. IPv4 and IPv6 have different constraints; do not reuse an IPv4 counting shortcut for every address family. Avoid assigning example addresses to real interfaces or probing routes merely to validate a teaching calculation.

Usable addresses are not the whole CIDR size

For an ordinary Azure IPv4 subnet, Azure reserves the first four addresses and the last address. A /24 therefore has 256 total addresses and 251 after this platform reservation, before considering the workload’s further requirements. Particular services can require dedicated or larger subnets, so this arithmetic is a starting point rather than a sizing guarantee. The standard-library example parses a synthetic prefix and subtracts the stated five addresses without making a network request. Include scale-out, replacement overlap, private endpoints, and other consumers in a real plan, then verify current service rules.

python Offline Azure IPv4 reservation arithmetic

from ipaddress import ip_network
subnet = ip_network("10.20.1.0/24")
reserved = 5
print(subnet.num_addresses, subnet.num_addresses - reserved)

Expected output

256 251

This applies the declared ordinary IPv4 reservation rule only. It does not allocate addresses or validate a service-specific subnet size.

Routing, security, and DNS answer different questions

Routing selects a next-hop path, network security rules allow or deny traffic according to their contract, and DNS resolves the name the client uses. A reachable IP with the wrong DNS or TLS name can still fail application access. Network security groups are stateful rule systems with priority and direction semantics; they are not a full application firewall or data-permission engine. A connection can be allowed at one boundary and denied at another. Plan explicit outbound connectivity instead of assuming an internet path exists under every subnet and service configuration. Troubleshooting should follow the actual source, destination, protocol, and port.

A static traffic matrix exposes missing decisions

The synthetic matrix permits web-to-application traffic and application-to-data traffic while rejecting direct client-to-data access. These are requirements, not deployable NSG rules; real rules also need validated prefixes, ports, priorities, and service-specific behavior. Identity authorization remains required on allowed paths. Review health probes, administration, name resolution, and dependency traffic so a narrow policy does not accidentally break necessary recovery operations. Do not fix a missing path by permitting every source and port. An offline matrix is useful because reviewers can challenge each intended edge before any cloud action occurs.

json A reviewable synthetic traffic matrix

{
  "model": "traffic-requirements-only",
  "flows": [
    {
      "from": "web",
      "to": "application",
      "decision": "allow-required-port"
    },
    {
      "from": "application",
      "to": "data",
      "decision": "allow-required-port"
    },
    {
      "from": "external-client",
      "to": "data",
      "decision": "deny"
    }
  ]
}

Expected output

two intended paths; direct external data path denied

The model is not an NSG deployment and performs no packet test. Required ports and identity policies are intentionally separate decisions.

Peering and private access need explicit topology

Virtual network peering connects supported networks but is not automatically transitive across an arbitrary chain. Hybrid connectivity and private service access need their own routing and DNS design. Private endpoints, service endpoints, and a service’s public endpoint controls are distinct mechanisms, explored later. Never infer that private addressing encrypts every connection or grants application access. Record the client location and resolver context when diagnosing reachability. This course performs no connection tests, packet captures, route changes, or cloud CLI operations; its examples establish addressing arithmetic and intended traffic decisions only.

Common errors and fixes

A route is assumed to grant traffic permission

Why it happens: Path selection and security policy are conflated.
How to fix it: Review routing and each allow/deny boundary separately.
Prevent it next time: Document source, destination, port, protocol, and identity.

A /24 is planned as 256 usable Azure IPv4 addresses

Why it happens: Platform reservations are omitted.
How to fix it: Subtract the ordinary reservation and verify service-specific needs.
Prevent it next time: Include growth and replacement overlap in sizing.

Peering is treated as automatic transitive routing

Why it happens: Topology behavior is assumed from a drawn chain.
How to fix it: Design and verify the intended supported connectivity path.
Prevent it next time: Review every required network pair and dependency.

Check your understanding

1. How many addresses remain in the stated /24 after Azure’s ordinary IPv4 reservation?

Show worked solution

There are 256 total addresses; subtracting five leaves 251 before additional workload requirements. That does not prove a specific managed service fits or that all 251 can be assigned to the application. Verify dedicated-subnet and service-specific rules separately.

2. An application has an allowed data role but cannot connect. What does that role not establish?