VPC Peering

VPC peering connects two VPCs so they can communicate using private IP addresses as if they were on the same network. Use it for cross-project, inter-region, or cross-account connectivity without traversing the public internet.

When to Use VPC Peering

• Multi-environment — Connect production and staging VPCs for controlled data sync
• Microservices — Separate VPCs per team or service with private connectivity
• Hybrid — Connect NFYio VPCs to on-premises or other cloud VPCs (via VPN or direct connect)
• Cross-account — Share resources between different NFYio accounts or organizations

Architecture

┌─────────────────────┐                    ┌─────────────────────┐
│  VPC A (10.0.0.0/16)│                    │  VPC B (172.16.0.0/16)│
│                     │                    │                     │
│  ┌───────────────┐  │   Peering Link     │  ┌───────────────┐  │
│  │ Bucket A      │  │◄──────────────────►│  │ Agent B      │  │
│  │ 10.0.2.10     │  │                    │  │ 172.16.2.20   │  │
│  └───────────────┘  │                    │  └───────────────┘  │
│                     │                    │                     │
└─────────────────────┘                    └─────────────────────┘

Traffic between peered VPCs stays on the NFYio backbone and does not go over the public internet.

CIDR Requirements

Peered VPCs must not have overlapping CIDR blocks. If both use 10.0.0.0/16, peering cannot be established.

Valid example:

• VPC A: 10.0.0.0/16
• VPC B: 172.16.0.0/16

Invalid example:

• VPC A: 10.0.0.0/16
• VPC B: 10.1.0.0/16 (overlaps with 10.x.x.x)

Plan CIDR blocks upfront if you expect to peer VPCs.

Inter-Region Peering

Connect VPCs in different regions (e.g., us-east-1 and eu-west-1):

• Latency — Higher than same-region; traffic crosses regional boundaries
• Bandwidth — May have different limits than same-region peering
• Use case — Disaster recovery, global data replication, multi-region apps

curl -X POST https://api.yourdomain.com/v1/vpc-peering \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "requester_vpc_id": "vpc_us_east",
    "accepter_vpc_id": "vpc_eu_west",
    "requester_region": "us-east-1",
    "accepter_region": "eu-west-1"
  }'

Cross-Account Peering

Connect VPCs owned by different NFYio accounts:

1. Requester initiates the peering request
2. Accepter must accept the request (via console or API)
3. Both accounts need appropriate IAM permissions

Requester side:

curl -X POST https://api.yourdomain.com/v1/vpc-peering \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "requester_vpc_id": "vpc_abc123",
    "accepter_vpc_id": "vpc_xyz789",
    "accepter_account_id": "account_other_org"
  }'

Accepter side:

curl -X POST https://api.yourdomain.com/v1/vpc-peering/peer_xxx/accept \
  -H "Authorization: Bearer $ACCEPTER_API_KEY"

Transitive Routing

VPC peering is not transitive. If VPC A peers with VPC B, and VPC B peers with VPC C, VPC A cannot reach VPC C through B.

VPC A ◄──► VPC B ◄──► VPC C
  │                      │
  └──── No direct path ──┘

To connect A and C, create a direct peering connection between them.

Setting Up a Peering Connection

Step 1: Create the Peering Request

curl -X POST https://api.yourdomain.com/v1/vpc-peering \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "requester_vpc_id": "vpc_abc123",
    "accepter_vpc_id": "vpc_def456",
    "auto_accept": true
  }'

auto_accept: true works when both VPCs are in the same account. For cross-account, the accepter must explicitly accept.

Step 2: Update Route Tables

Add routes in both VPCs to direct traffic to the peer:

VPC A route table:

Destination	Target
172.16.0.0/16	pcx_peer_xxx

VPC B route table:

Destination	Target
10.0.0.0/16	pcx_peer_xxx

Step 3: Update Security Groups and NACLs

Ensure security groups and network ACLs allow traffic between the peered CIDR blocks. By default, they may block cross-VPC traffic.

Via API (Route Table Update)

curl -X POST https://api.yourdomain.com/v1/route-tables/rtb_xxx/routes \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "destination_cidr": "172.16.0.0/16",
    "target": "pcx_peer_xyz789"
  }'

Peering Status

Status	Meaning
pending	Request sent, awaiting acceptance
active	Peering established, traffic can flow
rejected	Accepter declined the request
expired	Request expired before acceptance
failed	Peering could not be established (e.g., CIDR overlap)

Verify Connectivity

From a resource in VPC A, ping or curl a resource in VPC B:

# From a container/resource in VPC A (10.0.0.0/16)
curl http://172.16.2.20:7010/health

Best Practices

1. Plan CIDRs — Avoid overlapping blocks before creating VPCs
2. Document peering — Keep a map of which VPCs peer with which
3. Least privilege — Restrict security group rules to peered CIDRs only
4. Monitor — Track peering connection metrics for bandwidth and errors

Next Steps

• Private Endpoints — Access services via private IPs
• VPC — VPC fundamentals
• Networking API Reference — Peering API details