VPC peering connections allow two or more VPCs to access resources in each VPC from the other, as shown in Figure 8.1. The AWS peering service has no bandwidth limitations, and there is no single failure point. It does not rely on gateways, Direct Connect, or VPN interconnections. This allows full IPv4 and IPv6 connectivity between services in each VPC. Peering connections can be in the same account or between separate accounts. Connections can be made across regions and availability zones. Instances running inside of a VPC, such as EC2 or Lambda, have full private network communications without the need to configure a gateway or NAT instance. All VPC-to-VPC traffic can use the private IP address space and transits the AWS internal global network.
FIGURE 8.1 VPC peer connection
Figure 8.2 shows a multi-VPC peering architecture between VPCs A, B, and C. Since A is directly connected to B, they can exchange traffic. This is also true for the VPC B to C peering connection. However, since A is not directly connected to C, there can be no exchange of traffic; this is known as nontransitive peering. To route traffic from VPC A to VPC C, you must create a meshed peer connection between the two, as shown in Figure 8.3. VPC peering does not support transitive routing; for example, if a VPC has an Internet connection, the peered VPC cannot connect through it to reach the Internet. This is also true for NAT devices where, for example, VPC A peer is connected with VPC B and uses its NAT gateway to exit the VPC to access services external to VPC B. Edge-to-edge routing is not supported through the peer connection to a gateway, VPN, or private Direct Connect. Gateway endpoints in a VPC such as for internal DynamoDB and S3 connections do not support transitive connections over a peer connection.
All peering connections represent a one-to-one connection between two VPCs. However, each VPC can have many peer connections to multiple VPCs. A VPC can route traffic only between VPCs that are directly connected; there is no transitive routing through an indeterminate peered VPC to another VPC that does not have a peer connection to the originating VPC. They must be directly connected.
FIGURE 8.2 Nontransitive peering
The default maximum number of peering connections is 50 per VPC. However, this can be increased to a maximum of 125 by contacting AWS Support and requesting an increase. There can be only a single peer connection between VPCs; tags are applied in the account only in a single region. DNS support can be enabled to resolve private domain names to the private IP address space if enabled. The IP CIDR blocks must be unique in each VPC. If there are overlapping or duplicate IP address spaces, routing is not possible.
Many of these limitations can be resolved by implementing the VPC Transit Gateway instances that are discussed later in this chapter.
AWS does not charge for VPC peer connections; however, standard data transfer charges still apply.
VPC peering between regions is supported and can be used, for example, for data replication and geographic proximity to reduce network latency. However, there are several limitations to be aware of when stretching a VPC peer between two different regions. Jumbo frames are not supported, so there is a basic maximum Ethernet frame size of 1,500 bytes that applies. However, jumbo frames are supported when peering inside a single region. You cannot use a security group in one region that references a security group in the other region. DNS resolution for private networks is supported across regions but must be enabled, as it is disabled by default.
It is a common architecture to create a central VPC for shared services. This allows you to create common resources in a single VPC and share them between the other VPCs, as shown in Figure 8.4.
The shared services VPC can be used as a central file sharing location to host management and monitoring applications such as Active Directory services or for a VPC you want to share with your customers but not allow the customers to see each other’s data.