What's changed: In-scope coverage: added service mesh/discovery/device VPN (App Mesh/Cloud Map/Client VPN)
1.3Multi-VPC and Multi-Account Connectivity Design
Understand how to connect multiple networks—choosing among VPC peering, Transit Gateway, and PrivateLink. Scale and intent drive the choice.
As VPCs multiply, how to connect them becomes central. Use peering for a few, Transit Gateway for many-to-hub, and PrivateLink to expose a single service.
1.3.1Choosing a connectivity model
- VPC peering: 1:1, non-transitive. Connect a few VPCs cheaply. Not possible with overlapping CIDRs.
- Transit Gateway: a hub for many VPCs and on-prem. Transitive, scales to hundreds, centralizes routing.
- PrivateLink (VPC endpoint service): expose only a specific service to consumer VPCs without joining whole networks.
- Choosing: full mesh/many → TGW; pairwise → peering; service exposure → PrivateLink.
Common on ANS-C01: peering is non-transitive (A-B and B-C do not give A-C), hub for many VPCs + on-prem = Transit Gateway, and exposing a single service = PrivateLink. Remember peering is non-transitive and cannot use overlapping CIDRs.
Transit Gateway uses route tables to control reachability between attachments, enabling segmentation (e.g., isolating prod from dev).
ANS-C01 connectivity design probes choosing the optimal model by scale, transitivity, CIDR overlap, and service exposure. VPC peering directly joins two VPCs 1:1, is non-transitive (A-B and B-C do not give A-C), works inter-region (inter-region peering), cannot use overlapping CIDRs, and becomes a hard-to-manage full mesh at scale. Transit Gateway (TGW) is a hub bundling many VPCs/VPNs/Direct Connect, with transitive routing, TGW route tables controlling reachability between attachments (prod/dev segmentation, aggregating to shared services), inter-region via TGW peering, scaling to hundreds–thousands of VPCs. PrivateLink (VPC endpoint service) exposes a provider NLB as an endpoint service, with consumers connecting via an interface endpoint (ENI)—exposing only a single service one-way without joining whole networks, so it works even with overlapping CIDRs and suits SaaS provision or strict exposure control. Selection: a few pairs = peering, many/with-on-prem hub = TGW, per-service exposure = PrivateLink. Costs differ: peering (free within an AZ, data transfer only), TGW (attachment-hours + data processing), PrivateLink (endpoint-hours + data processing). The key is to precisely use "non-transitive = peering," "transitive hub = TGW," and "single-service exposure, CIDR-independent = PrivateLink."
| Model | Traits | Best for |
|---|---|---|
| VPC peering | 1:1, non-transitive, no overlap | A few pairs; low cost |
| Transit Gateway | Hub, transitive, route-table segmentation | Many VPCs + on-prem; large scale |
| PrivateLink | Single-service exposure; CIDR-independent | SaaS provision; strict exposure control |
Scenario: (1) Let many business VPCs and on-prem use a shared-services VPC, with prod and dev network-isolated. (2) Separately, provide only your API to a partner VPC with overlapping CIDRs. → For (1), use Transit Gateway as the hub and separate prod/dev attachments into different domains via TGW route tables for segmentation (both reach shared services). For (2), use PrivateLink (expose an NLB as an endpoint service) to provide just the API one-way regardless of CIDR overlap. Avoid full-mesh peering, which becomes unmanageable.
FAQ: How to connect to a peer with overlapping CIDRs? Peering and Transit Gateway cannot be used with overlapping CIDRs (routing isn’t deterministic). To provide/consume a single service despite overlap, PrivateLink is the answer (CIDR-independent, one-way endpoint connection). For full interconnection, re-CIDR one VPC or work around overlap with private NAT.
Exam trap: "Chaining VPC peering lets many VPCs intercommunicate" is wrong—peering is non-transitive; A-B and B-C do not give A-C. For many-VPC mesh/hub connectivity, Transit Gateway (transitive) is correct. Also, trying to peer/TGW an overlapping-CIDR peer is wrong—work around it by exposing only a single service via PrivateLink.
1.3.2In-scope services for service mesh, discovery, and client connectivity
Network design also covers application-layer communication control and connectivity. AWS App Mesh is an Envoy-based service mesh giving inter-microservice communication observability (metrics/traces), retries, and traffic splitting without changing app code (note: AWS App Mesh reaches end of support on September 30, 2026, with no new onboarding since September 2024; the successor is Amazon ECS Service Connect). AWS Cloud Map is managed service discovery that registers resources under custom names so apps discover services by name while tracking IP/port changes (with health-check integration). For remote connectivity, use Site-to-Site VPN site-to-site and AWS Client VPN from individual employee devices. Client VPN is a managed TLS-based VPN from devices, authorizing connections via certificate auth or Active Directory integration.
1.3.3Section summary
- Few = peering / many-hub = Transit Gateway / single service = PrivateLink
- Peering is non-transitive and cannot overlap CIDRs
- Mesh = App Mesh / discovery = Cloud Map / device VPN = Client VPN
Sign in to track progress — Log in.
Quick check
(just a quick review)Q1. Interconnect 50 VPCs plus on-prem and centralize routing. Best choice?
Q2. VPC-A peers with VPC-B, and VPC-B peers with VPC-C. Can VPC-A reach VPC-C?
Q3. Expose your API to another account’s VPC without joining whole networks. What?