Domain 1 of 4 · Chapter 1 of 5

Cross-account and hybrid network connectivity

The connectivity decision space: topology, transitivity, and CIDR

At professional scale the network question is never "can these two VPCs talk". It is "how do I connect dozens of accounts and an on-premises estate without the topology, the routing, or the address plan collapsing." Four properties decide which primitive wins, and a stem usually telegraphs which one binds: transitivity (a peering mesh is non-transitive, a Transit Gateway is not), scale ceiling (peering hits 125 per VPC long before a TGW strains), CIDR overlap tolerance (only PrivateLink survives overlapping address space), and directionality (PrivateLink is one-way, the routed fabrics are not). Get these four straight and most SAP-C02 networking scenarios resolve to one answer.

Transitivity is the dividing line

VPC peering[2] is strictly 1:1 and non-transitive: if VPC A peers B and A peers C, B still cannot reach C through A. You must add a direct B↔C peering. The figure below contrasts that non-transitive triangle with the transitive hub. Peering also forbids edge-to-edge routing: across a peering connection you cannot use the peer VPC's internet gateway, NAT device, Site-to-Site VPN, Direct Connect, or gateway endpoint (documented restriction[2]). Those two facts are why a peering mesh grows as O(n²) and why it cannot host centralized egress or shared on-premises connectivity. AWS Transit Gateway (TGW)[1] is a regional Layer-3 hub that is transitive: each VPC, VPN, Direct Connect gateway, or peer attaches once, and routing between attachments is governed by TGW route tables rather than a pairwise mesh.

Scale ceilings you design around

The third primitive in the table, AWS Cloud WAN[5], a managed multi-Region network driven by one declarative core network policy (fully defined under Transit Gateway and Cloud WAN below), scales by policy rather than by a per-resource quota:

Primitive Hard ceiling that bites first
VPC peering 50 active peerings per VPC default, hard max 125[4]
Transit Gateway 5,000 attachments, 20 route tables, 10,000 routes per TGW[3]
Cloud WAN one core-network-edge per Region, scaled by a single core network policy[5]

Because each new VPC in a mesh adds a peering to every existing VPC, the pairwise count hits the 125 ceiling well before a single TGW (5,000 attachments) would feel any strain. The exam telegraphs this with phrases like "50 VPCs needing full connectivity" or "the team can no longer manage the peering connections."

CIDR overlap is a hard wall for routed connectivity

Both peering and Transit Gateway are routing fabrics, so neither can carry overlapping address space. A transit gateway "doesn't support routing between VPCs with identical CIDRs, or if a CIDR in a range overlaps a CIDR in an attached VPC"[13]. The overlapping VPC's routes simply are not propagated. The only clean escape when re-IP is impossible is AWS PrivateLink[11], which exposes a single service endpoint rather than routing whole networks and therefore tolerates overlapping consumer/provider CIDRs[11]. This makes PrivateLink the right tool for two unrelated, possibly-overlapping, mutually-distrusting networks that need to share exactly one service.

Directionality

Peering, Transit Gateway, and Cloud WAN are bidirectional routed fabrics. Either side can initiate any flow the route tables and security groups allow. PrivateLink is unidirectional consumer-to-provider: the consumer reaches the provider's service through an interface endpoint (an ENI with a private IP), but the provider cannot initiate back into the consumer VPC. When a scenario says both sides must originate connections, PrivateLink is wrong and you need peering or TGW. The four-way matrix (transitive? scale? overlap-tolerant? one-way?) is the lens for the rest of this guide.

VPC peering: non-transitive Transit Gateway: transitive no path via A VPC A VPC B VPC C peers peers VPC TGW hub VPC VPC attach once, all reach each other
Transitivity is the dividing line: a peering triangle leaves B and C with no path through A, while every VPC on a TGW hub reaches every other.

Transit Gateway and Cloud WAN: route tables, peering, scale

Having settled on a hub in the previous section, this one covers the mechanics of the two hub fabrics: how a Transit Gateway isolates traffic with route tables, how much it carries, when it needs appliance mode, and when one Region's TGW gives way to a multi-Region Cloud WAN.

Segmentation lives in route tables, not attachments

A Transit Gateway implements isolation through route tables, not per-attachment ACLs. Each attachment associates with exactly one TGW route table (which determines where its traffic can go) and can propagate its routes into one or more route tables (which determines who can reach it). To build a classic three-tier segmentation, say Prod, Non-Prod, and a Shared-Services/Inspection domain, you give each its own TGW route table and control association/propagation so Prod and Non-Prod cannot route to each other but both can reach Shared Services. Defaults to design within: 5,000 attachments, 20 route tables, and 10,000 total routes per TGW[3].

Bandwidth and packet ceilings

A TGW VPC attachment delivers up to 100 Gbps each direction per Availability Zone and up to 7,500,000 packets/sec per AZ (quotas[3]), so you scale aggregate throughput by spreading the attachment across more AZs, each adding capacity. A TGW Connect peer (GRE tunnel) is capped at 5 Gbps, and a Connect attachment can hold up to 4 peers for up to 20 Gbps via ECMP[3]. That is the path for an SD-WAN / third-party router integration.

Appliance mode keeps stateful flows symmetric

When a Shared-Services VPC hosts a stateful inspection appliance (a firewall, or AWS Network Firewall / Gateway Load Balancer), asymmetric routing across AZs would break the connection-tracking state. Enabling appliance mode on that VPC attachment makes the TGW "use the same Availability Zone for that VPC attachment for the lifetime of the flow of traffic between a source and destination"[13], and it works even for flows whose source and destination are in different Regions. Appliance mode is only supported on VPC attachments (same doc[13]). A recurring distractor enables it "on the VPN attachment," which is invalid.

Sharing and multi-Region

A Transit Gateway is shared to other accounts in the organization with AWS Resource Access Manager (RAM)[14]; those accounts then create their own VPC attachments to the central hub, the mechanism behind a centralized-egress / shared-services hub in a landing zone. TGWs in different Regions connect via inter-Region TGW peering, but each Region's route tables must be built and kept in sync by hand. That manual multi-Region toil is exactly what AWS Cloud WAN[5] removes.

Cloud WAN: one declarative policy, VRF-like segments

Cloud WAN is driven by a single core network policy document that declares Regions, segments, and how attachments map to segments (including tag-based mapping). AWS provisions a core network edge (a TGW-like router) per Region and full-meshes them automatically[5]. A segment is an isolated routing domain analogous to a globally consistent VRF, define "prod" and "dev" segments once and they enforce the same isolation in every Region without per-Region route-table surgery. Migration is incremental: an existing Transit Gateway can be peered into a Cloud WAN segment[5] rather than forklift-replaced. Decision rule: one Region, many VPCs → Transit Gateway; many Regions under central policy → Cloud WAN. Cloud WAN's value is centralized global policy, so for a single Region a lone TGW is cheaper and sufficient.

Prod VPC attachment associates to Prod route table Non-Prod VPC attachment associates to Non-Prod route table Prod route table Non-Prod route table Shared-Services route table Prod + Non-Prod propagate here Shared-Services VPC associate associate propagate propagate
TGW segmentation: Prod and Non-Prod attachments each use their own route table (so they can't reach each other) but both propagate into the Shared-Services table, so both reach Shared Services.

Hybrid edge: Direct Connect, VPN resilience, and DNS

Hybrid scenarios pair a private path to on-premises with name resolution that works across the boundary; this section covers picking the right Direct Connect interface, making that path encrypted and resilient with VPN, and bridging DNS with Route 53 Resolver.

Direct Connect VIFs and the DX gateway

Direct Connect (DX) is a private fiber link into an AWS Region with three virtual-interface types[6]: a private VIF reaches a VPC (or, via a Direct Connect gateway, virtual private gateways across accounts and Regions); a public VIF reaches public AWS service endpoints by public IP; a transit VIF reaches Transit Gateways through a DX gateway. Pick the transit VIF when DX must feed a TGW hub rather than a single VPC. Dedicated ports are 1, 10, 100, and 400 Gbps; partner hosted connections range 50 Mbps to 25 Gbps[7].

DX is not encrypted, and a single circuit is a single failure domain

DX provides no encryption by itself. MACsec Layer-2 encryption is supported only on 10, 100, and 400 Gbps dedicated connections (and LAGs of them), not on 1 Gbps dedicated or on hosted connections[8]; for a small or non-MACsec link, run an IPsec Site-to-Site VPN over the connection to encrypt in transit. Because one DX circuit is a single failure domain, a resilient hybrid design backs DX with a Site-to-Site VPN (or a second DX at another location). SiteLink[6] routes on-prem-site to on-prem-site directly over the AWS backbone via DX, bypassing a Region. Supported on transit VIFs and on private VIFs attached to a DX gateway, not on public VIFs.

VPN bandwidth, ECMP, and acceleration

Each Site-to-Site VPN connection has two tunnels. Standard tunnels are up to 1.25 Gbps each; Large Bandwidth Tunnels reach up to 5 Gbps each but are available only on VPN connections attached to a Transit Gateway or Cloud WAN, not a virtual private gateway (tunnel options[10]). To exceed a single tunnel you use ECMP across multiple connections: AWS gives the example of "two VPN connections with Large Bandwidth Tunnels and using ECMP across all four tunnels" to reach 20 Gbps[10]. ECMP rides on dynamic routing: a VPN to a transit gateway supports both dynamic (BGP) and static routes[15], but equal-cost multipath requires BGP, so a static-route VPN cannot ECMP. Separately, an accelerated VPN routes over the AWS edge via Global Accelerator and is likewise "only supported for Site-to-Site VPN connections that are attached to a transit gateway; virtual private gateways do not support accelerated VPN connections"[16] and cannot be used with a DX public VIF[16]. Note LBT and accelerated VPN are mutually exclusive: accelerated VPN is not supported on Large Bandwidth Tunnels[10].

Hybrid DNS with Route 53 Resolver

Routing packets is half the hybrid problem; name resolution is the other half. Route 53 Resolver[12] bridges it with two endpoint directions: an inbound endpoint lets on-premises resolvers query private hosted zones in the VPC, and an outbound endpoint with forwarding rules sends VPC DNS queries to on-premises corporate DNS over Direct Connect or VPN. Each endpoint requires "a minimum of two IP addresses for redundancy"[17], placed across at least two Availability Zones, and each AZ/subnet/IP combination becomes an elastic network interface. An outbound forwarding rule names one domain and the target on-prem resolver IPs; the Resolver picks a target IP at random and retries another if it does not respond[18]. Full bidirectional hybrid resolution needs both endpoint directions; resolver rules can be centralized and shared across accounts via AWS RAM[14].

Direct Connect private fiber into a Region private VIF public VIF transit VIF VPC public AWS service endpoints, by public IP Transit Gateways via DX gateway
Direct Connect VIF types: a private VIF reaches a VPC, a public VIF reaches public AWS service endpoints, and a transit VIF reaches Transit Gateways via a DX gateway.

SAP-C02 exam-pattern recognition: stems, answers, traps

Networking scenarios on SAP-C02 are long and detail-dense; the trick is mapping the stem's keywords to the four-property lens (transitive? scale? CIDR overlap? one-way?) and rejecting distractors that violate a documented constraint.

Pattern 1: "dozens of VPCs / accounts, full connectivity, peering unmanageable"

Keywords: 50 VPCs, full mesh, too many peering connections, one Region. Correct: Transit Gateway shared via AWS RAM[14], with per-environment route tables for segmentation. Distractors: expanding the peering mesh (hits the 125-per-VPC ceiling and is non-transitive)[4]; Cloud WAN when everything is in one Region (over-engineered, more cost).

Pattern 2: "single global network across many Regions, central policy"

Keywords: multiple Regions, consistent segmentation, central network team, one dashboard. Correct: Cloud WAN with a core network policy and segments[5]. Distractor: hand-built inter-Region TGW peering, technically works but requires per-Region route-table sync the question is explicitly trying to avoid.

Pattern 3: "share one service across overlapping / untrusted CIDRs"

Keywords: overlapping CIDR blocks, expose a single API/service, third-party consumers, no full network routing. Correct: PrivateLink interface endpoint + endpoint service behind an NLB; it exposes one service one-way and tolerates overlapping CIDRs[11]. Distractors: TGW or VPC peering, both of which cannot route overlapping address space[13]; NAT/re-IP when the question forbids changing addressing.

Pattern 4: "private, predictable bandwidth to on-prem, must stay resilient/encrypted"

Keywords: consistent throughput, no internet path, must survive a circuit failure, encrypt in transit. Correct: Direct Connect via a transit VIF + DX gateway to a TGW, backed by a Site-to-Site VPN. If the link is 1 Gbps or hosted, you cannot use MACsec; run an IPsec VPN over DX instead[8]. For >5 Gbps over VPN, ECMP across Large Bandwidth Tunnels on TGW-attached connections[10]. Distractor: "enable MACsec on the 1 Gbps connection" (unsupported); "accelerated VPN on a virtual private gateway" (only TGW-attached VPNs support acceleration[16]).

Pattern 5: "on-prem can't resolve AWS private names" (or vice versa)

Keywords: private hosted zone, on-premises servers can't resolve, forward corporate domain queries. Correct: Route 53 Resolver: inbound endpoint for on-prem→VPC resolution, outbound endpoint + forwarding rules for VPC→on-prem (resolver[12]). Trap: swapping inbound and outbound, or assuming a TGW VPC attachment resolves names; a TGW does not provide DNS resolution for attached VPCs' private hosted zones[13].

Pattern 6: "centralized egress / inspection for all spoke VPCs"

Keywords: single egress, traffic inspection, stateful firewall, hub-and-spoke. Correct: Transit Gateway with a central inspection/egress VPC, the inspection attachment in appliance mode so stateful flows stay pinned to one AZ for the flow lifetime[13], and route tables steering spoke traffic through the inspection VPC. Distractor: relying on VPC peering for shared egress, peering forbids edge-to-edge routing through a peer's NAT/IGW/VPN[2], so it cannot host centralized egress.

Pattern 7: "a few VPCs, keep it cheap and simple"

Keywords: two or three VPCs, minimize cost, no central hub needed. Correct: VPC peering: no hourly hub charge, simplest for a tiny topology. Distractor: a Transit Gateway, which adds per-attachment plus data-processing fees[3] that a three-VPC topology does not justify. The exam rewards matching the primitive to the scale, not always reaching for the biggest hub.

Choosing an inter-VPC / hybrid connectivity model

Decision axisVPC peeringTransit GatewayCloud WANPrivateLink
Topology1:1 mesh (non-transitive)Hub-and-spoke, regionalManaged global multi-RegionService exposure (NLB endpoint)
Transitive routingNoYesYes (segments + peering)N/A (single service)
Scale ceiling125 peerings per VPC5,000 attachments / TGWMany Regions via core policyPer-endpoint, no full routing
Segmentation modelPer-pair onlyTGW route tablesPolicy-defined segments (VRF-like)Per-service, no broad routing
Works with overlapping CIDRs?NoNoNoYes
DirectionBidirectionalBidirectionalBidirectionalConsumer to provider (one-way)
Cost shapeNo hub fee; data transferPer-attachment + data processingPer-attachment/edge + dataPer-hour + per-GB (gateway type free)
Best forA few VPCsMany VPCs/accounts, 1 RegionGlobal enterprise WANSharing one service privately

Decision tree

One global network across many Regions? Yes AWS Cloud WAN central policy + segments (VRF-like) No Many VPCs/accounts, one Region? Yes Transit Gateway (hub) share via RAM; route tables = segments No Expose one service, or CIDRs overlap? Yes AWS PrivateLink NLB-backed interface endpoint, one-way No Private, predictable bandwidth to on-prem? Yes Direct Connect + VPN backup private/transit VIF via DX gateway; ECMP VPN No VPC peering a few VPCs; no hub fee; non-transitive Always for hybrid name resolution: Route 53 Resolver endpoints inbound = on-prem queries VPC zones; outbound + rules = VPC queries forwarded to corporate DNS
Cheat sheet

Sharp facts the exam loves — give these one last read before exam day.

Cheat sheet

Sharp facts the exam loves — scan these before test day.

Transit Gateway replaces the O(n^2) peering mesh

Transit Gateway (TGW) is a regional Layer 3 hub-and-spoke router: each VPC, VPN, or Direct Connect gateway attaches once, and the hub routes between them, collapsing a full peering mesh into one attachment per VPC. It's the default answer for connecting dozens of VPCs and accounts plus on-premises in a single Region; reach for it instead of peering once the pairwise-mesh count becomes unmanageable. Per-Region scope is the catch: inter-Region reach needs TGW-to-TGW peering or Cloud WAN.

Trap Assuming a single Transit Gateway routes between VPCs in different Regions on its own, when a TGW is regional and inter-Region reach needs TGW peering or Cloud WAN.

1 question tests this
TGW segmentation is per-route-table, not per-attachment

Transit Gateway isolation lives in its route tables: give each environment its own TGW route table, then control which attachments associate to it and which propagate routes into it, analogous to VRFs. Default quotas bound the design: 20 route tables per TGW, 10,000 total routes across all of them, and 5,000 attachments per TGW.

Trap Assuming an attachment can sit in two route tables for selective isolation: each attachment associates to exactly one TGW route table; segmentation comes from propagation, not multi-association.

8 questions test this
TGW bandwidth is up to 100 Gbps per VPC attachment per AZ

A Transit Gateway VPC attachment delivers up to 100 Gbps each direction per Availability Zone (and up to 7,500,000 packets/sec per AZ), so spreading an attachment's subnets across more AZs is how you scale aggregate throughput. A single TGW Connect (GRE) peer is capped at up to 5 Gbps; a Connect attachment holds up to 4 peers for up to 20 Gbps total, scaled with ECMP across the peers.

Trap Concentrating an attachment's subnets in one AZ and expecting more bandwidth, when the 100 Gbps cap is per-AZ so scaling throughput means spreading subnets across additional AZs.

TGW supports inter-Region peering and multicast

Transit Gateways peer to other TGWs across Regions (and to a Cloud WAN core network edge) to form a multi-Region network, and TGW natively supports multicast, neither of which VPC peering offers. The cost: inter-Region TGW peering attachments are static-routing only and must be hand-built with route tables synchronized per Region, which is exactly the toil Cloud WAN automates.

Trap Expecting dynamic BGP route propagation across an inter-Region TGW peering attachment, when those attachments are static-routing only and need per-Region route tables synchronized by hand.

8 questions test this
Share a TGW across accounts with AWS RAM

A Transit Gateway is shared to other accounts with AWS Resource Access Manager (RAM); the receiving account then creates its own VPC attachment to the central hub. This is the mechanism behind centralized-egress and shared-services hubs in a multi-account landing zone: one team owns the TGW, every spoke account attaches into it.

5 questions test this
Cloud WAN = one declarative core network policy

AWS Cloud WAN builds a managed global network from a single core network policy document: a declarative JSON that defines Regions, segments, and how attachments map to segments; AWS then provisions a core network edge (a TGW-like router) per Region and full-meshes them automatically. Choose it over self-managed multi-Region TGW peering when you want central policy, tag-based attachment-to-segment mapping, and one dashboard instead of synchronizing route tables by hand.

Cloud WAN segments are VRF-like isolated routing domains

A Cloud WAN segment is a dedicated routing domain (AWS likens it to a globally consistent VRF or L3 IP VPN): by default only attachments in the same segment communicate, and AWS keeps that isolation consistent across every Region without you hand-synchronizing per-Region TGW route tables. You can peer an existing Transit Gateway into a Cloud WAN segment for incremental migration rather than a forklift cutover.

Trap Assuming attachments in different Cloud WAN segments can talk by default, when segments are isolated and cross-segment routing requires an explicit sharing action in the core network policy.

Direct Connect has three virtual interface types

Direct Connect carries traffic over a VIF, and the type picks the destination: a private VIF reaches a VPC by private IP (or, via a Direct Connect gateway, virtual private gateways across accounts and Regions); a public VIF reaches all AWS public service endpoints by public IP; a transit VIF reaches Transit Gateways through a DX gateway. Pick the transit VIF when DX must feed a TGW hub rather than a single VPC.

Trap Using a public VIF to reach a private VPC subnet: a public VIF only advertises AWS public-service prefixes; private-IP VPC access needs a private or transit VIF.

Direct Connect is not encrypted by itself

Direct Connect is a private dedicated link but provides no encryption on its own. MACsec (Layer 2 encryption) is available only on 10, 100, and 400 Gbps dedicated connections, not on 1 Gbps dedicated and not on hosted connections; for a sub-MACsec or hosted link, run an IPsec Site-to-Site VPN over a DX public VIF to encrypt traffic in transit.

Trap Treating a Direct Connect circuit as encrypted because it's private: privacy is path isolation, not confidentiality; an eavesdropper on the link sees cleartext without MACsec or an overlay VPN.

Pair Direct Connect with a backup VPN for resilience

A single DX circuit is one failure domain, so a resilient hybrid design backs DX with a Site-to-Site VPN (accelerated or ECMP) or a second DX at a different location. ECMP, which aggregates multiple tunnels for bandwidth and failover, requires the VPN to use dynamic (BGP) routing; it is not supported on static-route VPNs.

Trap Expecting ECMP aggregation across VPN tunnels with static routing, when ECMP needs dynamic BGP routing and is unsupported on static-route VPNs.

DX dedicated ports vs hosted connection speeds

Direct Connect dedicated ports come in 1, 10, 100, and 400 Gbps; partner-provided hosted connections range from 50 Mbps to 25 Gbps. Reach for a hosted connection when you need a sub-1 Gbps committed link, since the smallest dedicated port is 1 Gbps and won't go lower.

Trap Ordering a dedicated port for a sub-1 Gbps link, when the smallest dedicated port is 1 Gbps and only a partner hosted connection goes below that.

Direct Connect SiteLink connects two DX points of presence directly over the AWS global backbone so site-to-site traffic takes the shortest path without hairpinning through an AWS Region. It's supported on transit VIFs and on private VIFs attached to a Direct Connect gateway, but not on a private VIF attached directly to a virtual private gateway, nor on public VIFs; a separate per-hour and data fee applies, and it isn't offered in GovCloud (US) or China Regions.

Trap Expecting SiteLink to work on a private VIF attached directly to a virtual private gateway, when it requires a Direct Connect gateway (or a transit VIF) and is unsupported on a VGW-attached private VIF or a public VIF.

AWS PrivateLink publishes a single service through an interface VPC endpoint (an ENI with a private IP in the consumer's subnet) backed by a VPC endpoint service that the provider fronts with a Network Load Balancer. Connectivity is unidirectional consumer-to-provider (the consumer initiates); when both sides must initiate full IP connectivity, use VPC peering or a Transit Gateway instead.

Trap Reaching for PrivateLink when the provider also needs to initiate connections back to the consumer: the endpoint is one-way, so bidirectional flows need peering or a TGW.

2 questions test this

PrivateLink exposes only a service endpoint, not whole networks, so the consumer and provider VPCs may have overlapping or identical CIDR blocks, exactly the case where TGW and VPC peering both refuse to route. It's the standard way to share a service privately when address-space overlap is unavoidable and re-IPing isn't an option.

Trap Reaching for Transit Gateway or VPC peering to connect VPCs with overlapping CIDRs, when both refuse to route overlapping address space and PrivateLink is the way to share a single service across the overlap.

1 question tests this
Gateway endpoints (S3/DynamoDB) are free; interface endpoints are billed

Gateway VPC endpoints exist only for Amazon S3 and DynamoDB and add no charge: they're prefix-list route-table entries with no ENI. Every other service uses an interface endpoint (PrivateLink), billed per hour per AZ plus per GB processed. Use a gateway endpoint to reach S3/DynamoDB privately without routing the traffic through a NAT gateway and paying NAT data-processing fees.

Trap Putting an interface endpoint in front of S3 purely to save money: S3 and DynamoDB have a free gateway endpoint, so a billed interface endpoint is only warranted when you specifically need private-IP/on-prem reachability the gateway endpoint can't give.

1 question tests this
Route 53 Resolver endpoints bridge hybrid DNS

Route 53 Resolver endpoints connect VPC and on-premises DNS in two directions: inbound endpoints let on-premises resolvers query records in the VPC (private hosted zones), while outbound endpoints, paired with forwarding (resolver) rules, send matching VPC DNS queries out to on-premises corporate DNS. Full bidirectional name resolution across the hybrid boundary needs both endpoint types.

Trap Assuming an inbound endpoint lets the VPC resolve on-prem names: direction matters: inbound serves queries coming INTO the VPC; resolving on-prem names FROM the VPC needs an outbound endpoint plus a forwarding rule.

5 questions test this
Overlapping CIDRs break TGW and peering: plan address space up front

Transit Gateway and VPC peering cannot route between VPCs whose CIDR blocks match or overlap, so non-overlapping addressing has to be planned before you scale out accounts. When overlap is already unavoidable, expose the workload via PrivateLink or front it with NAT rather than re-IPing live VPCs.

Trap Planning to fix overlapping VPC CIDRs later with Transit Gateway routing, when neither TGW nor peering routes overlapping address space and the workaround is PrivateLink or NAT, not the hub itself.

1 question tests this
VPC peering is non-transitive

VPC peering is a strictly one-to-one, non-transitive relationship: if A peers B and A peers C, B still can't reach C through A. You must add a direct B-to-C peering, and the per-pair route entries that go with it. That non-transitivity is the core reason a Transit Gateway hub scales better once you pass a handful of VPCs.

Trap Treating a peered hub VPC as a transit point so spokes reach each other through it: peering never forwards transitively; each spoke pair needs its own connection (or a TGW).

7 questions test this
VPC peering active quota is 50 per VPC (max 125)

The default quota is 50 active VPC peering connections per VPC, adjustable up to a hard maximum of 125. Because each new VPC must peer with every existing one, the pairwise count grows quadratically and hits this ceiling well before a TGW hub would, another trigger to move to Transit Gateway.

VPC peering blocks edge-to-edge routing

A VPC peering connection won't let you use the peer VPC's internet gateway, NAT device, Site-to-Site VPN, Direct Connect, or gateway endpoint: edge-to-edge routing through a peer is unsupported. Centralized egress or shared on-prem connectivity therefore requires a Transit Gateway (or Cloud WAN), not peering.

Trap Centralizing internet egress through one peered VPC's NAT gateway: peers can't reach a neighbor's NAT, IGW, VPN, or DX, so shared egress needs a TGW/Cloud WAN hub.

2 questions test this
Small topologies: peering beats a TGW on cost

For just two or three VPCs, VPC peering is simpler and carries no hourly hub charge, whereas a Transit Gateway adds a per-attachment hourly fee plus per-GB data-processing charges. Reserve the TGW hub for many-VPC or hybrid topologies where its operational simplicity outweighs the per-attachment cost.

Trap Standing up a Transit Gateway hub for two VPCs that only need to talk to each other: you pay attachment plus data-processing fees for routing peering would do free.

Appliance mode keeps inspection traffic symmetric

Centralized inspection through Transit Gateway (Network Firewall, Gateway Load Balancer, or third-party appliances in an inspection VPC) requires enabling appliance mode on the inspection VPC attachment. Appliance mode makes the TGW pick one network interface and Availability Zone via a flow hash and pin both forward and return traffic to that same AZ for the life of the flow (including flows whose source and destination are in different Regions) preventing the asymmetric routing that otherwise drops cross-AZ stateful connections. It's supported only on VPC attachments.

Trap Expecting symmetric return paths through a stateful inspection VPC without appliance mode: the TGW will otherwise hash forward and return flows to different AZs and the appliance drops the asymmetric half.

8 questions test this
Set HOME_NET to spoke CIDRs for centralized Network Firewall

Network Firewall's stateful (Suricata) rules only evaluate traffic whose source falls inside the HOME_NET rule variable, which defaults to the CIDR of the VPC where the firewall endpoints are deployed. In a centralized inspection VPC behind Transit Gateway, spoke-VPC and on-premises traffic is silently ignored until you expand HOME_NET to include those CIDR ranges.

Trap Leaving HOME_NET at its default in a centralized inspection VPC: stateful rules then skip every spoke's traffic because its source falls outside the inspection VPC's own CIDR.

6 questions test this
RAM trusted access plus auto-accept removes invitation steps

Before a Transit Gateway can be shared to your organization or specific OUs, you must enable sharing with AWS Organizations (RAM trusted access) from the management account; in-organization shares then grant access with no invitation to accept. The receiving account's VPC attachment still needs approval, though, unless 'Auto accept shared attachments' is enabled on the Transit Gateway itself.

Trap Assuming an in-organization RAM share auto-approves the spoke's VPC attachment, when the attachment still needs acceptance unless 'Auto accept shared attachments' is enabled on the TGW.

8 questions test this

Also tested in

References

  1. Transit gateways in AWS Transit Gateway
  2. VPC peering basics
  3. Transit gateway quotas
  4. VPC peering connection quotas
  5. What is AWS Cloud WAN?
  6. AWS Direct Connect virtual interfaces
  7. AWS Direct Connect dedicated connections
  8. MACsec on AWS Direct Connect
  9. AWS Direct Connect FAQs FAQ
  10. Tunnel options for your AWS Site-to-Site VPN connection
  11. AWS PrivateLink concepts
  12. What is Route 53 VPC Resolver?
  13. Amazon VPC attachments in AWS Transit Gateway
  14. Shareable AWS resources
  15. AWS Site-to-Site VPN attachments in AWS Transit Gateway
  16. Accelerated AWS Site-to-Site VPN connections
  17. Values that you specify when you create or edit inbound endpoints
  18. Forwarding outbound DNS queries to your network