scaleway · SamyOubouaziz · Jun 23, 2026 · Jun 22, 2026 · Jun 22, 2026 · Jun 22, 2026
@@ -0,0 +1,8 @@
+---
+macro: ingress-routing-rule-concept
+---
+An ingress routing rule routes incoming traffic from a peered VPC to a specific private IP address within a destination VPC's Private Network. For example, this allows you to force all traffic entering a VPC from a peering connection to first go through a central firewall before reaching its final destination to inspect traffic.
+
+Ingress routing rules are defined at the VPC level and apply only to that VPC. They affect inter-VPC traffic (traffic coming from other VPCs) and do not apply to internal traffic within the VPC itself. You can configure multiple ingress routing rules per VPC.
+
+Each rule is composed of a **source** (the CIDR block of the source subnet targeted by the rule), and a **next hop** (the IP of a resource in a specific Private Network to which the traffic is forwarded). For detailed information, see [How to create an ingress routing rule](/vpc-peering/how-to/manage-routing/#how-to-create-an-ingress-routing-rule).
@@ -4,12 +4,10 @@ description: Learn the core concepts of Scaleway VPC Peering, including peering
 tags: vpc-peering, vpc, networking, private-network, cidr-block, custom-routes, ip-type, origin-vpc, target-vpc, orphan, peering-connector, peering-connection
 dates:
   creation: 2026-02-10
-  validation: 2026-02-10
+  validation: 2026-06-22
 ---
 
-<Message type="note">
-VPC Peering is currently in Public Beta.
-</Message>
+import IngressRoutingRuleConcept from '@macros/vpc/ingress-routing-rule-concept.mdx'
 
 ## CIDR block
 
@@ -21,6 +19,10 @@ For two VPCs to be successfully peered, none of the CIDR blocks assigned to thei
 
 To route traffic between two peered VPCs, you must create custom routes on each side. These are user-defined, personalized routes that let you route all traffic destined for an IP address within a defined range, to a designated next hop. The next hop can be a resource within this VPC, or a peered VPC. [How to create custom routes](/vpc/how-to/manage-routing/#how-to-create-a-custom-route).
 
+## Ingress routing rule
+
+<IngressRoutingRuleConcept />
+
 ## Origin VPC
 
 The VPC that initiates a [peering connection](#peering-connection). When you create a [peering connector](#peering-connector), you designate one of your own VPCs as the origin, and another VPC as [target](#target-vpc). This expresses your consent, as a manager of the origin VPC, to peer with the target VPC.
@@ -47,9 +49,11 @@ The VPC that is identified in a [peering connection](#peering-connection) as the
 
 ## Transitive peering
 
-Scaleway VPC Peering natively supports transitive peering across up to four chained VPCs. This means VPC A can communicate with VPC C via an intermediate VPC B (A ↔ B ↔ C), even though VPC A and C are not directly connected with a peering connector.
+Scaleway VPC Peering supports transitive peering across up to four chained VPCs. This means VPC A can communicate with VPC C via an intermediate VPC B (A ↔ B ↔ C), even though VPC A and C are not directly connected with a peering connector.
+
+Transitive peering is disabled by default. It must be enabled on the intermediary VPC (the VPC that forwards traffic between the two others) when [creating this VPC](/vpc/how-to/create-vpc/#how-to-create-a-vpc). Only intermediary VPCs require this setting, and it cannot be disabled after the VPC is created.
 
-To allow transitive peering across chained VPCs, additional [custom routes](#custom-routes) must be created in each VPC of the transitive chain.
+To allow transitive peering across chained VPCs, additional [custom routes](#custom-routes) must also be created in each VPC of the transitive chain.
 
 Refer to the [dedicated documentation](/vpc-peering/reference-content/understanding-transitive-peering/) for more information on transitive peering.
 

@@ -4,17 +4,12 @@ description: Get answers to common questions about Scaleway VPC Peering. Learn h
 tags: vpc-peering, networking, cloud-infrastructure, private-networks, vpc, network-connectivity, cloud-networking
 dates:
   creation: 2026-02-10
-  validation: 2026-02-10
+  validation: 2026-06-22
 productIcon: VpcPeeringProductIcon
 ---
 
 import peeringDiag from './assets/scaleway-vpc-peering-diag.webp'
 
-
-<Message type="note">
-VPC Peering is currently in Public Beta.
-</Message>
-
 ## Overview
 
 ### What is VPC Peering?
@@ -47,7 +42,7 @@ No. Only VPCs in the same Scaleway region can be peered.
 
 ### Does Scaleway VPC Peering support transitive peering?
 
-Yes, you can chain several VPCs using peering connectors, and benefit from transitivity between up to four VPCs using custom routes.
+Yes, you can chain several VPCs using peering connectors, and benefit from transitivity between up to four VPCs using custom routes. Transitive peering is disabled by default and must be enabled on the intermediary VPC (the one forwarding traffic between two others) when this VPC is created. This setting cannot be disabled afterward.
 
 Refer to the [dedicated documentation](/vpc-peering/reference-content/understanding-transitive-peering/) for more information on transitive peering.
 

@@ -3,16 +3,23 @@ title: How to manage routing for VPC Peering
 description: Find out how to manage a VPC Peering connector using the Scaleway console.
 tags: vpc peering connector connect pair peer secure private networks
 dates:
-  validation: 2026-05-11
+  validation: 2026-06-22
   posted: 2026-05-11
 ---
 
+import Requirements from '@macros/iam/requirements.mdx'
 import VPCRoutingCompatibility from '@macros/vpc-peering/vpc-routing-compatibility.mdx'
 
 This page explains how to manage routing for a VPC Peering connector using the [Scaleway console](https://console.scaleway.com/). To allow traffic through a peering connector, you must create a custom route in each of the two peered VPCs. Each route's destination must be a subnet containing the IP addresses of the resources in the opposite VPC that need to communicate through the connector.
 
 <VPCRoutingCompatibility />
 
+<Requirements />
+
+- A Scaleway account logged into the [console](https://console.scaleway.com)
+- [Owner](/iam/concepts/#owner) status or [IAM permissions](/iam/concepts/#permission) allowing you to perform actions in the intended Organization
+- [Created a peering connector](/vpc-peering/how-to/create-peering-connector/)
+
 ## How to create a custom route
 
 Each VPC has auto-generated, managed routes to local subnets and Public Gateways, but you can also create your own custom routes.
@@ -23,20 +30,74 @@ Each VPC has auto-generated, managed routes to local subnets and Public Gateways
 
 3. Click the **Routing** tab.
 
-4. Click **Create route**. The custom route creation wizard displays.
-
-5. Enter a **description** for your route, e.g. "Route to VPC B".
+4. Click **Create route** in the **Route table** section. The custom route creation wizard displays.
 
-6. Optionally, enter one or more **tags** for your route. Tags help you filter and organize your list of routes.
+5. Select the **IP type** (**IPv4** or **IPv6**) of the route's destination.
 
-7. Enter a **destination** for the route. The VPC will apply the route to all traffic with a matching destination IP. You must enter an IPv4 or IPv6 CIDR range with a subnet mask, e.g. `192.168.1.0/24`. For a single IP address, use the `/32` mask for IPv4.
+6. Enter an **IP address range** for the destination. The VPC will apply the route to all traffic with a matching destination IP. You must enter a CIDR range with a subnet mask, e.g. `192.168.1.0/24`. For a single IP address, use the `/32` mask for IPv4.
 
     <Message type="note">
     If you enter a destination of `0.0.0.0/0`, all packets not destined for a local Private Network will be sent through the peering connector.
     </Message>
 
-8. Choose **Peering connector** as the **next hop** for the route, then select the desired peering connector from the drop-down list. The VPC will route traffic for the destination IP to the selected entry.
+7. Under **Enter next hop**, select **Peering connector** as the **next hop type**, then select the desired peering connector from the drop-down list. The VPC will route traffic for the destination IP to the peered VPC and all the Private Networks within it.
+
+8. Optionally, under **Enter custom route details**, enter a **route description**, and one or more **route tags**. Tags help you organize your list of routes.
 
 9. Click **Create route** to finish.
 
-Your new route now displays in the **Routing** tab of your VPC. A matching custom route must be added to the target VPC for traffic to flow between the peered VPCs. The destination of that return route must be a subnet that contains the IP address(es) of the resources in the origin VPC that need to reach the peered side.
+Your new route now displays in the **Routing** tab of your VPC. A matching custom route must be added to the target VPC for traffic to flow between the peered VPCs. The destination of that return route must be a subnet that contains the IP address(es) of the resources in the origin VPC that need to reach the peered side.
+
+## How to create an ingress routing rule
+
+An ingress routing rule allows you to manually define the destination for traffic originating from a peered VPC. Ingress routing rules do not apply to internal traffic from the VPC where you create them.
+
+1. Click **VPC** in the **Network** section of the Scaleway console side menu. A list of your VPCs displays.
+
+2. Use the **region selector** at the top of the page to filter for the region of the VPC where you want to define an ingress routing rule, then click the VPC. A list of Private Networks in this VPC displays.
+
+3. Click the **Routing** tab.
+
+4. Click **Create rule** in the **Ingress routing rules** section. The ingress routing rule creation wizard displays.
+
+5. Select the **IP type** (**IPv4** or **IPv6**) of the incoming traffic from the peered VPC.
+
+6. Enter the **IP address range** of the incoming traffic from the peered VPC. You must enter a CIDR range with a subnet mask, e.g. `192.168.1.0/24`. For a single IP address, use the `/32` mask for IPv4.
+
+7. Under **Enter next hop**, select the **Private Network** that the VPC should route the matching traffic through.
+
+8. Enter the **IPv4 address** of the resource to route the traffic to via the selected Private Network.
+
+9. Optionally, enter a **rule description**, and **rule tags** to help you organize your list of rules.
+
+10. Click **Create rule** to finish.
+
+Your new ingress routing rule now displays in the **Ingress routing rules** section of the **Routing** tab of your VPC.
+
+## How to manage an ingress routing rule
+
+1. Click **VPC** in the **Network** section of the Scaleway console side menu. A list of your VPCs displays.
+
+2. Use the **region selector** at the top of the page to filter for the region of the VPC whose ingress routing rule you want to manage, then click the VPC. A list of Private Networks in this VPC displays.
+
+3. Click the **Routing** tab.
+
+4. Click the edit <Icon name="edit" /> icon next to the rule you want to modify in the **Ingress routing rules** section.
+
+5. Modify the details of the ingress routing rule as necessary, then click **Save changes** to finish.
+
+    The ingress routing rule is updated, and you are returned to the list of your VPC's ingress routing rules.
+
+## How to delete an ingress routing rule
+
+1. Click **VPC** in the **Network** section of the Scaleway console side menu. A list of your VPCs displays.
+
+2. Use the **region selector** at the top of the page to filter for the region of the VPC whose ingress routing rule you want to delete, then click the VPC. A list of Private Networks in this VPC displays.
+
+3. Click the **Routing** tab.
+
+4. Click the delete <Icon name="delete" /> icon next to the ingress routing rule you want to delete in the **Ingress routing rules** section. A pop-up displays asking you to confirm.
+
+5. Click **Confirm** to proceed.
+
+    The ingress routing rule is deleted, and you are returned to the list of your VPC's ingress routing rules.
@@ -4,13 +4,9 @@ description: This page presents the different features and limitations of Scalew
 tags: vpc-peering features limitations specs quota transitivity dhcp technical datasheet
 dates:
   creation: 2026-04-10
-  validation: 2026-04-10
+  validation: 2026-06-22
 ---
 
-<Message type="note">
-VPC Peering is currently in Public Beta.
-</Message>
-
 This page lists the different features and limitations of Scaleway VPC Peering.
 
 ## Features
@@ -29,7 +25,7 @@ Once two VPCs are peered, you control exactly which traffic flows across the pee
 
 ### 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.
+VPC Peering 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. Transitive peering is disabled by default and must be enabled on the intermediary VPC (here, VPC B) at its creation. This setting cannot be disabled afterward. Transitivity also requires custom routes to be configured in each VPC of the chain.
 
 ### Unlimited traffic
 

@@ -7,10 +7,6 @@ dates:
   posted: 2026-02-10
 ---
 
-<Message type="note">
-VPC Peering is currently in Public Beta.
-</Message>
-
 ## VPC Peering connector statuses
 
 A VPC Peering connector always has a **status**.

@@ -3,7 +3,7 @@ title: Understanding transitive peering
 description: This page helps users understand how transitivity works when using Scaleway VPC Peering.
 tags: peering transitivity daisy chained hub spoke
 dates:
-  validation: 2026-05-18
+  validation: 2026-06-22
   posted: 2026-05-18
 ---
 
@@ -14,19 +14,15 @@ import peeringNoTransitivity4 from './assets/scaleway-vpc-peering-no-transitivit
 import peeringTransitivity4 from './assets/scaleway-vpc-peering-transitivity-4.webp'
 import peeringFullTransitivity from './assets/scaleway-vpc-peering-full-transitivity-4.webp'
 
-<Message type="note">
-VPC Peering is currently in Public Beta.
-</Message>
-
 ## Overview
 
-Scaleway VPC Peering natively supports transitive peering.
-
 Transitive peering (or transitive routing) allows two VPCs that are not directly peered to exchange traffic through a third VPC that is peered with both. Traffic is forwarded through this intermediate network, making the connection transitive.
 
-To enable transitivity, you must [define custom routes](/vpc/how-to/manage-routing/#how-to-create-a-custom-route) in each VPC.
+Transitive peering is disabled by default. It must be [enabled on the intermediary VPC](/vpc/how-to/create-vpc/#how-to-create-a-vpc) (the VPC that forwards traffic between the two others) when that VPC is created. Only intermediary VPCs require transitive peering to be enabled, and this setting cannot be disabled after the VPC is created.
+
+To enable transitivity, you must also [define custom routes](/vpc/how-to/manage-routing/#how-to-create-a-custom-route) in each VPC of the chain.
 
-For example, if VPC A is peered with both VPC B and VPC C, you can route traffic between VPC B and VPC C through VPC A. To do so, define a custom route in VPC B directing traffic to VPC C via VPC A, and a corresponding route in VPC C directing traffic to VPC B via VPC A.
+For example, if VPC A is peered with both VPC B and VPC C, you can route traffic between VPC B and VPC C through VPC A. As the intermediary, VPC A must have transitive peering enabled. To route the traffic, define a custom route in VPC B directing traffic to VPC C via VPC A, and a corresponding route in VPC C directing traffic to VPC B via VPC A.
 
 <Message type="note">
 As routing complexity increases with each additional VPC in the transitivity chain, transitive peering is limited to four chained VPCs.

@@ -4,17 +4,12 @@ description: Discover how VPC Peering enables secure, private connections betwee
 tags: vpc-peering, networking, private-connection, secure-connectivity, cross-project, cross-organization, custom-routes, hub-and-spoke
 dates:
   creation: 2026-02-10
-  validation: 2026-02-10
+  validation: 2026-06-22
 ---
 
 import peeringDiag from './assets/scaleway-vpc-peering-diag.webp'
 import VPCRoutingCompatibility from '@macros/vpc/vpc-routing-compatibility.mdx'
 
-<Message type="note">
-VPC Peering is currently in Public Beta.
-</Message>
-
-
 This document covers the features, use cases, pricing, and technical details of VPC Peering.
 
 ## Overview
@@ -81,7 +76,7 @@ VPC Peering connectors are a regional resource, and are available in multiple re
 - You must know the VPC ID of the target VPC you want to peer with, in order to create a peering connection.
 - You must create custom routes in order to route traffic across a peering connection. Traffic will not be routed between them automatically or via any auto-created, managed routes.
 - All resources which are [compatible with VPC routing](/vpc/reference-content/understanding-routing/#limitations) are also compatible with VPC Peering, and traffic can be routed across a peering connection to and from these resources.
-- [Transitive peering](/vpc-peering/concepts/#transitive-peering) is limited to four chained VPCs (three peering connectors).
+- [Transitive peering](/vpc-peering/concepts/#transitive-peering) is limited to four chained VPCs (three peering connectors). It is disabled by default and must be enabled on the intermediary VPC at its creation. This setting cannot be disabled afterward.
 - If the VPCs have [network ACLs](/vpc/reference-content/understanding-nacls/) with a deny default rule, you must add a rule in each peered VPC's network ACL to explicitly allow traffic between the peered subnets.
 - The following products can be attached to a Private Network, but do not currently support [VPC routing](/vpc/reference-content/understanding-routing/), and are not compatible with [VPC Peering](/vpc-peering/reference-content/understanding-vpc-peering/):
     - Clusters for Apache Kafka®

@@ -7,10 +7,6 @@ dates:
   posted: 2026-02-10
 ---
 
-<Message type="note">
-VPC Peering is currently in Public Beta.
-</Message>
-
 You may create a peering connector, and then see that it has a status of `Conflict`. This page explains that status, and gives you tips on resolving the issue so your connector can move to a status of `Peered`.
 
 ## Understanding conflict status

@@ -7,7 +7,7 @@ dates:
   posted: 2023-02-06
 ---
 import RegionAndAz from '@macros/console/region-and-az.mdx'
-
+import IngressRoutingRuleConcept from '@macros/vpc/ingress-routing-rule-concept.mdx'
 import image from './assets/scaleway-vpc-pn-diag.webp'
 import image2 from './assets/scaleway-vpc-osi.webp'
 
@@ -63,6 +63,10 @@ The **D**omain **N**ame **S**ystem (DNS) is a naming system for devices connecte
 
 Scaleway Private Networks benefit from managed DNS, which resolves the hostnames of attached resources into their IP addresses. The hostname for a given device is generally the name defined when creating the resource (and which in the case of an Instance, for example, displays in the shell when connected to that resource by SSH). See [full information](/vpc/reference-content/dns/) on Scaleway DNS and how to reach a resource via its hostname.
 
+## Ingress routing rule
+
+<IngressRoutingRuleConcept />
+
 ## IPAM
 
 **IP** **A**ddress **M**anager (IPAM) is Scaleway's tool for planning, tracking and managing the IP address space of Scaleway products. It acts as a single source of truth for the IP addresses of Scaleway resources. See our [dedicated IPAM documentation](/ipam/) for full information.