AWS VPC Peering vs Transit Gateway

In This Article

• What is AWS VPC Peering?
• What is AWS Transit Gateway?
• What are the Differences Between VPC Peering and Transit Gateway?
• Point-to-point vs Hub-and-Spoke
• No Transit vs. Traffic Transit
• Complexity
• VPC-to-VPC only vs Additional Hybrid Connectivity
• Data Transfer Costs Only vs Additional Transit Gateway Costs
• Low Latency vs Increased Latency
• Bandwidth Limit
• Security Group Referencing
• Monitoring
• When to Use Each?

What is AWS VPC Peering?

VPC peering is network connection between two VPCs that allows you to route traffic between them using private IP addresses (IPv4 or IPv6).

In order to create VPC peering connection you have to provide:

• Requester VPC ID. The VPC that initiates VPC peering connection request.
• Accepter VPC ID. The VPC that receives peering connection request. This VPC can be from the same account, same region, different region or even from different account.

When the VPC peering connection has been created, the owner of the accepter VPC ID must accept the connection request:

In order to correctly route the traffic from one VPC to another, you must update route tables for your VPCs.

As you can see in the diagram above, an additional route needs to be added to both VPC route tables (used for public and private subnets):

• For the VPC with CIDR block 10.0.0.0/16, add a new route with the destination CIDR block 172.31.0.0/16 and target VPC peering ID (e.g., pcx-0e5412f6eb80362e7).
• For the VPC with CIDR block 172.31.0.0/16, add a new route with the destination CIDR block 10.0.0.0/16 and target VPC peering ID (e.g., pcx-0e5412f6eb80362e7)

What is AWS Transit Gateway?

Transit Gateway is network transit hub that is used to connect virtual private clouds (VPCs) and on-premises networks.

As you can see in the diagram above by using transit gateway and transit gateway attachments you can attach following resources:

• Virtual Private Clouds (VPCs)
• VPN connections
• AWS Direct Connect gateways
• Transit Gateway peering connections
• Transit Gateway Connect attachments

Each transit gateway automatically comes with a default route table that will contain routes for specific traffic (CIDR blocks) to transit gateway attachments:

However, this default transit gateway route table doesn’t mean you can skip configuring your VPC subnet route tables. For example, whenever you attach a VPC to a transit gateway, you still need to add a route to your subnet route tables for the traffic to be correctly routed (ex. to other connected VPC with CIDR 10.0.0.0/16 via transit gateway as target).

What are the Differences Between VPC Peering and Transit Gateway?

While both VPC Peering and Transit Gateway allow you to connect multiple VPCs, there are differences between them. We’ll now take a closer look at these differences, which might help you decide when to use each in the future.

Point-to-point vs Hub-and-Spoke

Each VPC peering connection is established between two VPCs, meaning that one VPC peering connection facilitates direct communication only between those two VPCs (point-to-point architecture).

However, a single transit gateway can connect multiple VPCs and on-premises networks (hub-and-spoke architecture).

As you can see in the diagram above, we have visualized two approaches for connecting four VPCs (enabling private traffic routing between all of them) using VPC Peering and Transit Gateway. To accomplish this with VPC Peering, you would need to create six VPC peering connections. In contrast, using a Transit Gateway requires only four VPC attachments.

No Transit vs. Traffic Transit

A VPC peering connection defines a 1:1 relationship between two VPCs. That’s why, if there is no explicit VPC peering connection created between two VPCs, you can’t route private traffic between them. For example, as shown in the diagram above, we have VPC A paired with both VPC C and VPC B. We can route private traffic between VPC A <-> VPC C and VPC A <-> VPC B. However, we cannot route traffic between VPC C and VPC B because there is no VPC peering connection created between them.

A transit gateway allows traffic to transit through the gateway to reach other connected VPCs or networks. For example, when you create a new VPC attachment for a transit gateway, this new VPC (e.g., VPC C) can route traffic to other connected VPCs (e.g., VPC B and VPC A), of course after the subnet route table is updated with the additional routes.

Complexity

It’s true that the number of required VPC peering connections increases as the number of connected VPCs grows. Essentially, this number follows an exponential pattern— for N VPCs, you would need N * (N-1)/2 peering connections.

For example:

• For 3 connected VPCs, you would need 3 VPC peering connections.
• For 6 connected VPCs, you would need 15 VPC peering connections.
• For 10 connected VPCs, you would need 45 VPC peering connections.

However, when using a transit gateway to connect N VPCs, you only need N VPC attachments. For instance, with 10 connected VPCs, you would only need 10 transit gateway VPC attachments.

Of course, this “number pattern difference” only is true if all VPCs are in the same region. If the VPCs are located in different regions, then the complexity of using a transit gateway increases because you will need at least one transit gateway per region, and for all the involved regions, you’ll need to create multiple transit gateway peering connections.

You can see in the diagram above that in order to support cross-account VPC routing with one VPC in each of the four regions:

• For Transit gateway: you would need 6 peering attachments and 4 VPC attachments = 10 transit gateway attachments in total.
• For VPC peering: you would only need 6 VPC peering connections.

Let’s not forget one often-overlooked fact: even though a transit gateway comes with its own routing table that contains routes to transit gateway attachments, this doesn’t mean you can skip updating each VPC subnet route table. You still need to add a separate route for each connected VPC. This means that whenever you connect a new VPC to your transit gateway, you must update the route table for each VPC to ensure proper traffic routing to the new VPC. So in the end, you end up maintaining VPC/subnet and transit gateway route tables.

From my experience, I can say that many professionals often forget or are unaware that they need to update each connected VPC route table too when adding new VPC attachments. This could lead to incorrect analysis when choosing between VPC peering and a transit gateway for their next AWS network architecture.

VPC-to-VPC only vs Additional Hybrid Connectivity

As we mentioned previously VPC peering connection connects two VPCs and allows to route private traffic (via IPv4 or IPv6 addresses) between these two. That’s the main use-case for using VPC peering connections.

However, transit gateway besides of connecting multiple VPCs together has capability to connect on-premises network to AWS VPCs:

• By associating Direct Connect gateway with transit gateway.
• By creating site-to-site VPN attachments in transit gateway.

Of course, you can still connect your VPCs to your on-premises network without using a transit gateway by using the traditional approach of a VPN gateway and VPN connection. However, if multiple VPCs need access to your on-premises network, you would have to create multiple VPN connections for each VPC. By using a transit gateway with a VPN attachment, you could simplify your network architecture by using only one VPN connection.

Data Transfer Costs Only vs Additional Transit Gateway Costs

For VPC peering connections, you are charged only for data transfer that crosses availability zones and regions. Currently, data transfer prices are as follows:

• For intra-region: $0.01 per GB
• For inter-region: $0.02 per GB

Transit gateway pricing consists of:

• Data transfer charge (similar as for VPC peering)
• Data processing charge: $0.02 per GB
• Price per transit gateway attachment: $0.05 per hour

Compared to VPC peering, you have to pay additional costs for data processing and for each attachment you use.

For example, in a scenario where you use a transit gateway with 3 VPC attachments for one month (30 days) and 10 GB of total data transfer (intra-region), you would have to pay:
$0.10 (data transfer) + $0.20 (data processing) + $108 (3 attachments per month) = $108.3

I guess you already understood that if you would use VPC peering connections for the same scenario that the total price most likely would be only around $0.10.

Low Latency vs Increased Latency

VPC peering provides lower latency compared to a transit gateway. This is due to the direct VPC-to-VPC communication with a direct network path and no intermediary devices.

A transit gateway introduces slightly higher latency due to the additional traffic routing and processing through the centralized hub. Essentially, latency will increase with each additional transit gateway and attachment involved in the traffic routing. That’s why, when designing your network using transit gateways, you should try to optimize the communication path by using fewer transit gateways and attachments to achieve lower latency.

Bandwidth Limit

For VPC peering, there is no bandwidth limit (no aggregate bandwidth).

For a transit gateway, the maximum bandwidth (burst) per availability zone per VPC connection is 50 Gbps.

Of course, for both VPC peering and transit gateway connections, individual instance network performance limits apply (10 Gbps within the same placement group and 5 Gbps otherwise).

Security Group Referencing

When using VPC peering connections (within the same region), you can update the inbound and outbound rules for your security groups to reference security groups in the peered VPC (using the security group ID as the source or destination). This gives you the ability to have more granular and flexible security configurations.

For example, if there are two VPCs, VPC A and VPC B, peered within the same region, you can create a security group rule in VPC A that allows inbound traffic from instances in VPC B by referencing the security group of VPC B.

A transit gateway doesn’t support security group referencing.

Monitoring

You can monitor VPC peering and transit gateway traffic using VPC flow logs. You can send the logs to an S3 bucket, a CloudWatch Logs group, or a Kinesis Data Firehose stream.

In addition to flow logs, to gain more visibility into your transit gateway network configuration (it’s not available for VPC peering), you can use AWS Transit Gateway Network Manager.

When to Use Each?

I will most likely have an unpopular opinion on this topic because in the majority of comparisons you can find by googling “VPC Peering vs Transit Gateway”, you’ll come across advice like this: “For simple one-to-one network connections, use VPC peering, and for more complex network architectures where you need to scale, use a transit gateway”.

To be honest, my opinion is a bit different. In most AWS networking scenarios where you are connecting VPCs to enable private traffic routing between them, I would use VPC peering connections.

A few of the reasons:

• Cost-effectiveness: VPC peering is much more cost-effective. For example, the monthly cost for just using 10 transit gateway VPC attachments is $360 (excluding data transfer and processing charges). With VPC peering, you would only pay for data transfer, with no data processing and VPC peering usage charges.
• Latency: While latency may not be a dealbreaker for some architectures, it can be critical in many network architectures (e.g., multi-tier applications, hybrid cloud configurations, cross-account connectivity) where fast connections and quick responses are needed.
• Complexity: Yes, as more VPCs need to be connected, more VPC peering connections are required. However, this shouldn’t be a problem if you are using infrastructure as code to manage your infrastructure, as you can automate the process when adding new VPCs. Additionally, the complexity of using a transit gateway increases as the number of transit gateways and AWS regions used increases, which is likely with a large number of VPCs.
• Selective Connectivity: Not all VPCs used in your network architecture may need to be connected to each other.
• Simplified Routing: With VPC peering, only VPC subnet route table updates are needed, compared to the additional transit gateway route table management.
• Cost-Effective On-Premises Connectivity: Even if you need to connect all your VPCs to your on-premises network (which is very unlikely), using a VPN gateway and a site-to-site VPN connection for each VPC would still be less expensive than using a transit gateway and VPN attachments.

Yes, there is a limitation of 125 maximum VPC peering connections per VPC. However, that’s a lot, and if you have a network of 50+ VPCs that need to be connected, you should consider using transit gateways and attachments. Be aware that with that number of VPCs needing to be connected to each other or to on-premises networks, you will always incur high operational costs, regardless of whether you use VPC peering or transit gateways.