diff --git a/pages/public_cloud/compute/create_and_configure_an_additional_disk_on_an_instance/guide.en-gb.md b/pages/public_cloud/compute/create_and_configure_an_additional_disk_on_an_instance/guide.en-gb.md
index d956a09a40f..e5fbdba3083 100644
--- a/pages/public_cloud/compute/create_and_configure_an_additional_disk_on_an_instance/guide.en-gb.md
+++ b/pages/public_cloud/compute/create_and_configure_an_additional_disk_on_an_instance/guide.en-gb.md
@@ -55,6 +55,8 @@ The Classic volume is a reliable, cost-effective storage solution, ideal for wor
 - Storage of small to medium-sized databases
 - Data backup and archiving
 
+In 3AZ regions, Classic Volumes are regional services that use distributed erasure coding across multiple Availability Zones. This ensures data remains available without impact or downtime in the event of an AZ failure, provided the multi-attached resilient architecture conditions are met (cf: [This guide](/pages/compute/classic_block_multi_az_limitations)).
+
 ///
 
 /// details | **High-Speed – Up to 3000 IOPS**
diff --git a/pages/public_cloud/compute/create_and_configure_an_additional_disk_on_an_instance/guide.fr-fr.md b/pages/public_cloud/compute/create_and_configure_an_additional_disk_on_an_instance/guide.fr-fr.md
index 8bce911cdb2..6ae79d1f642 100644
--- a/pages/public_cloud/compute/create_and_configure_an_additional_disk_on_an_instance/guide.fr-fr.md
+++ b/pages/public_cloud/compute/create_and_configure_an_additional_disk_on_an_instance/guide.fr-fr.md
@@ -55,6 +55,8 @@ Le volume Classic est une solution de stockage fiable et économique, idéale po
 - Stockage de bases de données de petite à moyenne taille
 - Sauvegarde et archivage de données
 
+Dans les régions 3AZ, les volumes Classic sont des services régionaux qui utilisent un Erasure Coding distribué entre plusieurs zones de disponibilité. Cela garantit la disponibilité des données sans impact ni interruption en cas de défaillance d’une zone, à condition que les exigences de l’architecture résiliente avec attachement multiple soient respectées (cf: [Ce guide](/pages/compute/classic_block_multi_az_limitations)).
+
 ///
 
 /// details | **High-Speed – Jusqu’à 3000 IOPS**
diff --git a/pages/public_cloud/public_cloud_cross_functional/3az_ref_architecture/guide.en-gb.md b/pages/public_cloud/public_cloud_cross_functional/3az_ref_architecture/guide.en-gb.md
index f47527d5b52..ee04e5ecce3 100644
--- a/pages/public_cloud/public_cloud_cross_functional/3az_ref_architecture/guide.en-gb.md
+++ b/pages/public_cloud/public_cloud_cross_functional/3az_ref_architecture/guide.en-gb.md
@@ -1,7 +1,7 @@
 ---
 title: "3-AZ resilience: Mechanisms and reference architectures"
 excerpt: "Understand 3-AZ resilience mechanisms and explore OVHcloud reference architectures"
-updated: 2025-03-21
+updated: 2025-04-24
 ---
 
 <style>
@@ -30,14 +30,14 @@ The table below lists the services offered, their scope (zonal or regional), and
 
 | Service | Zonal/Local | Regional | Architecture/Configuration Best Practices      | In case of AZ failure                                                              |
 | ------- | ----------- | -------- | ---------------------------------------------- | ------------------------------------------------------------------------------------ |
-| Instances | <center>X</center> | | As instances are zonal services, they are only deployed in a single availability zone. To ensure resilience, customers must manually distribute their instances over several availability zones. Depending on your architecture and services, a regional load balancer may be the solution. For example, an active/passive clustered database distributed over two AZs can automatically switch from one instance to the other without a Load Balancer. | In the event of failure of one AZ, with resilience mechanisms, service continuity is ensured by your instances in the other AZs. |
+| Instances | <center>X</center> | | As instances are zonal services, they are only deployed in a single availability zone. To ensure resilience, customers must manually distribute their instances over several availability zones. Depending on your application, use case and services, a regional load balancer and a multi attached classic block volume may be the recommended architecture to leverage on resilience. For example, an active/passive clustered database distributed over two AZs can automatically switch from one instance to the other without a Load Balancer. | In the event of failure of one AZ, with resilience mechanisms, service continuity is ensured by your instances in the other AZs. |
 | Private Network | | <center>X</center> | | DHCP/DNS agents operate in two AZs. If one AZ fails, they will be automatically reactivated in the AZ where they are not already running. |
 | Public Cloud Load Balancer ( Octavia ) | | <center>X</center> | The regional Load Balancer consists of an active Load Balancer and a passive Load Balancer, each deployed in a separate AZ. | The service will remain available without interruption. In the event of failure of an AZ containing a Load Balancer node, the latter will automatically be moved to the last AZ. |
 | Gateway | | <center>X</center> | The regional gateway consists of an active and a passive gateway, each deployed in a separate AZ. If an AZ containing a Gateway node fails, it will not be recreated in another AZ. | The service will remain available without interruption. |
 | Floating IP | | <center>X</center> | The customer can attach a multi-AZ Floating IP to any instance or Load Balancer in any AZ. | The service will remain available without interruption. |
 | Object Storage ( Standard class ) | | <center>X</center> | Object Storage is a regional service offering advanced data protection options, including integrated off-site replication via the Control Panel and S3-compatible asynchronous replication via the API for custom configuration. | No impact on Object Storage service or data. Data remains available for read and write operations, even in the event of an AZ failure. This configuration is ideal for high-availability, fault-tolerant applications. Once the AZ is restored, chunks are moved to the affected AZ. Learn more [here](/pages/storage_and_backup/object_storage/s3_regions_comparison). |
 | Block storage High Speed | <center>X</center> | | HighSpeed is a zonal service with triple replication within a single AZ. To ensure resilience, customers must manually deploy HighSpeed Block Storage on several AZs to ensure service continuity. The use of volume backups (local or distant) can also be interesting in some use cases to restore local block storage. | In the event of a major outage, as the service is zonal, customers could lose their data and will have to recreate their Block volume (from backups for example) when the AZ is restored. |
-| Block storage Classic Multi-Zone | | <center>X</center> | Block Storage Classic is a regional service using distributed erasure coding across several AZs. Off-site replication is recommended to protect against regional failure. | Block Storage data will remain available without impact or downtime. In the event of a major incident, chunks will be recreated as soon as the AZ is restored. |
+| Block storage Classic Multi-Zone | | <center>X</center> | Block Storage Classic is a regional service using distributed erasure coding across several AZs. Off-site replication is recommended to protect against regional failure. | Block Storage data remains available without impact or downtime, provided the conditions of the multi-attached resilient architecture are met. (cf: [This guide](/pages/compute/classic_block_multi_az_limitations)). In the event of a major incident, chunks will be recreated as soon as the AZ is restored. |
 | Managed Kubernetes Service | | <center>X</center> <br> <center>(Coming soon)</center> | With the Managed Kubernetes on 3-AZ regions, the Control Plane is distributed over 3 AZs. The customer must deploy worker nodes on several AZs and use Multi-Zone/Regional Block Storage for persistent volumes. | In the event of an AZ failure, the Control Plane remains available and the customer's workload is rescheduled on the nodes on another available AZ. <br> Note that workloads using persistent volumes of single-zone classes cannot be migrated to other AZs. When the AZ is restored, the Control Plane will become available again in the AZ and the unmigrated workload will resume. |
 | DBaaS | | <center>X</center> <br> <center>(Coming soon)</center> | Database nodes are distributed across several nodes in different AZs. Backup is useful in the event of regional failure or for a single-node database. | In the event of an AZ failure, databases and data will remain available. The Production and Advanced offerings include at least two nodes, ensuring no service interruption. Backups are automatically managed by our services and stored off-site. Learn more [here](/pages/public_cloud/public_cloud_databases/databases_05_automated_backups). |
 <!-- | Private Registry | | <center>X</center> | Based on S3, with a Control Plane distributed over several geographical zones. Off-site replication is recommended in the event of regional failure. | In the event of AZ failure, the registry remains available. <br> On the basis of S3 3-AZ/regional storage, the data will remain available without impact. <br> The chunks will be recreated once the AZ is operational again. | -->
@@ -77,7 +77,7 @@ This diagram illustrates an application deployed across two availability zones (
 - The 2 AZs are in the same Private Network.
 - Instance 1 runs on AZ-a and Instance 2 on AZ-b.
 - An active Load Balancer distributes traffic on the AZ-a, with a passive Load Balancer waiting on the AZ-b.
-- The Block Storage service is regional, shared between the AZs.
+- The Block Storage service is regional, shared between the AZs and simultaneously attached to both Instance 1 on AZ-a and Instance 2 on AZ-b (cf: [This guide](/pages/compute/classic_block_multi_az_limitations))
 - Connectivity is provided by a Floating IP and a Gateway (including a second one available in case of failure).
 
 **AZ-a Incident** (Right Side):
diff --git a/pages/public_cloud/public_cloud_cross_functional/3az_ref_architecture/guide.fr-fr.md b/pages/public_cloud/public_cloud_cross_functional/3az_ref_architecture/guide.fr-fr.md
index 0fe557273a3..a2e9e29e775 100644
--- a/pages/public_cloud/public_cloud_cross_functional/3az_ref_architecture/guide.fr-fr.md
+++ b/pages/public_cloud/public_cloud_cross_functional/3az_ref_architecture/guide.fr-fr.md
@@ -1,7 +1,7 @@
 ---
 title: "Résilience 3-AZ : Mécanismes et architectures de référence"
 excerpt: "Comprenez les mécanismes de résilience 3-AZ et explorez les architectures de référence OVHcloud"
-updated: 2025-03-21
+updated: 2025-04-24
 ---
 
 <style>
@@ -30,14 +30,14 @@ Le tableau ci-dessous liste les services proposés, leur périmètre (zonal ou r
 
 | Service | Zonal/Local | Régional | Architecture/Bonnes pratiques de configuration | En cas de panne de l'AZ                                                              |
 | ------- | ----------- | -------- | ---------------------------------------------- | ------------------------------------------------------------------------------------ |
-| Instances | <center>X</center> | | Les instances étant des services zonaux, elles ne sont déployées que dans une seule zone de disponibilité. Pour assurer la résilience, les clients doivent répartir manuellement leurs instances sur plusieurs Availability Zones. La mise en place d'un Load Balancer régional peut être une solution, selon votre architecture et vos services. Par exemple, une base de données en cluster actif/passif répartie sur deux AZ peut basculer automatiquement d'une instance à l'autre sans Load Balancer. | En cas de défaillance d'une AZ, avec des mécanismes de résilience, la continuité de service est assuré par vos instances dans les autres AZ. |
+| Instances | <center>X</center> | | Comme les instances sont des services zonaux, elles ne sont déployées que dans une seule zone de disponibilité. Pour garantir la résilience, il revient donc au client de répartir manuellement ses instances sur plusieurs zones. Selon votre application, votre cas d’usage et les services impliqués, une architecture combinant un équilibreur de charge régional et un volume Block Storage classique en mode multi-attach peut être recommandée pour maximiser la résilience. Par exemple, une base de données en cluster actif/passif répartie sur deux zones peut basculer automatiquement d’une instance à l’autre, même sans Load Balancer. | En cas de défaillance d'une AZ, avec des mécanismes de résilience, la continuité de service est assuré par vos instances dans les autres AZ. |
 | Private Network | | <center>X</center> | | Les agents DHCP/DNS fonctionnent dans deux AZ. En cas de défaillance d'une AZ, ils seront automatiquement réactivés dans l'AZ où ils ne sont pas déjà en cours d'exécution. |
 | Public Cloud Load Balancer ( Octavia ) | | <center>X</center> | Le Load Balancer régional se compose d'un Load Balancer actif et d'un Load Balancer passif, chacun étant déployé dans une AZ distincte. | Le service restera disponible sans interruption. En cas de défaillance d'une AZ contenant un nœud de Load Balancer, celui-ci sera automatiquement déplacé vers la dernière AZ. |
 | Gateway | | <center>X</center> | La Gateway régionale se compose d'une Gateway active et d'une Gateway passive, chacune étant déployée dans une AZ distincte.| Le service restera disponible sans interruption. |
 | Floating Ip | | <center>X</center> | Le client peut attacher une Floating IP multi-AZ à n'importe quelle instance ou à n'importe quel Load Balancer dans n'importe quelle AZ. | Le service restera disponible sans interruption. |
 | Object Storage ( Standard class ) | | <center>X</center> | L’Object Storage est un service régional offrant des options avancées de protection des données, dont la réplication hors site intégrée via l'espace client et la réplication asynchrone compatible S3 via l’API pour une configuration personnalisée. | Aucun impact sur le service Object Storage ni sur les données. Les données restent disponibles pour les opérations de lecture et d'écriture, même en cas de défaillance d'une AZ. Cette configuration est idéale pour les applications à haute disponibilité et tolérance de pannes. Une fois l'AZ rétablie, les blocs sont déplacés vers l'AZ affectée. Pour en savoir plus, [cliquez ici](/pages/storage_and_backup/object_storage/s3_regions_comparison). |
 | Block storage High Speed | <center>X</center> | | L'offre HighSpeed est un service zonal avec une triple réplication au sein d'une seule zone de stockage. Pour assurer la résilience, les clients doivent déployer manuellement leur service Block Storage HighSpeed sur plusieurs AZ pour assurer la continuité du service. L'utilisation de backup de volume (locaux ou distants) peut également être intéressante dans certains cas d'utilisation pour restaurer un service block storage local. | En cas de panne majeure, le service étant zonal, les clients peuvent perdre leurs données et devront recréer leur volume Block (à partir de backup par exemple) lorsque l'AZ sera rétabli. |
-| Block storage Classic Multi-Zone | | <center>X</center> | Le Block Storage Classic est un service régional utilisant le codage par effacement réparti sur plusieurs AZ. Une réplication hors site est recommandée pour se prémunir contre une défaillance régionale. | Les données du Block Storage resteront disponibles sans impact ni temps d'arrêt. En cas d'incident majeur, les chunks seront recréés dès que l'AZ sera rétablie. |
+| Block storage Classic Multi-Zone | | <center>X</center> | Le Block Storage Classic est un service régional utilisant le codage par effacement réparti sur plusieurs AZ. Une réplication hors site est recommandée pour se prémunir contre une défaillance régionale. | Les données du Block Storage restent disponibles sans impact ni interruption, à condition que les conditions de l’architecture résiliente avec attachement multiple soient respectées (cf. [Ce guide](/pages/compute/classic_block_multi_az_limitations)). En cas d’incident majeur, les fragments de données (chunks) seront recréés dès que la zone de disponibilité concernée est restaurée. |
 | Managed Kubernetes Service | | <center>X</center> <br> <center>(À venir)</center> | Avec les régions Managed Kubernetes en 3-AZ, le Control Plane est réparti sur 3 AZ. Le client doit déployer des worker nodes sur plusieurs AZ et utiliser des Block Storage Multi-Zone/Regionaux pour les volumes persistants. | En cas de défaillance d'une AZ, le Control Plane reste disponible et le workload du client est reprogrammé sur les nœuds d'une autre AZ disponible. <br> Il est à noter que les workloads utilisant des volumes persistants de classes single-zone ne peuvent pas être migrées vers d'autres AZ. Lorsque l'AZ est restaurée, le Control Plane redevient disponible dans l'AZ et le workload non migré reprend. |
 | DBaaS | | <center>X</center> <br> <center>(À venir)</center> | Les nœuds de base de données sont répartis sur plusieurs nœuds dans différentes AZ. Le backup est utile en cas de défaillance régionale ou pour une base de données à un seul nœud. | En cas de défaillance de l'AZ, les bases de données et les données restent disponibles. Les offres Production et Advanced comprennent au moins deux nœuds, ce qui garantit l'absence d'interruption de service. Les backups sont automatiquement gérés par nos services et stockés hors site. Pour en savoir plus, [cliquez ici](/pages/public_cloud/public_cloud_databases/databases_05_automated_backups). |
 <!-- | Private Registry | | <center>X</center> | Based on S3, with a control plane distributed over several geographical zones. Off-site replication is recommended in the event of regional failure. | In the event of AZ failure, the registry remains available. <br> On the basis of S3 3-AZ/regional storage, the data will remain available without impact. <br> The chunks will be recreated once the AZ is operational again. | -->
@@ -77,7 +77,7 @@ Ce schéma illustre une application déployée sur deux Availability Zones (AZ)
 - Les 2 AZ sont dans le même Private Network.
 - L'instance 1 fonctionne sur l’AZ-a et l'instance 2 sur l’AZ-b.
 - Un Load Balancer actif répartit le trafic sur l’AZ-a, avec un Load Balancer passif en attente sur l’AZ-b.
-- Le service Block Storage est régional, partagé entre les AZ.
+- Le service Block Storage est régional, partagé entre les zones de disponibilité, et simultanément attaché à la fois à l’Instance 1 sur AZ-a et à l’Instance 2 sur AZ-b (cf. [Ce guide](/pages/compute/classic_block_multi_az_limitations)).
 - La connectivité est assurée par une Floating IP et une Gateway (dont une seconde disponible en cas de défaillance).
 
 **Incident sur l’AZ-a** (Côté droit) :