Transit Gateway, VPC Connectivity, and PrivateLink

Evaluating inter-VPC connectivity at professional scale

SAP-C02 Task 1.1 asks you to choose a network connectivity strategy, not to pick a service by popularity. In a two-VPC lab, Amazon VPC peering looks sufficient. In a multi-account organization with shared services, traffic inspection, hybrid circuits, and an acquisition that reused 10.0.0.0/16, that same peering mesh becomes an operations and routing failure. Start every design from three questions: Do workloads need transitive routing (spoke-to-spoke or on-premises-to-many-VPCs)? Do CIDR blocks overlap? Are you connecting entire networks or only specific services?

VPC peering when it is still the right tool

Peering is a point-to-point relationship. Two VPCs with non-overlapping CIDR blocks can route to each other as if they were adjacent. Security groups can reference peer security groups in supported configurations, and there is no Transit Gateway attachment-hour or data-processing charge on the peering path. Peering is not transitive: if VPC A peers with B and B peers with C, A cannot reach C through B. That single property eliminates peering as the campus backbone. Peering also gives you no choke point for centralized inspection. Keep it for a small number of VPCs that need full Layer 3 adjacency, or for a tightly coupled pair such as a production VPC and a dedicated analytics VPC that will never need on-premises hairpinning through the peer. Inter-Region peering exists and is still non-transitive. You cannot peer VPCs whose CIDR blocks overlap, and you cannot use peering to attach on-premises networks.

A full mesh of N VPCs needs N(N−1)/2 peering connections. At 35 application VPCs that is already hundreds of relationships, each with route entries in every subnet route table. SAP-C02 scenarios that mention “dozens of accounts” or “shared services plus isolation” are telling you that mesh peering has already lost.

Transit Gateway as the Regional hub

AWS Transit Gateway is a Regional Layer 3 virtual router. You create attachments for VPCs, AWS Site-to-Site VPN, AWS Direct Connect gateways, Transit Gateway Connect (for SD-WAN appliances), peering to another transit gateway, and, where used, Client VPN or VPN Concentrator constructs. AWS Network Firewall can also attach as a network function attachment, which AWS documents as a way to avoid a customer-managed inspection VPC for that firewall; those attachments use static routing, enable appliance mode automatically, and do not support third-party appliances.

Packets arriving on one attachment are forwarded to another attachment based on the destination IP address and the transit gateway route table associated with the source attachment. Each attachment associates with exactly one route table. A route table may be associated with many attachments. An attachment can propagate its prefixes into one or more tables. The naive pattern—every attachment associated with and propagating to the same default table—makes the gateway a simple router: every VPC can reach every other VPC and on-premises. The professional pattern uses multiple route tables as routing domains. Production spokes associate with a production table that contains other production CIDRs, shared services, and hybrid prefixes, but omits or blackholes development CIDRs. Development gets a separate table. Shared services and inspection VPCs get tables that decide who may enter hub services. A blackhole route drops matching traffic inside the gateway, which is how you enforce “prod must not talk to dev” even if someone adds a VPC route toward the hub.

AWS documents that a transit gateway is highly available by design. You do not deploy a second gateway in the same Region merely for failover. A second gateway is a blast-radius or environment split (isolated sandbox) or the far side of inter-Region peering. Peering attachments do not speak BGP; you install static routes whose target is the peering attachment. Equal-cost multipath (ECMP) is available for VPN (when enabled), Connect, and Direct Connect gateway attachments when prefixes and BGP attributes match. ECMP is not available between different attachment types, transit gateway peering does not ECMP, and you cannot attach two VPCs with the same CIDR and load-balance them. Route evaluation uses the longest prefix first; for equal prefixes, static routes beat propagated routes, and among propagated types AWS publishes a priority order in which Direct Connect gateway routes beat Site-to-Site VPN. That last fact is the backup-VPN design you will reuse in the hybrid section: advertise the same prefixes on both paths and the gateway prefers Direct Connect until that path is withdrawn.

Appliance mode on a VPC attachment pins a flow to one Availability Zone for the lifetime of the flow and lets the gateway send that flow to any AZ in the inspection VPC that has a subnet association. Enable it on the attachment that hosts stateful firewalls or IDS appliances. Without it, return traffic can hash to a different AZ than the forward path, and the middlebox drops the session. This is a classic SAP-C02 trap in inspection-VPC questions.

Current Transit Gateway design guidance: dedicate a small subnet (commonly a /28) in each AZ for the attachment elastic network interface; keep the network ACL on those subnets open; apply restrictive NACLs on workload subnets if you need them; associate the same VPC route table with all attachment subnets unless you are building a middlebox VPC that must steer through different NAT gateways. Enable every AZ that actually hosts resources. Instances in an AZ without an attachment cannot originate to the gateway; the gateway may internally shift some traffic toward an AZ that does have an attachment, which is availability behavior, not permission to skip AZ coverage. Use BGP-based VPNs and enable propagation for Direct Connect gateway and BGP VPN attachments. When migrating from peering, watch MTU: the gateway supports 8500 bytes for VPC, Direct Connect, Connect, and peering attachments, while VPN is 1500 bytes. Mixed jumbo paths drop packets.

RAM-shared subnets versus routed hubs

VPC sharing with AWS Resource Access Manager (RAM) is not another WAN overlay. The VPC owner—usually a network account—shares subnets with participant accounts. Participants launch elastic network interfaces (Amazon EC2, Amazon ECS tasks in awsvpc mode, Amazon EKS pods using the VPC CNI) into those subnets. Everyone shares the owner’s CIDR, route tables, and network ACLs. Sharing is the right tool when a central team must own IP allocation, default routes, and inspection insertion, and application teams should not create their own VPCs. It is the wrong tool when accounts need independent CIDR spaces, independent route tables, or isolation that a shared NACL cannot express. Shared subnets do not connect two owner VPCs; you still need peering, a transit gateway, or PrivateLink between those VPCs. RAM is also how you share a transit gateway itself into member accounts so each account can create its own VPC attachment without copying the hub.

PrivateLink versus routed connectivity

AWS PrivateLink connects a consumer VPC to a specific service as if that service lived locally. The provider places a Network Load Balancer in front of the application and creates an endpoint service. Consumers create interface VPC endpoints. Traffic never requires a route between the two VPC CIDRs, so overlapping CIDRs are acceptable. You do not get ICMP to every host, file-share protocols to a subnet, or transitive access to on-premises through the consumer VPC. PrivateLink is the professional answer for SaaS-style APIs, cross-organization integrations, and acquisitions that cannot re-IP in the exam’s planning window. It is a weak answer when the stem requires full subnet reachability, east-west campus routing, or a single hybrid path that must see every RFC1918 prefix.

Cloud WAN when the problem is global policy

AWS Cloud WAN is a policy-driven global network. You define Regions, segments (isolated routing domains), and attachment mappings in a core network policy. AWS places a core network edge in each listed Region and meshes those edges over the AWS global network. Choose Cloud WAN when you would otherwise maintain a full mesh of inter-Region transit gateway peering plus duplicated static routes for the same segmentation intent. You can peer a core network edge to an existing transit gateway in the same Region and extend segments onto transit gateway route tables. Cloud WAN does not repeal IP uniqueness: overlapping CIDRs still collide inside a routed segment.

Container networking does not invent a fifth WAN. Amazon ECS and Amazon EKS in awsvpc mode place ENIs in VPC subnets. Those ENIs obey the same route tables, security groups, and transit gateway AZ rules as EC2. EKS prefix delegation increases IP consumption per node, which is an Amazon VPC IP Address Manager (IPAM) problem, not a reason to skip a hub. If two clusters inherited overlapping Pod or VPC CIDRs from a datacenter template, you cannot attach both VPCs to one transit gateway until you re-address, or you expose only Kubernetes Services through PrivateLink or an ingress controller.

Connectivity decision table

Scenario: multi-account hub-and-spoke plus an overlapping acquisition

A payments platform runs 35 spoke VPCs in us-east-1, a shared-services VPC (directory, artifact storage), and a requirement that production and development must not route to each other. On-premises must reach production and shared services but not development. That is a shared Transit Gateway with at least three route tables, RAM sharing of the gateway into member accounts, and a Direct Connect gateway on a transit virtual interface. When an acquired VPC still uses 10.0.0.0/16 that collides with production, do not attach it to the same transit gateway. Expose the payment API with PrivateLink; schedule a later re-IP only if the acquired estate truly needs full campus routing. If the organization also has five other Regions with the same segmentation story, evaluate Cloud WAN segments rather than a handmade mesh of peering attachments and static defaults.