Architecture Patterns: The Grand Design

You know the building blocks—VPCs, VPNs, load balancers, firewalls. Now it is time to assemble them into production architectures. The PCNE exam does not just ask you to configure a single resource; it presents a business scenario and expects you to choose the correct architecture from a set of options. The patterns you choose determine whether your network is scalable, secure, and cost-effective—or a tangled web of workarounds that collapses at the first growth spurt.

This article covers the reference architectures that appear most frequently on the exam and in real-world enterprise environments.

The Hub and Spoke (Star Topology)

This is the enterprise standard for multi-team organizations.

Architecture
  1. Hub Project: Contains the Shared VPC, Interconnects, VPNs, and centralized firewall policies.
  2. Spoke Projects: Service projects attached to the Shared VPC. Each team gets their own project but shares the hub’s network.
Benefits
  1. Centralized administration. One place to manage firewall rules, routes, and hybrid connectivity.
  2. No transitivity problems. Because all spokes share the same VPC, they can communicate natively—no peering chains.
  3. IAM isolation. Each team manages their own project’s compute resources but cannot modify the network.
The Transitivity Problem (When Using Peering)

If you use VPC Peering instead of Shared VPC for the spokes, Spoke A cannot talk to Spoke C through the Hub—peering is non-transitive. The fix is to deploy a Network Virtual Appliance (NVA) in the Hub that acts as a router between spokes.

The Floating IP Pattern (Legacy HA)

Before Internal Load Balancers matured, enterprises used “Floating IPs” for database high availability.

  1. Active DB in Zone A has IP 10.0.0.100 (via an alias IP range).
  2. Passive DB in Zone B is on standby.
  3. On failover, a script removes the alias IP from the Active VM and adds it to the Passive VM.

This pattern is outdated. The modern replacement is an Internal TCP/UDP Load Balancer, which handles health checks and failover in milliseconds instead of script-based API calls that take seconds or minutes.

The Global Frontend, Regional Backend

This is the standard for globally distributed web applications.

  1. Frontend: Global External HTTP(S) Load Balancer with a single Anycast IP.
  2. Backend: Regional Managed Instance Groups in US, EU, and Asia.
  3. Database: Cloud Spanner (global) or Cloud SQL with cross-region read replicas.
  4. Magic: The LB automatically routes each user to the closest healthy backend. If the US backend fails, US traffic overflows to EU seamlessly.
The Secure Web Proxy Pattern

How do you control outbound web traffic from your VMs?

  1. Old Way: Route 0.0.0.0/0 through a self-managed Squid Proxy farm. You manage the VMs, the patches, and the scaling.
  2. New Way: Secure Web Proxy (managed service). You define URL lists (github.com allowed, facebook.com denied) and attach them to a policy. The proxy is serverless and auto-scaling.
The Multi-NIC Inspection Pattern

Sometimes a VM needs to sit at the boundary between two networks for traffic inspection.

  1. nic0: Connected to the Untrusted VPC (internet-facing).
  2. nic1: Connected to the Trusted VPC (backend applications).
  3. Constraint: Each NIC must belong to a different VPC. You cannot have two NICs in the same VPC.
  4. Routing: Use Policy-Based Routing to ensure traffic replies exit through the correct interface.

This is how you insert a third-party firewall (like Palo Alto or Fortinet) into the packet path without creating a single point of failure—by fronting the multi-NIC VMs with an Internal Load Balancer.

Putting it Together: A Pro-Engineer View

Imagine you are designing the network for a multinational bank. The Hub-and-Spoke model gives you centralized control. The Global Frontend pattern gives your customers low-latency access to the online banking portal from any country. The Multi-NIC Inspection pattern inserts your compliance firewall between the internet and your application tier. And the Secure Web Proxy controls what your internal VMs can access on the web. Four patterns, layered on top of each other, forming a single cohesive architecture. That is network engineering at scale.

Related Posts