VPC Peering features and limitations
This page lists the different features and limitations of Scaleway VPC Peering.
Features
Cross-project and cross-organization peering
VPC Peering lets you connect any two Scaleway VPCs, whether they belong to the same Project or Organization, or to different ones. There is no requirement for the two VPCs to share any common ownership or management.
Mutual consent security model
Peering connections are always mutually consented. An owner or manager of each VPC must independently create a peering connector towards the other. If only one side creates a connector, it remains in an Orphan state and no connection is established. No requests or notifications are sent between Organizations.
Fine-grained traffic control via custom routes
Once two VPCs are peered, you control exactly which traffic flows across the peering connection by creating custom routes. Routes support both IPv4 and IPv6, and each side independently manages its own routing configuration.
Transitive peering
VPC Peering natively supports transitive peering. This means that VPC A can communicate with VPC C via an intermediate VPC B (A ↔ B ↔ C), even without a direct peering connector between A and C. Transitivity requires custom routes to be configured in each VPC of the chain.
Unlimited traffic
Once a peering connection is established, there are no caps or rate limits on the traffic flowing across it.
Limitations
Same-region requirement
Two VPCs can only be peered if they are located in the same Scaleway region. Cross-region peering is not supported.
No overlapping CIDR blocks
For peering to be established, none of the CIDR blocks attributed to Private Networks in one VPC may overlap with those in the other VPC. If an overlap is detected, both connectors enter a Conflict state. Since CIDR blocks cannot be modified after a Private Network is created, conflicting Private Networks must be deleted and recreated with non-overlapping CIDR ranges. See our troubleshooting guide for more details.
Custom routes are not created automatically
Traffic does not flow between two peered VPCs automatically. You must manually create custom routes on each side to define the IP ranges that should be routed across the peering connection.
DHCP route propagation delay
When a new custom route is added to a VPC's route table, it is not propagated immediately to attached resources via DHCP. Resources will receive the updated routing information only upon their next DHCP lease renewal, which can take up to 1 hour.
Routing must be activated on older VPCs
VPCs created before routing was introduced must have routing activated before a peering connection can be successfully established.
Target VPC ID required
When creating a peering connector, you must specify the exact VPC ID of the target VPC. No additional information about the target VPC (such as its network topology or resources) is disclosed during the process.