Scenario: a global SaaS platform's hub-and-spoke backbone

Speaker notes

• The scenario: a SaaS company runs dozens of microservice-owning teams, each with their own VPC, plus a shared-services VPC (logging, secrets, CI/CD runners), plus a requirement to let enterprise customers privately connect their own VPCs to one specific ingestion API without any broader network access.
• The architecture layers exactly the three tools from earlier in this deck by role: Transit Gateway is the backbone connecting every internal team VPC and the shared-services VPC, letting any team reach shared infrastructure without pairwise peering; VPC Lattice sits on top of that backbone for service-to-service calls between teams' own microservices, giving them IAM-based request authorization without each team hand-rolling their own auth; PrivateLink, and only PrivateLink, fronts the customer-facing ingestion API, since that's the one case genuinely requiring the tightest, one-directional isolation from an external account.
• The lesson this scenario is meant to reinforce: a real enterprise architecture almost never picks one connectivity tool for everything, it picks the right tool per relationship (internal backbone, internal service mesh, external exposure), exactly the layered decision framework from the PrivateLink-vs-Lattice-vs-Transit-Gateway slide, now applied to an actual multi-team organization instead of an abstract comparison.

Deck map