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.
|
Peered VPCs must contain at least one instance each before the creation of the VPC peering connection. |
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.
|
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.
|
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.
-
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.
|
We recommend waiting until the VPC peering connection is in the |
For more information, see About Route Tables and Tutorial: Setting Up a VPC Peering Connection.
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