Designing Connectivity and Ownership for an Internal Application
Goal
Apply the chapter's path model to an application spanning employees, cloud services, and on-premises dependencies.
The Short Version
A network design is complete when every required path, prohibited path, failure mode, and owner is explicit.
A communication matrix should precede the provider topology. 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
Create a numbered end-to-end path diagram plus a small ownership table for workload, network platform, security, DNS, and on-premises teams.
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
A communication matrix should precede the provider topology
A communication matrix should precede the provider topology. 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.
Shared network services need workload, platform, security, and on-premises ownership boundaries
Shared network services need workload, platform, security, and on-premises ownership boundaries. 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.
The design must cover normal paths, failover, DNS behavior, telemetry, change control, and incident coordination
The design must cover normal paths, failover, DNS behavior, telemetry, change control, and incident coordination. 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
Design employee access to an internal application that calls a private managed service and an on-premises records 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
Showing boxes and connections without directions, trust, or required protocols. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Leaving DNS and route ownership implicit between teams. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
Declaring the topology highly available without walking through link, appliance, resolver, and region failures. It hides a boundary or enlarges the impact of failure, so record the safer alternative in the design.
If Someone Asks You
How would you explain and defend this internal application's connectivity design?
A clear answer is:
A network design is complete when every required path, prohibited path, failure mode, and owner is explicit.
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
A network design is complete when every required path, prohibited path, failure mode, and owner is explicit.
Questions to Check Your Understanding
What should appear in a communication matrix?
Which shared components require explicit owners?
How would you isolate a DNS failure from a route or policy failure?
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.