Hybrid Networking & Connectivity
Transit Gateway, VPC Endpoints, Site-to-Site VPN, and Direct Connect: how AWS networks talk to each other, and to the world outside AWS
Introduction
Be honest with yourself about how often you will reach for the services in this lesson: for most teams building cloud-native applications, the answer is "rarely, if ever". The Networking & VPC lesson covered everything a typical workload needs: subnets, route tables, an internet gateway, and a NAT gateway for outbound traffic. That is plenty when your entire system lives inside AWS.
That changes the moment your system stops living entirely inside AWS, that is, the moment you are working in a hybrid environment: an organization with an on-premises datacenter, branch offices, or a colocation facility that must connect securely, privately, or at guaranteed bandwidth to AWS networks and services. Think of a bank migrating workloads gradually while keeping its core ledger on-prem, a hospital network that legally cannot route patient data over the public internet, or a company with multiple AWS accounts and VPCs that all need to reach a handful of shared services without a tangle of point-to-point links.
This lesson is a tour of the connectivity layer: how VPCs connect to each other at scale (VPC Peering and Transit Gateway), how workloads reach AWS services without ever touching the public internet (VPC Endpoints and AWS PrivateLink), and how on-premises networks bridge into AWS over the internet (Site-to-Site VPN) or over a dedicated private line (AWS Direct Connect). You may not deploy any of these next week, but recognizing them on a diagram, and knowing which problem each one solves, is exactly the kind of knowledge that separates "I can build an app on AWS" from "I can read and reason about a real company's AWS architecture."
1. Connecting VPCs: Peering vs. Transit Gateway
The simplest way to let two VPCs talk to each other is a VPC peering connection: a one-to-one link that routes traffic between them over AWS's private backbone, never the public internet. There is no hourly charge for the connection itself, but data transfer is not free: traffic between VPCs in different Availability Zones costs $0.01/GB per side, and cross-region peering is higher. Peering supports VPCs in different accounts and regions, and requires nothing more than a route table entry on each side pointing at the peering connection.
The Catch: No Transitive Routing
If VPC A peers with VPC B, and VPC B peers with VPC C, traffic from A still cannot reach C through B. Each peering connection is its own isolated pipe. Connect five VPCs to each other this way and you need ten separate peering connections, a full mesh that becomes painful to create, document, and secure as the number of VPCs grows. This "peering mesh" problem is precisely what pushed AWS to build a hub-and-spoke alternative.
AWS Transit Gateway (TGW) is a regional network transit hub: every VPC, VPN connection, and Direct Connect link attaches to it once, and the gateway routes traffic between all of them. Connect five VPCs to a Transit Gateway and you need five attachments, not ten peering connections, and adding a sixth VPC means exactly one more attachment.
- Transitive routing - unlike peering, traffic can flow VPC A → Transit Gateway → VPC C even if A and C have no direct relationship, as long as the Transit Gateway's route tables allow it.
- Attachments - VPCs, VPN connections, Direct Connect gateways, and even peering connections to other Transit Gateways (for multi-region designs) all attach the same way and show up in the same route tables.
- Transit Gateway route tables - separate from VPC route tables, these decide which attachments can reach which, letting you isolate, say, a "production" route domain from a "shared services" or "sandbox" one on the same gateway.
Why Transit Gateway Replaces the Peering Mesh
Figure 1: Four VPCs connected by peering need a full mesh of six point-to-point connections, and a fifth VPC would push that to ten. The same four VPCs attached to one Transit Gateway need only four attachments, and a fifth VPC adds exactly one more, with transitive routing between every spoke included for free.
A Pattern You May Still See: Transit VPC
Before Transit Gateway existed, teams built the same hub-and-spoke shape themselves with a Transit VPC: a central VPC running third-party router software on EC2 instances, with every other VPC and VPN connection terminating there. It worked, but it meant patching, scaling, and paying for EC2 instances just to move packets around. Transit Gateway is a fully managed replacement for this exact pattern, if you encounter "Transit VPC" in an older architecture diagram or runbook, you are looking at the thing Transit Gateway was built to retire.
2. Private Access to AWS Services: VPC Endpoints & PrivateLink
By default, a Lambda function or EC2 instance in a private subnet reaches S3, DynamoDB, or any other AWS service through a NAT gateway and the public internet, even though the traffic never technically leaves AWS's network. VPC endpoints remove the public internet from that path entirely, keeping traffic to AWS services on AWS's private network the whole way. There are two kinds:
Gateway Endpoints
A route table entry that points traffic for S3 or DynamoDB directly at the service instead of a NAT gateway. They cost nothing extra to use and add no additional infrastructure, the simplest, cheapest way to keep this traffic private.
Interface Endpoints
An elastic network interface (ENI) with a private IP, placed directly in your subnets, that fronts almost any other AWS service: Secrets Manager, SQS, CloudWatch Logs, Bedrock, and dozens more. They are billed hourly plus per-GB processed, and they are powered by the technology covered next.
AWS PrivateLink is the underlying technology that makes interface endpoints possible: it connects an ENI in your VPC to a service running in another VPC, another account, or AWS itself, again without traversing the public internet or requiring peering, route tables, or firewall rules on either side. The relationship is simple to remember: every interface endpoint is powered by PrivateLink, but PrivateLink is bigger than just AWS-managed services.
Two Roads Off the Private Subnet
Figure 1: A Gateway Endpoint is just a route-table entry that redirects S3/DynamoDB traffic away from the NAT gateway, free of charge. An Interface Endpoint places a billed ENI in your subnet and uses AWS PrivateLink to privately reach almost any other AWS service, or, through a VPC Endpoint Service, a service published by another team, account, or partner.
Exposing Your Own Services: VPC Endpoint Services
You can run PrivateLink in the other direction, too. Put your own service behind a Network Load Balancer, register it as a VPC Endpoint Service, and other teams, other accounts, or even SaaS customers can reach it through an interface endpoint in their own VPC. Neither side ever exposes the service to the internet or peers their networks together, this is the standard pattern behind many "AWS Marketplace" and B2B SaaS integrations.
3. Site-to-Site VPN & VPN CloudHub
AWS Site-to-Site VPN connects an on-premises network to a VPC over the public internet using encrypted IPsec tunnels. On the on-premises side sits a Customer Gateway (a physical device or software appliance you manage); on the AWS side, the connection terminates at either a Virtual Private Gateway (VGW) attached to a single VPC, or, increasingly, directly at a Transit Gateway so the same VPN connection can reach every VPC attached to the hub. Every Site-to-Site VPN connection provisions two tunnels to different AWS endpoints by design, so a single tunnel failure or maintenance event does not take the link down.
AWS VPN CloudHub reuses that same VGW to create a hub-and-spoke network over VPN: connect multiple branch offices, each with its own Customer Gateway and Site-to-Site VPN connection, to one VGW, and CloudHub lets them route traffic to each other through AWS, not just to the VPC. It is a low-cost way to link several remote sites without provisioning any dedicated network hardware between them, the VPN equivalent of the Transit VPC pattern from Section 1, minus the EC2 routers.
VPN CloudHub: Branch Offices Sharing One Gateway
Figure 1: Each branch office terminates its own redundant IPsec tunnel pair at the same Virtual Private Gateway. VPN CloudHub then advertises routes between the branches themselves, so Branch A and Branch B can reach each other through AWS, not just reach the VPC, all without a dedicated link between the offices.
Not the Same Job: AWS Client VPN
Site-to-Site VPN and VPN CloudHub connect networks to AWS. AWS Client VPN solves a different problem: it lets individual remote users (think: engineers working from home) connect their laptops to a VPC over an OpenVPN-based client, the cloud equivalent of a traditional corporate remote-access VPN. Same underlying idea, encrypted tunnels into AWS, but a different audience and a different service.
4. AWS Direct Connect & Direct Connect Gateway
Site-to-Site VPN is encrypted, but it still rides on the public internet, with all the latency variability and bandwidth unpredictability that implies. AWS Direct Connect (DX) replaces that path with a dedicated private network connection from your datacenter, office, or colocation facility straight into AWS, provisioned through a Direct Connect Partner. The result is consistent, low latency, predictable bandwidth (from 50 Mbps up to 100 Gbps), and often meaningfully cheaper data transfer rates than the equivalent traffic over the internet, the connection is private, but unlike Site-to-Site VPN, it is not encrypted by default (teams that need encryption in transit can layer an IPsec VPN or MACsec on top of it).
A Direct Connect connection does not talk to a VPC directly, it carries one or more virtual interfaces (VIFs), each suited to a different destination:
- Private VIF - connects to a single VPC through a Virtual Private Gateway, or to a Direct Connect Gateway (which can then fan out to VGWs in multiple regions and accounts), for reaching private resources like EC2 instances and RDS.
- Public VIF - reaches AWS public service endpoints (S3, DynamoDB, and others) using their public IP ranges, over your private connection instead of the internet.
- Transit VIF - connects to a Transit Gateway through a Direct Connect Gateway, the modern way to reach many VPCs over one physical connection.
That last point is worth unpacking: a single Direct Connect connection terminates at one specific AWS location, but most organizations have VPCs spread across regions and accounts. Direct Connect Gateway (DXGW) is the piece that bridges that gap, it is a globally available resource that lets one Direct Connect connection (via a transit VIF) reach Transit Gateways, and through them VPCs, in multiple regions and accounts, without provisioning a separate physical connection for each one.
Direct Connect Gateway: One Connection, Many Regions
Figure 1: A Direct Connect connection terminates at one physical location, but a transit virtual interface into a Direct Connect Gateway lets that single link reach Transit Gateways, and the VPCs behind them, across multiple regions and accounts. A private VIF skips the gateway entirely for simpler single-VPC, single-region designs.
The Resiliency Rule of Thumb
A single Direct Connect link is still a single point of failure: a fiber cut or a partner outage takes your private connectivity with it. AWS's standard guidance for production workloads is to provision at least two connections, terminating at two different Direct Connect locations, and to keep a Site-to-Site VPN connection as a lower-bandwidth, higher-latency fallback that can absorb traffic if Direct Connect itself goes down.
5. Choosing the Right Connectivity Option
Every option in this lesson trades off setup effort, cost, and performance differently. Lined up side by side, they form a spectrum of increasing commitment, each one reaching further than the last:
The Connectivity Spectrum: From Simple to Dedicated
Figure 1: Each step to the right trades a bit more setup effort and cost for a bit more scale, reach, or performance guarantee, moving from a free point-to-point link, to a managed hub for many VPCs, to an encrypted bridge to on-premises networks, to a dedicated private line with predictable bandwidth.
| Option | Connects | Path | Typical Use Case |
|---|---|---|---|
| VPC Peering | VPC ↔ VPC (1:1) | AWS private backbone | A handful of VPCs that need direct, simple connectivity |
| Transit Gateway | Many VPCs, VPNs, DX (hub) | AWS private backbone | Growing networks where a peering mesh would not scale |
| VPC Endpoints / PrivateLink | VPC ↔ AWS service or another VPC's service | AWS private network, no internet hop | Reaching S3, Secrets Manager, or a partner's service privately |
| Site-to-Site VPN | On-prem ↔ VPC / Transit Gateway | Encrypted IPsec over the public internet | Fast, low-cost hybrid connectivity, or a DX backup link |
| Direct Connect (+ DXGW) | On-prem ↔ many VPCs / regions | Dedicated private line via a partner | Production hybrid workloads needing predictable bandwidth and latency |
One more name worth recognizing as you read newer architecture diagrams: AWS Cloud WAN. It sits a layer above Transit Gateway and Direct Connect, letting you design, manage, and monitor a global network spanning multiple AWS regions and on-premises locations from a single dashboard, using a declarative network policy instead of wiring up each region's transit hub by hand. Think of it as the emerging answer to "now that I have five Transit Gateways in five regions, how do I manage them as one network?"
6. Reference Architecture: A Hybrid Network
Putting it together: an on-premises datacenter reaches AWS over two paths, a Direct Connect connection (through a Direct Connect Gateway) as the primary, high-bandwidth route, and a Site-to-Site VPN as an encrypted fallback. Both paths attach to a central Transit Gateway, which fans traffic out to every VPC that needs it. Inside each VPC, a VPC Endpoint keeps calls to AWS services like S3 on the private network, the same private-by-default principle that motivated Direct Connect and VPN in the first place, just applied one hop closer to the workload.
Hybrid Connectivity Reference Architecture
Figure 1: Direct Connect (through a Direct Connect Gateway) is the primary path into the Transit Gateway hub, with Site-to-Site VPN standing by as an encrypted backup. The hub fans out to every attached VPC, and a VPC Endpoint keeps the final hop to an AWS service like S3 off the public internet entirely.
What actually happens when the primary Direct Connect path fails is the kind of detail that separates a diagram from an operational understanding of one:
Failover from Direct Connect to Site-to-Site VPN
Figure 2: BGP route priorities make Direct Connect the preferred path under normal conditions. When its session drops, on-premises routers automatically shift traffic onto the Site-to-Site VPN tunnels, the Transit Gateway keeps routing to the same VPCs, and the application never needs to know which path its packets took.
Two small CDK snippets show how the building blocks come together. First, a Transit Gateway with VPC attachments and a route between them:
# Hub-and-spoke: one Transit Gateway, two VPC attachments
tgw = ec2.CfnTransitGateway(self, "CoreTransitGateway",
description="Hub for VPC, VPN and Direct Connect attachments",
default_route_table_association="enable",
default_route_table_propagation="enable",
)
prod_attachment = ec2.CfnTransitGatewayAttachment(self, "ProdVpcAttachment",
transit_gateway_id=tgw.ref,
vpc_id=prod_vpc.vpc_id,
subnet_ids=[s.subnet_id for s in prod_vpc.private_subnets],
)
shared_attachment = ec2.CfnTransitGatewayAttachment(self, "SharedServicesVpcAttachment",
transit_gateway_id=tgw.ref,
vpc_id=shared_vpc.vpc_id,
subnet_ids=[s.subnet_id for s in shared_vpc.private_subnets],
)
# Route table entries that let the spokes reach each other through the hub
ec2.CfnRoute(self, "ProdToSharedRoute",
route_table_id=prod_private_route_table.ref,
destination_cidr_block=shared_vpc.vpc_cidr_block,
transit_gateway_id=tgw.ref,
)Then, the two flavors of VPC endpoint living side by side in the same VPC:
# Gateway endpoint: free, route-table based, S3 and DynamoDB only
vpc.add_gateway_endpoint("S3Endpoint",
service=ec2.GatewayVpcEndpointAwsService.S3,
subnets=[ec2.SubnetSelection(subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS)],
)
# Interface endpoint: ENI-based, billed hourly + per GB, powered by PrivateLink
vpc.add_interface_endpoint("SecretsManagerEndpoint",
service=ec2.InterfaceVpcEndpointAwsService.SECRETS_MANAGER,
subnets=ec2.SubnetSelection(subnet_type=ec2.SubnetType.PRIVATE_WITH_EGRESS),
private_dns_enabled=True, # rewrites the public DNS name to resolve to the ENI
)Key Takeaways
- VPC Peering does not scale past a handful of VPCs - its lack of transitive routing forces a full mesh; Transit Gateway replaces that mesh with a managed hub-and-spoke that supports transitive routing across VPCs, VPNs, and Direct Connect, the same shape teams used to hand-build with EC2 routers in a Transit VPC.
- VPC Endpoints keep AWS service traffic off the internet - free Gateway Endpoints cover S3 and DynamoDB; Interface Endpoints, powered by AWS PrivateLink, cover almost everything else, and PrivateLink also lets you expose your own services to other VPCs and accounts privately.
- Site-to-Site VPN connects networks over the internet with IPsec encryption - terminating at a Virtual Private Gateway or Transit Gateway, with VPN CloudHub turning one VGW into a low-cost hub for several branch offices; Client VPN solves the related but distinct problem of individual remote-user access.
- AWS Direct Connect trades setup effort for predictable performance - a dedicated private line (not encrypted by default) carrying private, public, or transit virtual interfaces, with Direct Connect Gateway letting one connection reach VPCs across regions and accounts via Transit Gateway.
- Production hybrid links need redundancy - two Direct Connect connections at different locations, often paired with a Site-to-Site VPN as an automatic, lower-bandwidth fallback, and increasingly managed end to end with AWS Cloud WAN.