About VPC Peering Connections

A VPC peering connection enables two Virtual Private Clouds (VPCs) to communicate with each other using a private connection. Instances in peered VPCs can access each other.

General Information

Peered VPCs can belong to the same account, or to different accounts. You can create multiple peering connections for each of your VPCs. However, you cannot create more than one peering connection between the same two VPCs at the same time.

A peering connection is a private connection using private IPs. Peered VPCs must not have overlapping CIDR blocks, and must be located in the same Region. However, their subnets can be located in different Availability Zones. For more information, see About Regions, Endpoints, and Availability Zones.

When you create a connection, a request is sent to the VPC with which you want to connect. The owner of this VPC must accept the request for the connection to be established. For more information, see the Lifecycle section below.

  • If you use Cockpit v1 to create a VPC peering connection between two VPCs that belong to your account, the request is automatically accepted.

  • A peering connection between two VPCs works both ways. Therefore, you do not need to create a B-to-A connection if an A-to-B connection is already created and accepted.

Once the connection is created, network traffic between the peered VPCs is possible. You must update their route tables and security groups to allow traffic. For more information, see the Network Configuration section below.

A VPC peering connection is a direct, one-to-one, and non-transitive connection. That is, peered VPCs cannot communicate with other VPCs they are not directly peered with. Two VPCs each peered with the same third VPC cannot use it as a transit point to access each other.

Non-Transitive Connection through a VPC Peering Connection

sch General VPCPeeringConnection

To ensure redundancy and high-availability, you can peer two VPCs whose subnets are located in different Availability Zones.

Lifecycle

Once requested, a VPC peering connection can go through several state changes. With each state, different actions are possible.

VPC Peering Connection Lifecycle

sch General VPCPeeringConnectionLifecycle

  • failed: The creation of the VPC peering connection has failed. This happens, for example, when the VPCs are located in different Regions, or when their CIDR blocks overlap. A failed connection cannot be accepted, rejected, nor deleted.

  • pending-acceptance: The connection is awaiting action from the owner of the accepter VPC, who can accept or reject it. In the meantime, the owner of the requester VPC can still delete the request. If no action is taken, the request expires after 7 days.

  • expired: The request has expired. The connection can no longer be accepted, rejected, or deleted.

  • rejected: The request was rejected by the owner of the accepter VPC. No connection is created between the VPCs. The connection can no longer be accepted or deleted.

  • active: The connection was accepted by the owner of the accepter VPC. A connection is created between the VPCs. Either owner of the peered VPCs can delete it.

  • deleted: The VPC peering connection was deleted by either owner of the peered VPCs.

Connections in the failed, expired, or deleted states remain visible for 1 hour.

Network Configuration

Route Tables

To enable traffic between two peered VPCs, you need to update the route tables associated with their subnets.

Both owners of the VPCs must create a new route with the CIDR block of the other VPC as destination, and the ID of the VPC peering connection as target. This enables instances to route traffic between the two VPCs.

You can create a route for a VPC peering connection that is in the pending-acceptance state. However, in that case, the route is in the blackhole state until the VPC peering connection becomes active.

VPC Peering Connection Architecture

sch General VPCPeeringConnectionArchitecture

Security Groups

To allow traffic between the instances of the peered VPCs, you need to update the security groups associated with their instances.

Both owners of the VPCs must add the appropriate rules allowing outbound and inbound flows to and from the subnet of the peer VPC. For more information, see About Security Groups and Tutorial: Setting up a VPC Peering Connection.

Related Pages