Networking as Intentional Communication Paths
Goal
Open the chapter by reframing networking around required, forbidden, and observable communication.
The Short Version
Network architecture decides which paths may exist, why they exist, and how the team can verify them.
Start from actors, destinations, ports or protocols, direction, trust, latency, availability, and data sensitivity. 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
Use a communication matrix feeding a simple flow diagram of users, edge, application, data, managed services, and on-premises dependencies.
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
Start from actors, destinations, ports or protocols, direction, trust, latency, availability, and data sensitivity
Start from actors, destinations, ports or protocols, direction, trust, latency, availability, and data sensitivity. 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.
Connectivity and isolation are outcomes produced by routing, controls, identity, DNS, and service configuration together
Connectivity and isolation are outcomes produced by routing, controls, identity, DNS, and service configuration together. 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.
Every allowed path needs an owner and every critical path needs failure and diagnostic assumptions
Every allowed path needs an owner and every critical path needs failure and diagnostic assumptions. 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
An internal application needs employee access, a database, a private managed service, and an on-premises system.
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
Drawing a virtual network before listing required flows. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Assuming private addressing alone creates trusted communication. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Allowing broad east-west connectivity because segmentation seems operationally difficult. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
If Someone Asks You
What does it mean to design a network from communication paths?
A clear answer is:
Network architecture decides which paths may exist, why they exist, and how the team can verify them.
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
Network architecture decides which paths may exist, why they exist, and how the team can verify them.
Questions to Check Your Understanding
Which facts define a communication requirement?
Why are connectivity and isolation both designed outcomes?
What ownership information belongs on a critical path?
Further Study
NIST SP 800-207A: Cloud-Native Zero Trust Access Control - Use this authoritative source to deepen the section's provider-neutral control and decision model.