VPC advanced — Transit Gateway, PrivateLink and Network Firewall

A single-VPC architecture scales to two or three microservices before peering meshes become unmanageable. N VPCs require N×(N−1)/2 peering connections, each with independent route-table entries on both sides. The moment an organisation grows to dozens of AWS accounts — the standard outcome of an AWS Organizations landing zone — this mesh collapses under its own operational weight.

Transit Gateway, launched in 2018, replaces the peering mesh with a managed hub-and-spoke fabric where every VPC attaches once. PrivateLink lets services in one VPC be consumed from another without peering, NAT, or public IP addresses, granting service-level access rather than network-level access to the entire connected CIDR. Together these two primitives form the connectivity and access layers of every serious multi-account AWS landing zone.

Network Firewall completes the architecture by inserting centralised stateful packet inspection at the boundary between trusted and untrusted segments. Understanding how all three interact is the prerequisite for every advanced network design pattern in this module, including the multi-region active-active architecture you will design in the practice exercise at the end of Module 1.

Analogy🏏Cricket

🏏 Think of it like cricket: In Test cricket, the ICC publishes playing conditions — governing over rates, DRS quotas, pitch inspection protocols, and player conduct — that both captains sign before the first session, whether the match is at Lord’s, the MCG, or Eden Gardens. Just as the playing conditions give umpires a single authoritative standard so every ruling references the same document rather than personal judgement, the Well-Architected Framework gives architects a shared evaluation language so every workload is measured against the same six pillars rather than each engineer’s intuition. Just as a team posting a slow over rate incurs penalties regardless of their score, a workload with Security or Reliability gaps carries structural risk regardless of how quickly it shipped. Just as every specialist role — opener, keeper, tail — has defined performance expectations against which selectors evaluate each player, every workload component is evaluated against pillar-specific best-practice questions. This reveals why the framework must precede any advanced architectural decision: a shared, evidence-based standard transforms subjective trade-offs into structured, auditable risk assessments that hold across teams, accounts, and regions.