VPC Connectivity
This page covers how to connect VPCs to each other and connect VPCs to on-premises networks — VPC peering, Transit Gateway, Site-to-Site VPN, and Direct Connect. For VPC basics (subnets, route tables, security groups, load balancers), see Networking.
Overview
Section titled “Overview”| Option | Connects | Use Case |
|---|---|---|
| VPC Peering | VPC ↔ VPC (same or cross-account/region) | 2–3 VPCs, simple |
| Transit Gateway | Many VPCs + VPN + Direct Connect via one hub | 5+ VPCs, hybrid, transitive routing |
| Site-to-Site VPN | VPC ↔ on-premises over the internet | Encrypted tunnel over public internet |
| Direct Connect | VPC ↔ on-premises over private link | Dedicated, predictable bandwidth |
VPC Peering
Section titled “VPC Peering”A direct connection between two VPCs. Traffic stays on the AWS backbone — it never crosses the public internet.
VPC-A (10.0.0.0/16) ◄──── peering connection ────► VPC-B (10.1.0.0/16)Key Properties
Section titled “Key Properties”| Property | Detail |
|---|---|
| Transitivity | None. A↔B and B↔C does not give A↔C. You need A↔C separately. |
| CIDR | Peered VPCs must have non-overlapping CIDR ranges. |
| Accounts/regions | Same account, same region; same account, different region (inter-region peering); or different accounts (requires acceptance). |
| Cost | Data transfer charges for traffic between VPCs (no hourly fee for the peering connection itself). |
When to Use
Section titled “When to Use”- You have 2–3 VPCs that need to talk.
- You don’t need transitive routing.
- You want the simplest setup with no hub.
Setup (Same Account, Same Region)
Section titled “Setup (Same Account, Same Region)”# Create peering connectionaws ec2 create-vpc-peering-connection \ --vpc-id vpc-aaaa \ --peer-vpc-id vpc-bbbb
# Accept (if same account, auto-accepted; cross-account: accept in peer account)aws ec2 accept-vpc-peering-connection --vpc-peering-connection-id pcx-xxxx
# In each VPC, add route: destination = peer VPC CIDR, target = pcx-xxxxaws ec2 create-route \ --route-table-id rtb-xxxx \ --destination-cidr-block 10.1.0.0/16 \ --vpc-peering-connection-id pcx-xxxxTransit Gateway
Section titled “Transit Gateway”Transit Gateway is a regional hub that connects many VPCs and on-premises networks (VPN, Direct Connect). One hub replaces a mesh of peering connections and gives transitive routing.
VPC-A ──►┐VPC-B ──►├──► Transit Gateway ──► Site-to-Site VPN ──► On-premisesVPC-C ──►┘ │ └──► Direct Connect Gateway ──► On-premisesWhy Use Transit Gateway?
Section titled “Why Use Transit Gateway?”| Need | Why TGW |
|---|---|
| Many VPCs | One attachment per VPC; no N² peering. |
| Transitive routing | VPC A → TGW → VPC B without a direct peering. |
| Hybrid | Same hub for VPCs, VPN, and Direct Connect. |
| Cross-account | Share TGW via RAM (Resource Access Manager). |
Attachments
Section titled “Attachments”You attach resources to the Transit Gateway:
| Attachment Type | What It Connects |
|---|---|
| VPC attachment | One VPC. You choose one subnet per AZ. |
| VPN attachment | A Site-to-Site VPN connection (to on-prem). |
| Direct Connect Gateway | A DX Gateway (private VIF from on-prem). |
| Transit Gateway peering | Another Transit Gateway in a different region. |
Each attachment is associated with a Transit Gateway route table.
Transit Gateway Route Tables
Section titled “Transit Gateway Route Tables”The Transit Gateway has its own route tables. They control how traffic is forwarded between attachments.
- Default: One default TGW route table; all attachments can use it.
- Segmentation: Create multiple TGW route tables (e.g. dev vs prod) and associate attachments to different tables so that not all VPCs can reach each other.
VPC side: In each VPC’s route table, add a route whose target is the TGW attachment (e.g. 10.1.0.0/16 → tgw-attach-xxxx).
TGW side: The TGW route table gets routes to the CIDRs of attached VPCs (and to VPN/DX destinations). Traffic to a CIDR is sent to the correct attachment.
Basic Flow
Section titled “Basic Flow”- Create a Transit Gateway (one per region).
- Create a VPC attachment for each VPC (one subnet per AZ).
- Create a TGW route table (or use the default); associate each attachment with it.
- In each VPC route table, add routes for remote CIDRs with target = TGW attachment.
- In the TGW route table, ensure routes exist to each VPC (and to VPN/DX if used).
Transit Gateway vs VPC Peering
Section titled “Transit Gateway vs VPC Peering”| VPC Peering | Transit Gateway | |
|---|---|---|
| Topology | Point-to-point (mesh) | Hub-and-spoke |
| Transitive routing | No | Yes |
| VPN / Direct Connect | Separate per VPC | Single hub for all |
| Cost | Per-GB data transfer | Hourly per TGW + per attachment + per-GB |
| Best for | 2–3 VPCs | 5+ VPCs, hybrid, shared services |
Rule of thumb: Use peering for a small number of VPCs; use Transit Gateway when you have many VPCs or need VPN/Direct Connect on a single hub.
Cost (Brief)
Section titled “Cost (Brief)”- Hourly charge for the Transit Gateway.
- Hourly charge per attachment (VPC, VPN, etc.).
- Data processing charge for traffic through the TGW.
So cost can favor peering when you only have a few VPCs.
Multi-Region: Transit Gateway Peering
Section titled “Multi-Region: Transit Gateway Peering”To connect VPCs (or VPN/DX) across regions, you create a Transit Gateway peering between two Transit Gateways in different regions. Traffic stays on the AWS backbone.
Sharing Across Accounts
Section titled “Sharing Across Accounts”Use RAM (Resource Access Manager) to share a Transit Gateway with other AWS accounts. They create VPC attachments to your TGW without owning the TGW.
Site-to-Site VPN
Section titled “Site-to-Site VPN”Site-to-Site VPN is an IPsec tunnel between your VPC and an on-premises network over the public internet.
VPC (Virtual Private Gateway) ◄── IPsec over internet ──► Customer Gateway (on-prem)Components
Section titled “Components”| Component | What It Is |
|---|---|
| Virtual Private Gateway (VGW) | Attached to your VPC; AWS side of the VPN. |
| Customer Gateway | Logical AWS object for your on-prem device (IP, type). |
| Site-to-Site VPN connection | The tunnel(s) between VGW and Customer Gateway. |
| Customer Gateway device | Your on-prem router/firewall (e.g. Cisco, pfSense). |
You can attach a VGW to a VPC, or attach it to a Transit Gateway so that one VPN serves all VPCs attached to the TGW.
Two Tunnels
Section titled “Two Tunnels”Each VPN connection has two tunnels (for availability). If one path fails, the other can still carry traffic.
Static vs Dynamic Routing
Section titled “Static vs Dynamic Routing”- Static: You define the CIDR blocks that are reachable over the VPN (route-based).
- Dynamic (BGP): Your on-prem device and the VPN use BGP to exchange routes. Preferred for complex or changing networks.
When to Use
Section titled “When to Use”- You need encrypted connectivity to on-prem over the internet.
- You don’t need a dedicated physical link (that’s Direct Connect).
- Typical bandwidth is up to ~1.25 Gbps per tunnel (depending on instance type and configuration).
Direct Connect
Section titled “Direct Connect”Direct Connect is a dedicated physical connection (e.g. fiber) from your location (or a colo) to an AWS Direct Connect location. Traffic does not go over the public internet.
On-premises ──► Direct Connect location ──► AWS (VPC via Private VIF + Direct Connect Gateway)Concepts
Section titled “Concepts”| Concept | What It Is |
|---|---|
| Connection | The physical link (1 Gbps or 10 Gbps). |
| Virtual Interface (VIF) | Logical channel on that link. |
| Private VIF | Connects to your VPC(s) via a Direct Connect Gateway. |
| Direct Connect Gateway | Connects a Private VIF to one or more VPCs (same or different regions). |
Direct Connect + Transit Gateway
Section titled “Direct Connect + Transit Gateway”You can attach a Direct Connect Gateway to a Transit Gateway. Then all VPCs attached to that TGW can reach on-prem over the same DX connection — no separate VPN per VPC.
When to Use
Section titled “When to Use”- You need predictable bandwidth and low latency to AWS.
- You have high or steady data volume (often cheaper than VPN over internet).
- Compliance or policy requires a private path (no internet).
Connecting AWS to Another Cloud (Azure, GCP)
Section titled “Connecting AWS to Another Cloud (Azure, GCP)”You use the same building blocks on the AWS side as for on-premises: Site-to-Site VPN or Direct Connect (with a partner). The other cloud has its own gateway — Azure VPN Gateway or ExpressRoute, GCP Cloud VPN or Partner Interconnect — and must be configured separately. AWS Transit Gateway does not extend into other clouds; it is the hub on the AWS side that can hold the VPN (or DX) connection to the other cloud.
AWS-Side Setup (VPN)
Section titled “AWS-Side Setup (VPN)”To connect AWS to Azure or GCP over the public internet (IPsec):
- Customer Gateway — In AWS, create a Customer Gateway with the other cloud’s VPN gateway public IP (e.g. Azure VPN Gateway or GCP Cloud VPN public IP) and the correct BGP ASN if you use dynamic routing.
- VPN connection — Create a Site-to-Site VPN connection from a Virtual Private Gateway (single VPC) or from a Transit Gateway (all VPCs attached to the TGW). Attach it to the Customer Gateway you created.
- Routing — Add routes so traffic to the other cloud’s CIDRs (e.g. Azure VNet, GCP VPC) goes to the VPN attachment. Use static routes or enable BGP and advertise the other cloud’s prefixes.
- Other cloud — On Azure or GCP, create the VPN gateway (or use an existing one), add the AWS VPN tunnel endpoint IPs as the remote peer, and configure routing so traffic to your AWS CIDRs uses the VPN.
Both sides must agree on CIDRs, IKE/IPsec settings, and (if used) BGP. Typical throughput is up to ~1.25 Gbps per tunnel depending on the VPN instance type.
AWS-Side Setup (Private Link)
Section titled “AWS-Side Setup (Private Link)”For private connectivity (no internet) between AWS and another cloud:
- Use AWS Direct Connect to a colo or partner location.
- Use a partner (e.g. Megaport, Equinix) that can connect your Direct Connect to Azure ExpressRoute or GCP Partner Interconnect in the same facility.
- On the AWS side, the Direct Connect Gateway (and optionally Transit Gateway) is configured as for on-prem: Private VIF, association with your VPCs or TGW, and routing.
The other cloud’s ExpressRoute or Partner Interconnect is configured in Azure or GCP; the partner connects the two.
When to Use VPN vs Direct Connect (Multi-Cloud)
Section titled “When to Use VPN vs Direct Connect (Multi-Cloud)”| Site-to-Site VPN | Direct Connect + Partner | |
|---|---|---|
| Cost | No physical circuit; pay for VPN connection and data transfer. Lower fixed cost, good for moderate traffic. | Physical circuit + partner fees; often better unit cost at high, steady volume. |
| Latency | Traffic over internet; variable. | Private path; typically more consistent and often lower latency. |
| Complexity | Easier: create Customer Gateway and VPN connection, configure both clouds’ VPN gateways. | Higher: order circuit, work with partner, configure DX and the other cloud’s private link. |
| Use when | Quick setup, moderate bandwidth, acceptable internet variability. | High or predictable traffic, compliance need for private path, or need for stable latency. |
Choosing an Option
Section titled “Choosing an Option”| Scenario | Option |
|---|---|
| 2–3 VPCs, no on-prem | VPC Peering |
| 5+ VPCs, no on-prem | Transit Gateway (or peering mesh if you accept N² connections) |
| VPC ↔ on-prem over internet | Site-to-Site VPN (VGW on VPC or on TGW) |
| VPC ↔ on-prem private link | Direct Connect (Private VIF + DX Gateway; optionally via TGW) |
| Many VPCs + on-prem | Transit Gateway + VPN and/or Direct Connect attached to TGW |
| AWS ↔ Azure/GCP | Site-to-Site VPN (Customer Gateway = other cloud’s VPN gateway) or Direct Connect + partner (Megaport, Equinix) to ExpressRoute/Partner Interconnect |
Key Takeaways
Section titled “Key Takeaways”- VPC Peering is simple for 2–3 VPCs; no transitive routing; CIDRs must not overlap.
- Transit Gateway is a regional hub for many VPCs and for VPN/Direct Connect; supports transitive routing and segmentation via route tables.
- Site-to-Site VPN gives encrypted connectivity to on-prem over the internet; use a Virtual Private Gateway on a VPC or on a Transit Gateway.
- Direct Connect gives a dedicated private path to AWS; use a Direct Connect Gateway, optionally with a Transit Gateway.
- Use Transit Gateway when you have many VPCs or want one hub for hybrid (VPN + DX + VPCs).
- Multi-cloud (AWS ↔ Azure/GCP): Same options — VPN (Customer Gateway + VPN connection to the other cloud’s VPN gateway) or Direct Connect plus a partner to ExpressRoute/Partner Interconnect. For multi-cloud, prefer VPN for lower cost and simpler setup at moderate scale; prefer Direct Connect + partner for high volume, private path, or more predictable latency.