Routing, Peering, Transit, and Inspection
Goal
Show how networks choose paths and how centralized or distributed connectivity changes ownership and failure behavior.
The Short Version
Routes choose the path, connectivity constructs make the path possible, and inspection controls what may traverse it.
Route evaluation, propagation, symmetry, and return paths are central to troubleshooting reachability. 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
Compare a peering mesh with a transit hub that includes shared inspection and controlled egress.
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
Route evaluation, propagation, symmetry, and return paths are central to troubleshooting reachability
Route evaluation, propagation, symmetry, and return paths are central to troubleshooting reachability. 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.
Direct peering suits bounded relationships; transit designs can centralize scale and policy but add shared dependencies
Direct peering suits bounded relationships; transit designs can centralize scale and policy but add shared dependencies. 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.
Inspection placement affects routing complexity, availability, cost, ownership, and the ability to preserve source context
Inspection placement affects routing complexity, availability, cost, ownership, and the ability to preserve source context. 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
Three application networks need shared on-premises access and outbound inspection, but only two may communicate with each other.
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
Assuming peering is transitive. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Designing only the forward route and forgetting the return path. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Centralizing inspection without designing its capacity, availability, bypass prevention, or owner. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
If Someone Asks You
When would you choose peering, transit, or a hub-and-spoke design?
A clear answer is:
Routes choose the path, connectivity constructs make the path possible, and inspection controls what may traverse it.
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
Routes choose the path, connectivity constructs make the path possible, and inspection controls what may traverse it.
Questions to Check Your Understanding
Why does the return path matter?
What changes when connectivity is centralized?
Which new failure and ownership concerns does inspection introduce?