fix(lb): clarify backend server rules

Author: RoRoJ

macros/network/lb-create-backend-2-traffic-mgnt.mdx

@@ -11,7 +11,7 @@ Traffic management configuration lets you define how your Load Balancer's backen
         * **Least connections**: Requests are forwarded to the backend server with the fewest current connections. 
         * **First available**: Requests are forwarded to the first backend server with available connection slots.
 
-2. Add the **Server IP addresses** of the servers the Load Balancer will forward requests/connections to. These will be your backend servers. 
+2. Add the **Server IP addresses** of the servers the Load Balancer will forward requests/connections to. These will be your backend servers. They must be Scaleway resources (Instances, Elastic Metal or Dedibox servers) unless you have a [Multi-Cloud](/load-balancer/faq/#what-is-the-difference-between-multi-cloud-and-non-multi-cloud-offers) Load Balancer, in which case this restriction does not apply. Scaleway backend servers can be in any AZ, and are not restricted to the same AZ as the Load Balancer.
 
         <Message type="note">
         If you want your Load Balancer to communicate with its backend servers over an attached [Private Network](/vpc/concepts/#private-networks), ensure that you enter the servers' private IP addresses. This is necessary in the case of a [private Load Balancer](/load-balancer/reference-content/public-private-accessibility/#private-load-balancers), but may also be desired for public Load Balancers attached to Private Networks where backend servers are in the same VPC. As Load Balancers are compatible with [VPC routing](/vpc/reference-content/understanding-routing/), they will be able to direct requests to any backend server within the same VPC, via its private IP address. The Load Balancer and backend server do not have to be on the same Private Network in that VPC.

pages/load-balancer/concepts.mdx

@@ -35,6 +35,8 @@ Each Load Balancer is configured with one or several backends. A backend represe
 
 The term "backend server" designates the final-destination backend servers which the Load Balancer forwards traffic on to. Each of the Load Balancer's [backends](#backends) must specify one or more backend servers (via their IP addresses) to forward to.
 
+Backend servers must be Scaleway resources (Instances, Elastic Metal or Dedibox servers) unless you have a [Multi-Cloud](/load-balancer/faq/#what-is-the-difference-between-multi-cloud-and-non-multi-cloud-offers) Load Balancer, in which case this restriction does not apply. Scaleway backend servers can be in any AZ, and are not restricted to the same AZ as the Load Balancer.
+
 ## Backend protection
 
 Backend protection is a set of configurable values that allow you to control how load is distributed to backend servers. You can use these settings to configure the **maximum number of simultaneous requests** to a given backend server before it is considered to be at maximum capacity. You can also configure a **queue timeout** value, which defines the maximum amount of time (in ms) to queue a request or connection for a particular backend server when [stickiness](#sticky-session) is enabled. Once this value is reached, the request/connection will be directed to a different backend server.

pages/load-balancer/reference-content/configuring-backends.mdx

@@ -101,6 +101,8 @@ Load Balancers support three different modes of balancing load (requests) betwee
 
 You can add one or more IP addresses, either IPv4 or IPv6, of the backend servers your Load Balancer's backend will forward traffic to.
 
+Backend servers must be Scaleway resources (Instances, Elastic Metal or Dedibox servers) unless you have a [Multi-Cloud](/load-balancer/faq/#what-is-the-difference-between-multi-cloud-and-non-multi-cloud-offers) Load Balancer, in which case this restriction does not apply. Scaleway backend servers can be in any AZ, and are not restricted to the same AZ as the Load Balancer.
+
 ### Sticky sessions
 
 When activated, sticky sessions bind a user's session to a specific server in the pool of backend servers. This ensures that all subsequent sessions from the user are sent to the same backend server while there is at least one active session. Sticky sessions can be **cookie-based** or **IP-based** (aka table-based).