Private Connectivity on AWS: Peering, Transit Gateway, or PrivateLink?
AWS private connectivity becomes confusing when architects compare services by diagram shape instead of by the communication problem. VPC peering, AWS Transit Gateway, and AWS PrivateLink can all move traffic without exposing an application to the public internet, but they create very different routing relationships, security boundaries, failure domains, and operating models. The best choice is usually determined by what must communicate, not by which service seems most advanced.
That distinction matters in the design work represented by SAA-C03. A solutions architect has to recognize when two networks genuinely need layer-3 reachability, when many networks need a common transit hub, and when consumers only need private access to one service. Treating those three requirements as interchangeable is how small connectivity decisions become long-term architecture constraints.
A useful starting question is simple: are you connecting networks, centralizing routes, or publishing a service? Once that is clear, the trade-offs around CIDR overlap, route-table growth, inspection, DNS, cross-account ownership, and cost become much easier to reason about.
VPC peering is direct network-to-network connectivity
A VPC peering connection creates a one-to-one relationship between two VPCs. Routes in each VPC can send private IPv4 or IPv6 traffic directly to the other VPC, and the relationship works within a Region or across Regions. There is no customer-managed gateway in the data path, so peering is appealing when two networks need straightforward, low-complexity IP connectivity.
The important limitation is that peering is not transitive. If VPC A peers with VPC B and VPC B peers with VPC C, A does not gain a route to C through B. Every pair that must communicate needs its own relationship and route configuration. That is manageable for a small set of VPCs, but a mesh becomes increasingly difficult to reason about as accounts, environments, and application domains grow.
Peering also assumes the networks can coexist at the IP layer. Overlapping address ranges create a fundamental problem because routing cannot unambiguously identify the destination. This is one reason address planning remains an architectural decision rather than a networking afterthought. The broader design concerns are explored in the ANS-C01 path, where routing, hybrid connectivity, and multi-account network design become first-class topics.
Transit Gateway turns many point-to-point relationships into a hub
AWS Transit Gateway is a regional network transit hub. VPCs, VPNs, Direct Connect gateways, and other transit gateways can attach to it, allowing routing policy to be centralized instead of built as a large collection of peer-to-peer relationships. That changes the operating model: the architecture becomes hub-and-spoke, and transit gateway route tables become an explicit place to control which attachments can reach which destinations.
The value is not merely fewer connections. Transit Gateway supports transitive routing, so a shared-services VPC, inspection VPC, on-premises network, and multiple application VPCs can participate in a controlled routing design without every network being directly peered with every other network. Route-table association and propagation can also create segmentation, such as separating production, development, shared services, and partner connectivity while using one transit fabric.
At that scale, AWS Certified Advanced Networking – Specialty maps directly to the hard part of the design: keeping routing, hybrid connectivity, security controls, and operations predictable as accounts, Regions, and network attachments multiply.
PrivateLink publishes a service instead of merging routing domains
AWS PrivateLink addresses a different problem. A consumer VPC creates a private endpoint to a specific service or resource rather than gaining general IP reachability to the provider network. For endpoint services, the provider exposes a service behind supported load-balancing constructs and controls which principals may connect. Consumers see endpoint network interfaces inside their own VPC and use private addressing to reach the service.
That model is especially useful when the provider does not want consumers to discover or route to the rest of its VPC. It can also work when consumer and provider networks have overlapping CIDR ranges because the consumer is connecting to endpoint interfaces rather than importing the provider network into its routing domain. In security terms, this can be a smaller blast radius than giving two networks broad connectivity simply because one application needs one dependency.
PrivateLink therefore fits internal platform services, SaaS-style provider/consumer relationships, private access to supported AWS services, and cross-account service exposure. It is not a general replacement for peering or Transit Gateway. If two application environments need bidirectional network reachability across many protocols and destinations, a service endpoint model may become an awkward abstraction rather than a simplification.
The decision changes when the number of VPCs grows
Two VPCs with a stable relationship can make peering the simplest choice. Twenty or two hundred VPCs change the arithmetic. A full mesh produces more connection objects, more route-table entries, more cross-account coordination, and more opportunities for inconsistent policy. At that scale, a transit architecture can reduce relationship count and provide a clearer place for network segmentation and shared connectivity.
But centralization is not free. Transit Gateway introduces processing cost, an additional routing layer, and a control plane that requires operational discipline. A team that creates one giant transit domain without intentional route-table boundaries can accidentally make segmentation weaker, not stronger. Centralized architecture should reduce complexity by making policy explicit, not simply by moving the complexity into one service.
Large environments often use several connectivity models together. Transit Gateway can provide broad network reachability, while PrivateLink exposes tightly scoped shared services and peering remains appropriate for selected direct relationships. Those trade-offs are central to AWS Advanced Networking, where routing scope, segmentation, inspection, and operational ownership have to work as one design.
Security architecture depends on what the connection makes reachable
Private traffic is not automatically least-privileged traffic. Peering and Transit Gateway can expose large address ranges if route tables and security controls are broad. PrivateLink can narrow the reachable surface to a specific service, but endpoint policies, service permissions, security groups, and application authorization still determine what a caller can actually do. Network privacy and application authorization solve different problems.
Inspection requirements can also influence the design. A transit architecture can steer flows through centralized security appliances or inspection VPCs, but symmetrical routing must be preserved and the failure behavior of the inspection path must be understood. Peering is intentionally direct, so inserting centralized inspection into every relationship is not its natural strength. PrivateLink can avoid some east-west exposure by eliminating network-level reachability to the provider environment in the first place.
Organization-wide designs add another layer: SAP-C02 expects architects to reason about connectivity alongside account structure, security ownership, hybrid networking, resilience, and migration constraints rather than optimizing the network in isolation.
DNS and ownership often decide whether the design feels clean
Routing diagrams can look correct while users still reach the wrong endpoint because DNS has not been designed with the same care. Private hosted zones, endpoint private DNS, split-horizon naming, resolver rules, hybrid name resolution, and service discovery all affect whether a private path is actually usable. Architects should decide which team owns names, how records change during migration, and whether the same hostname should resolve differently from different networks.
Cross-account design adds a second ownership problem. One team may own the transit layer while another owns application VPCs; a platform team may publish a PrivateLink service while consumers own endpoints; peering may require acceptance and route changes on both sides. Clear ownership reduces the risk that a technically valid architecture becomes operationally fragile because nobody knows who changes a route, endpoint permission, or DNS record during an incident.
At the associate level, AWS Certified Solutions Architect – Associate provides the architectural baseline for making those choices from workload requirements. The goal is to understand services as parts of operating relationships, not as isolated configuration screens.
Choose the smallest connectivity scope that solves the real problem
A practical decision sequence is to start with the application relationship. If two VPCs need broad, direct IP connectivity and the topology is small, peering can be elegant. If many networks need controlled transitive routing, shared hybrid connectivity, or centralized inspection, Transit Gateway is usually the more scalable mental model. If consumers need private access to one service without joining the provider routing domain, PrivateLink is often the cleaner boundary.
Then test the choice against future conditions: Will CIDR ranges overlap? Will the number of accounts grow? Does traffic need inspection? Is bidirectional connectivity required? Will on-premises systems participate? Who owns routing? How will DNS work? What happens if the central transit layer is misconfigured? These questions reveal constraints that a simple feature comparison misses.
The best AWS network is not the one with the most centralized or newest service. It is the one whose connectivity scope matches the trust relationship. That principle keeps routing comprehensible, limits accidental reachability, and preserves room for the environment to grow without turning every new application into another networking exception.
Cost and failure domains should be visible in the network decision
Connectivity services change both traffic economics and failure behavior. Peering has no hourly connection charge, but cross-AZ and cross-Region data transfer can matter. Transit Gateway adds attachment and data-processing costs in exchange for centralized routing. PrivateLink charges for endpoints and data processing while reducing the reachable surface to specific services. Cost comparison should therefore use actual traffic paths rather than service-list pricing alone. A design that centralizes every packet through a transit layer may simplify routing but create avoidable processing and cross-AZ charges; a design that creates hundreds of interface endpoints may trade network exposure for a material recurring endpoint bill.
Failure scope is equally important. A broken route in one peering relationship is local to that relationship. A bad transit-gateway route-table change can affect many attached networks at once. A PrivateLink endpoint can fail from DNS, endpoint permissions, provider load balancer health, or service acceptance even while both VPCs remain healthy. The operational blast radius should influence change controls, monitoring, and how aggressively configuration is centralized.
Architects should test these paths with the same seriousness as application dependencies. Flow logs, reachability analysis, route inspection, health checks, DNS tests, and synthetic transactions can prove that the intended private path works and that unintended paths do not. The design is complete only when teams understand not just how traffic should flow, but also how a failed route, endpoint, attachment, or policy will be detected and isolated.