fix(3AZ ref archietcture): update array

Author: OvhValentin

pages/public_cloud/compute/3az_ref_architecture/guide.en-gb.md

@@ -35,7 +35,7 @@ The table below lists the services offered, their scope (zonal or regional), and
 | 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). |
+| 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. |
 | 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. |

pages/public_cloud/compute/3az_ref_architecture/guide.fr-fr.md

@@ -35,7 +35,7 @@ Le tableau ci-dessous liste les services proposés, leur périmètre (zonal ou r
 | 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). |
+| 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. |
 | 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. |