Address planning starts with relationships, not portal defaults
A virtual network is an Azure address and routing boundary. A subnet is a defined part of its address space, used for placing supported resources and applying network-level controls. Microsoft AZ-104 administrators need to create and manage these elements, choose non-overlapping addresses, and understand the effect of public IP and outbound connectivity settings. A VNet without an address plan can be technically deployable yet impossible to peer with an existing corporate network whose private ranges overlap.
Consider an organization with a hub network, one production workload and one disposable testing environment. Reserve a distinct CIDR block for each intended VNet and plan subnet sizes before deploying NICs, gateways, private endpoints or delegated services. A subnet does not become a security boundary merely because it has a different name; NSGs, routes, identities and service controls enforce the desired traffic behavior.
Calculate CIDR capacity including reserved addresses
Suppose a planned VNet uses 10.40.0.0/16 and its web, application and data subnets use 10.40.1.0/24, 10.40.2.0/24 and 10.40.3.0/24 respectively. Those three /24 ranges do not overlap and each contains 256 addresses before Azure reservations. Microsoft reserves five IP addresses in a subnet, so that leaves 251 normally assignable addresses in each /24. More constrained delegated services can have additional minimum-size requirements.
Design for future scaling, not only today’s one VM. Consider VM instances, application gateways, private endpoints and any platform-managed resources that consume subnet capacity. A very small subnet can be cheap in address space but expensive in migration effort when a service must scale. The current VNet and subnet guidance documents reserved addresses and planning considerations.
Plan non-overlapping networks before peering or VPN
Peering requires a coherent address space; overlapping private address ranges are an operational problem when networks must communicate. The same principle applies to hybrid VPN or ExpressRoute connectivity, where an on-premises network may already use common 10.0.0.0/8 or 192.168.0.0/16 segments. Coordinate with network administrators rather than choosing an arbitrary convenient default.
Before peering virtual networks, reserve nonoverlapping address spaces and decide where each subnet and routing responsibility belongs. A peering marked Connected does not correct overlapping prefixes, wrong DNS answers or a return path blocked by a user-defined route. Address planning should make those future connectivity checks possible without renumbering an entire workload.
Distinguish NIC private addresses from public IP resources
A VM network interface normally has a private IP within a subnet, allocated under supported dynamic or static private-address configuration. A public IP address is a separately managed Azure resource that can be associated with supported frontends or interfaces. Creating a public IP does not by itself configure a healthy listener, permit inbound flows, or expose every VM behind the VNet.
Modern Azure public IP choices must account for the retirement of Basic SKU public IP addresses on September 30, 2025. Microsoft’s public IP guidance explains current Standard configuration and association. Do not teach creation of a new Basic SKU address as a normal 2026 deployment path. Choose the approved SKU, allocation, IP version and zone behavior according to service and region support.
Inbound exposure and outbound egress are different decisions
A frontend public IP can support inbound traffic under an appropriate NSG and application listener, while a private VM may need an explicit outbound route to reach package repositories or a SaaS endpoint. Do not attach public IPs to every VM merely to enable internet egress. A NAT Gateway, supported load-balancer outbound configuration, Azure Firewall or approved network appliance can provide a more deliberate egress architecture.
Azure changed private subnet defaults for newly created VNets under API versions released after March 31, 2026; the exact behavior depends on the deployment method and API version. New private subnets do not rely on implicit default outbound access, and legacy VNets are not automatically changed. The default outbound reference explains the transition. Verify the actual subnet setting rather than assuming every 2026 VNet behaves identically.
Choose a subnet security and routing model
Map each flow before placing an NSG: user to web HTTPS, web to application over a defined internal port, application to data service, and administrator to approved management endpoints. NSG rules filter supported traffic; user-defined routes select next hops; ASGs help group supported NICs for rule targeting. None of them automatically authenticates an Azure user to a service.
NSG and routing rules require checking the effective rules and next hops for the traffic path. Use it after the address plan is created: a connected subnet may still be blocked by a high-priority rule or steered to an unavailable appliance. Document request and return paths, not just a successful ping from one test machine.
Make private service connectivity and DNS intentional
A private endpoint provides a service-specific private connection with related DNS expectations. It may consume a private address from an approved subnet under supported constraints. A service endpoint has different network and addressing behavior; it does not place the PaaS service itself as a private IP in the subnet. Network planning should reserve the required subnet capacity and identify which client networks need to resolve the service hostname.
Hybrid and peered-network clients may use custom resolvers. Test the real hostname and returned address from each source VNet. If one client resolves to a public endpoint, adding a role assignment will not fix its network path. Private DNS resolution and resolver forwarding should be checked before changing role assignments or access policies.
Create a controlled network administration lab
Prepare a disposable resource group and VNet using a non-overlapping address range. Create web and application subnets sized for planned VM and service capacity; keep the data or private endpoint tier separate when appropriate. Apply the permitted NSG and routing rules and document all public IP resources. Define an explicit outbound method for private subnets whose workloads need public endpoints.
Deploy two small test VMs or equivalent supported endpoints. Verify their private IPs and actual subnet placement, then test allowed and denied communication. Introduce one wrong subnet route and one wrong DNS answer separately. Confirm the issue using effective routes, effective security rules, hostname resolution and application behavior. A successful Azure create operation is only the beginning of the validation.
Treat changing connectivity as a potentially disruptive operation
Changing a subnet’s NSG association, route table, delegation, address prefix or outbound option can affect every resource using that subnet. Before a production change, inventory attached NICs, private endpoints and services with delegated-subnet requirements. Identify maintenance expectations and the supported constraints of each resource. The smallest configuration update is not necessarily the smallest operational change.
Make one safe alteration in a test environment, observe its effect on client traffic and verify recovery after reverting. Keep a rollback record with the prior subnet properties. A VNet architecture document should describe which team owns network address reservations so future Azure, on-premises or multicloud integrations do not allocate overlapping ranges.
Evidence required before approving a subnet change
Finish with an address allocation table, VNet and subnet diagram, private/public IP inventory, expected inbound and outbound path, and a short matrix of permitted and denied flows. For each subnet record capacity after Azure’s reserved addresses, delegated services, attached NICs and private endpoints, effective routes, NSG associations and the approved egress design. A proposed address-space change is incomplete until existing peering or hybrid routes and the return path have been checked.
If an isolated subnet cannot reach an external package repository, start with DNS, the actual destination route, supported NAT or alternate outbound method, and filtering rules. Do not grant a broader subscription role or attach public IPs indiscriminately to solve a networking fault. Record the observed evidence and test one corrective change at a time; the goal is a network whose allowed traffic and failure behavior can be explained by the next administrator.