Skip to main content
This guide demonstrates how to set up VPC peering so resources in one VPC can communicate with resources in another VPC. We’ll cover the required steps: create the peering connection (request + accept) and update route tables so traffic flows over the peering connection. VPCs in this demo:
  • VPC-A: 10.1.0.0/16
  • VPC-B: 10.2.0.0/16
A screenshot of the Amazon Web Services VPC console listing four VPCs (including VPC-A, vpcdemo and a selected VPC-B) with their VPC IDs, state marked "Available," and IPv4 CIDR ranges. The left sidebar shows VPC navigation options like Subnets, Route tables, and Internet gateways.
Summary of instances for the test:
  • server-one (in VPC-A): private IP 10.1.1.13
  • server-two (in VPC-B): private IP 10.2.1.139
Table: resources and addresses Initial test: ping from server-one to server-two fails because VPCs are isolated by default.
This failure is expected. Before creating a peering connection, ensure your security groups and network ACLs already permit the traffic you want. In this demo those are already configured—so the remaining steps are creating the peering connection and updating routes.

Create the VPC peering connection

Steps (console):
  1. Open VPC → Peering Connections → Create Peering Connection.
  2. Give the peering a name (e.g., “VPC-A to VPC-B”).
  3. Choose the requester VPC (VPC-A).
  4. Choose the accepter VPC (VPC-B). You can select a VPC in the same account or in a different account, and you can choose same-region or cross-region peering.
Important: The two VPC CIDR blocks must not overlap—peering requires non-overlapping CIDRs so each VPC can route traffic to the other.
Screenshot of the AWS VPC Management Console on the "Create Peering Connection" page, showing two VPCs being peered (VPC-A 10.1.0.0/16 and VPC-B 10.2.0.0/16) in the us-east-1 region with their CIDRs marked "Associated."
After submitting the request, the peering connection appears in the console with state “Pending acceptance.” For cross-account peering, the other account owner must accept the request; for same-account peering you still need to Accept in the console.
A screenshot of the AWS VPC Management Console showing details for a VPC peering connection (pcx-...) between two VPCs labeled VPC-A and VPC-B. The peering request is shown as "Pending acceptance" with owner IDs, CIDR info, and related settings tabs visible.
Accept the request in the console (Actions → Accept request).
The screenshot shows the AWS VPC console with a modal dialog titled "Accept VPC peering connection request" displaying requester and accepter VPC details, owner IDs, and CIDR information. There are navigation menus on the left and an "Accept request" button at the bottom right of the dialog.

Update route tables (both VPCs)

Creating/accepting the peering connection alone does not forward traffic. You must update the route tables associated with the subnets that host your instances so that each VPC knows to route traffic destined for the other VPC via the peering connection. Example routes to add:
  • In the route table for subnets in VPC-A:
    • Destination: 10.2.0.0/16
    • Target: the VPC peering connection (e.g., pcx-xxxxxxxx)
  • In the route table for subnets in VPC-B:
    • Destination: 10.1.0.0/16
    • Target: the same peering connection
Here’s the route table edit showing the route to the peering connection added for 10.2.0.0/16.
A screenshot of the AWS VPC console "Edit routes" page showing a route table with destinations 10.1.0.0/16 (local), 0.0.0.0/0 (internet gateway igw-...), and 10.2.0.0/16 (peering pcx-...). The page shows status indicators, Remove buttons, and "Preview" / "Save changes" controls at the bottom.
If you try to ping immediately after accepting the peering but before updating route tables, it will still fail:
Once you add the correct routes to both sides, traffic can flow over the peering connection. The ping should then succeed:
Traffic between the VPCs uses the AWS private network and does not traverse the public internet.
Important reminders:
  • CIDR blocks must not overlap for peering to work.
  • Update the route tables associated with the subnets on both VPCs to point to the peering connection.
  • Ensure security groups and NACLs permit the desired traffic.
  • VPC peering is non-transitive: A ↔ B and B ↔ C does not imply A ↔ C.
That’s all that’s required for basic VPC peering: create the peering connection (request and accept), then add matching routes in both VPCs so instances can reach each other.

Watch Video

Practice Lab