At the Professional level, network design stops being about a single VPC and becomes about how dozens or hundreds of VPCs, on-premises data centers, and partner networks connect, route, and stay observable together -- Task 1.1 of the SAP-C02 blueprint tests exactly this scaling problem.
Connecting Many VPCs
VPC peering connects two VPCs directly with a low-latency, non-transitive link -- "non-transitive" is the key exam word: if VPC A peers with VPC B, and B peers with C, A cannot reach C through B. Peering works fine for a handful of VPCs but becomes an unmanageable full mesh past a dozen or so. AWS Transit Gateway solves this at scale: it acts as a regional hub that VPCs, VPN connections, and Direct Connect gateways attach to, turning what would be an O(n²) mesh of peering connections into O(n) attachments. Transit Gateway supports route tables per attachment, so a hub-and-spoke design can still segment traffic (for example, isolating a shared-services VPC from a production VPC while both reach a shared Direct Connect attachment). PrivateLink (VPC endpoint services) is a third connectivity pattern, but it's fundamentally different -- it exposes a specific service one-way, from a provider VPC to consumer VPCs, over AWS's internal network without any route table entries or peering at all, which is why it is the answer whenever a scenario needs to publish an internal service to many consumers without exposing the whole network.
Hybrid and On-Premises Integration
For connecting to on-premises data centers, Site-to-Site VPN gives an encrypted IPsec tunnel over the public internet -- fast to stand up but variable in latency and throughput. AWS Direct Connect provides a dedicated, private physical connection through a Direct Connect location, offering consistent low latency and higher throughput; a Direct Connect Gateway lets one Direct Connect connection reach multiple VPCs across regions. A common resilient pattern layers a Direct Connect connection as primary with a Site-to-Site VPN as failover -- both terminating on a Transit Gateway so route propagation handles the failover automatically via BGP.
Hybrid DNS
Amazon Route 53 Resolver is the piece that makes hybrid DNS work: Resolver endpoints (inbound and outbound) let on-premises resolvers forward queries for AWS-hosted domains into a VPC, and let VPC resources forward queries for on-premises domains out to on-premises DNS servers. This is the standard answer whenever a scenario describes an organization needing EC2 instances to resolve an on-premises Active Directory domain, or on-premises servers needing to resolve private Route 53 hosted zone records.
Segmentation, Regions, and Troubleshooting
Network segmentation decisions -- subnet sizing, IP address planning across a multi-VPC estate, and avoiding CIDR overlap before it forces re-IP work later -- matter more at this level because a poorly planned IP scheme blocks future peering or Transit Gateway attachments entirely. Region and Availability Zone selection should be driven by measured latency and data residency needs, not convenience. For troubleshooting live traffic flows, VPC Flow Logs capture accepted/rejected traffic at the ENI, subnet, or VPC level, and Reachability Analyzer traces the actual path (including security group and NACL evaluation) between a source and destination to pinpoint exactly where traffic is being dropped.
Key Mechanics
- VPC peering is non-transitive and point-to-point; Transit Gateway is a hub that scales attachments linearly and supports per-attachment route tables for segmentation.
- PrivateLink exposes one service to many consumer VPCs one-way, without peering or route table changes -- distinct from both peering and Transit Gateway.
- Direct Connect gives dedicated, consistent low-latency bandwidth; Site-to-Site VPN is faster to provision but rides the public internet -- combine them on a Transit Gateway for automatic BGP failover.
- Route 53 Resolver inbound/outbound endpoints are the standard mechanism for two-way hybrid DNS resolution between AWS and on-premises.
- VPC Flow Logs show what happened to traffic; Reachability Analyzer shows why, by tracing the actual path through security groups and NACLs.
Exam Tip: If a scenario has dozens of VPCs needing to talk to each other and to on-premises, and the question emphasizes simplifying management as connections grow, the answer is almost always Transit Gateway over a full mesh of VPC peering connections.
Exam Tip: Watch for "publish a service to hundreds of consumer accounts without them being able to see anything else in your VPC" -- that phrasing points to PrivateLink, not Transit Gateway or peering.
Exam Tip: "On-premises servers must resolve private AWS hosted zone records" or the reverse ("EC2 instances must resolve an on-premises domain") both point to Route 53 Resolver endpoints, not standard Route 53 public hosted zones.
Worked example: A company has 40 production VPCs across 3 regions, a shared-services VPC hosting a directory service, and an on-premises data center reachable via Direct Connect. New VPCs are added monthly, and the network team wants any new VPC to reach shared services and on-premises without manual peering work each time. The design attaches every VPC to a regional Transit Gateway with route tables that route shared-services and on-premises traffic through a central hub attachment, peers the three regional Transit Gateways for inter-region reach, and layers a Site-to-Site VPN as failover behind the primary Direct Connect connection -- eliminating the peering-mesh problem entirely while keeping the topology addable in one step per new VPC.