Address Spaces, Subnets, and Segmentation Boundaries
Goal
Explain how addressing and placement boundaries support routing, growth, policy, and operational ownership.
The Short Version
Addressing identifies locations; segmentation expresses where different communication rules and ownership expectations begin.
Address plans must account for overlap, hybrid connectivity, managed services, scaling, and organizational allocation. The important architecture move is to make the boundary explicit before selecting a cloud feature. A feature can automate a decision, but it cannot decide the organization's risk tolerance, ownership model, or acceptable failure behavior.
Use this section as a decision tool. Name the actor or producer, the protected or affected resource, the contract between them, the conditions under which the action is allowed, and the evidence that will show whether the design worked.
Mental Model
Show one address space divided into edge, application, data, and management segments, then overlay routes and policy controls.
flowchart LR
N1["Source"] --> N2["Name resolution"] --> N3["Route"] --> N4["Policy and inspection"] --> N5["Destination"] --> N6["Flow evidence"]Read the diagram from left to right, then review it from right to left. The forward pass explains how work succeeds. The reverse pass asks whether an operator can trace an outcome back to its initiating identity, input, policy, route, or contract.
Architecture Decisions
| Decision dimension | Question to make explicit |
|---|---|
| Reachability | Which source must communicate with which destination? |
| Addressing | Can address spaces coexist without overlap? |
| Routing | Which path should traffic take in each direction? |
| Control | Where are allow, deny, inspection, and egress decisions enforced? |
| Ownership | Who changes routes, DNS, firewall policy, and hybrid links? |
The answers should be recorded with the workload design. If the answer is merely "the platform default," the team has discovered an assumption, not completed an architecture decision.
Core Ideas
Address plans must account for overlap, hybrid connectivity, managed services, scaling, and organizational allocation
Address plans must account for overlap, hybrid connectivity, managed services, scaling, and organizational allocation. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.
Subnets are useful placement and routing boundaries but are not a complete security model
Subnets are useful placement and routing boundaries but are not a complete security model. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.
Segmentation may follow trust, environment, workload tier, data sensitivity, ownership, or operational lifecycle
Segmentation may follow trust, environment, workload tier, data sensitivity, ownership, or operational lifecycle. Make the owner, boundary, failure behavior, and evidence explicit. That turns the concept from a configuration choice into a design decision that another team can review and operate.
Provider Lenses
AWS implements these jobs with VPCs, subnets, route tables, security groups, network ACLs, peering or Transit Gateway, VPN or Direct Connect, and VPC endpoints. Azure uses virtual networks, subnets, route tables, network security groups, peering or Virtual WAN, VPN Gateway or ExpressRoute, and private endpoints. Defaults, transitivity, DNS integration, and inspection paths differ, so translate the design intent before selecting a feature.
Provider lenses are useful for implementation planning, but they should come after the provider-neutral decision. This keeps the reasoning portable and makes differences in defaults, scope, and operational responsibility easier to detect.
Example: Applying the Decision
Allocate space for production and non-production application tiers while avoiding overlap with an acquired company's on-premises network.
Document every required flow, reserve non-overlapping addresses, centralize shared connectivity only where ownership benefits, keep application segmentation close to the workload, and test DNS and return routing from every connected environment.
A review should finish with named owners, a testable success path, expected failure modes, and observable evidence. That is more useful than a diagram that only proves the components can connect.
Common Mistakes
Choosing address ranges without checking connected environments. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Creating a subnet for every small component without a durable boundary reason. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Assuming two resources in different subnets cannot communicate. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
If Someone Asks You
What is the difference between subnetting and segmentation?
A clear answer is:
Addressing identifies locations; segmentation expresses where different communication rules and ownership expectations begin.
I would then show the decision path, the responsibility boundary, and the evidence used to review it. That explanation connects the technical mechanism to its architecture purpose.
What You Should Remember
Addressing identifies locations; segmentation expresses where different communication rules and ownership expectations begin.
Questions to Check Your Understanding
Why does address overlap become an architecture problem?
Which concerns can justify a segmentation boundary?
What determines actual reachability between segments?