The problem, at pattern level
At enterprise scale, a cloud footprint is not one application. A representative estate spans hundreds of projects across many owning teams. Some of those projects have to reach on-premises systems over private links, some must never touch the internet, and some produce services that other projects consume. Left alone, the default outcome is a mesh of peerings that nobody can draw and that fails in ways nobody predicted.
This reference design aims for the opposite: a topology that a new engineer can draw from memory, that a new workload can join without human negotiation, and that a security reviewer can reason about from the infrastructure code alone.
The shape
- Hubs, not peerings. Network Connectivity Center hubs, one per connectivity domain, with spokes attached by declaration. The illustrative topology uses six representative domains: enough to keep each domain legible without making the routing tables absurd. In a real estate the right number falls out of its own domain boundaries. A spoke is an infrastructure-as-code module call, not a conversation.
- Shared VPC as the tenancy boundary. Host projects own the network; service projects own the compute. Teams get subnets, not networks. The people who can change routing are a short list.
- Hybrid as a first-class path. Dedicated Interconnect and HA VPN attachments terminate on Cloud Routers in the hub domain. On-premises prefixes are advertised once over BGP and learned everywhere they should be, and nowhere they should not.
- Producers and consumers. Services that other projects need are published over Private Service Connect. Consumers get an endpoint in their own subnet; the producer's network is never exposed. This is what keeps the topology hub-and-spoke instead of letting it decay into a mesh.
- Egress by policy. Internet egress goes through a controlled path with inspection. A workload that needs a new destination adds it to an allow-list in code, with a reviewer, with a diff.
What makes it hold
Three things, none of them clever.
- Infrastructure-as-code modules with opinions. The spoke module does one thing and refuses to do anything else. Its inputs are the questions a network engineer would ask; its outputs are the facts a security reviewer would want. Drift shows up in plan output, not in an incident.
- A living topology model. Every hub, spoke, attachment, route advertisement and firewall rule is exported on a schedule into a graph that can be queried and drawn. Exposure paths are questions against the model, not archaeology. Architecture diagrams are generated from the same model, so they are never stale.
- Runbooks written before go-live. For every nameable failure mode (an attachment down, a route leak, a hub saturating), a runbook that a person who did not design the system could execute at three in the morning.
What I would say at a conference
Connectivity is a governance problem wearing a networking costume. The routing is the easy part. The hard part is designing the system so that the correct thing is also the path of least resistance for the team that just wants to ship, and so that the incorrect thing is visible in a plan before it is real.