Résumé

  • AWS précise que S3 Cross-Region Replication et l’interconnexion inter-régions de Transit Gateway ne franchissent pas la limite entre ses partitions.
  • Une cible dans aws-eusc doit donc être approvisionnée avant l’incident, avec ses propres comptes, identités, certificats, chemins réseau, données récupérables et ressources.
  • Un périmètre de conformité ou une région multizone ne donne ni RTO ni RPO à l’application. Ces objectifs appartiennent à l’acheteur et doivent être éprouvés.

Le faux raccord du plan de reprise

Un plan prévu pour deux régions commerciales repose souvent sur deux continuités silencieuses. Les mêmes identités permettent d’administrer la cible et des services natifs déplacent ou répliquent les données. Dans l’AWS European Sovereign Cloud, aucune des deux ne doit être présumée.

AWS qualifie ses partitions de frontières strictes. Les identifiants d’une autre partition ne fonctionnent pas simplement dans aws-eusc. Surtout, AWS indique que S3 Cross-Region Replication et le peering inter-régions de Transit Gateway ne fonctionnent pas entre partitions. Ce ne sont pas des détails à corriger pendant la crise: ils déterminent l’architecture du transfert bien avant elle.

La séparation est cohérente avec la promesse du produit. AWS présente eusc-de-east-1, sa première région souveraine située dans le Brandebourg, comme une infrastructure physiquement et logiquement distincte, entièrement située dans l’Union européenne, sans dépendance critique à du personnel ou à une infrastructure hors UE, et conçue pour continuer à fonctionner si la connexion avec le reste du monde est interrompue. Des services d’identité, de facturation, de confiance et de DNS lui sont dédiés. Cette autonomie du fournisseur protège une frontière. Elle ne transporte pas l’état opérationnel du client.

Il faut construire une chaîne de reprise différente

Sans réplication S3 interrégions native à travers la partition, la question devient: quel mécanisme copie quelle donnée, selon quelle cohérence, avec quelle autorisation et à quel rythme? Un export périodique peut convenir à une archive, pas à une transaction qui tolère quelques minutes de perte. Un outil externe peut franchir le réseau, mais dépendre d’une identité, d’une clé ou d’un opérateur indisponible dans le scénario retenu.

Sans peering inter-régions de Transit Gateway, la connectivité doit également être explicite. AWS évoque TLS via internet, IPsec VPN ou des montages liés à Direct Connect. Chacune de ces options crée ses propres propriétaires, règles de routage, résolutions DNS, filtrages, certificats et points de défaillance. Une liaison testée un mardi ordinaire n’est pas encore une liaison prouvée quand la partition source, un opérateur ou un plan de contrôle juridique disparaît.

L’identité forme une troisième chaîne. Le compte souverain, l’organisation, les rôles, l’autorité de certification et les politiques doivent être disponibles sans réutiliser le contrôle dont la panne justifie la bascule. Copier une définition d’infrastructure accélère le déploiement; cela ne copie ni les décisions d’accès ni les secrets ni la chaîne de confiance.

Enfin, l’inventaire des services doit être rapproché dépendance par dépendance. AWS publie un ensemble étendu de services ainsi qu’une matrice de capacités. Une présence au catalogue ou dans le périmètre d’assurance ne garantit pas qu’une fonction, une API, un quota, une famille d’instance ou un service managé associé corresponde à la source. La cible doit être dimensionnée, pas seulement ouverte.

La donnée sauvegardée n’est pas le service repris

Une sauvegarde répond à une question de conservation. La reprise répond à une question de service. Pour passer de l’une à l’autre, il faut restaurer dans un compte utilisable, raccorder le réseau, réémettre ou valider les certificats, démarrer les dépendances dans le bon ordre, vérifier l’intégrité et obtenir l’autorisation d’exposer le résultat.

AWS distingue plusieurs modèles: sauvegarde et restauration, pilot light, warm standby et active-active. Ils échangent un coût permanent contre un temps de reprise différent. L’acheteur qui finance une sauvegarde mais annonce un RTO de warm standby crée une dette d’exploitation, pas une garantie.

La responsabilité partagée confirme cette limite. AWS prend en charge la résilience de son infrastructure. Le client configure la résilience de sa charge: déploiement multizone, autoréparation, stratégie de sauvegarde et de réplication, réseau, quotas, observabilité, runbooks et essais. Une plateforme robuste peut héberger une application non récupérable.

Trois preuves séparées

La preuve de souveraineté porte sur la gouvernance, l’exploitation, la résidence des données et l’isolation technique. La preuve de disponibilité porte sur le comportement de l’application dans son environnement courant. La preuve de reprise porte sur le retour mesuré du service après un sinistre nommé. Les agréger revient à utiliser un contrôle fort pour masquer deux contrôles manquants.

AWS définit le RTO comme le délai maximal acceptable avant restauration et le RPO comme l’âge maximal acceptable du dernier point de données récupérable. Ce sont des objectifs fixés par l’organisation. Une attestation ne les mesure pas; l’ouverture d’une région non plus.

Les sources d’AWS ne publient ni l’inventaire d’un acheteur, ni ses quotas, ni son volume de données, ni son résultat d’exercice ou de retour arrière. Elles ne démontrent donc pas qu’une charge réglementée nommée a déjà basculé entre partitions. Elles établissent les contraintes auxquelles une preuve crédible devrait répondre.