Résumé

  • Le mode conformité de Vault Lock impose une protection que même root ne peut retirer après le délai de grâce. AWS prévoit néanmoins la suppression du contenu après 90 jours de clôture du compte sans réouverture.
  • La retraite d’un produit doit attribuer un avenir à ses archives : un compte maintenu, un responsable identifiable et une restauration vérifiée dans le lieu qui les conservera.

Une fermeture peut en cacher une autre

Le responsable sécurité a acheté une contrainte : personne ne pourra vider le coffre à la première envie d’alléger la facture. Le responsable de la rationalisation reçoit une consigne tout aussi nette : ce produit est mort, il faut fermer son compte. Chacun travaille sérieusement. Leur entreprise risque de réussir deux objectifs incompatibles.

La documentation de Vault Lock expose la jonction entre ces décisions. Après la clôture d’un compte contenant un coffre de sauvegarde, AWS conserve les sauvegardes intactes pendant la suspension de 90 jours. Si le compte n’est pas rouvert durant cette période, son contenu est supprimé, verrou compris dans la situation décrite.

Le verrou règle le pouvoir d’effacer des éléments à l’intérieur du compte. La clôture règle la poursuite de leur hébergement. Une présentation commerciale réduite au mot « immuable » laisse une partie du contrat dans le couloir.

La contrainte mérite son prix

En mode gouvernance, les autorisations appropriées permettent de modifier la protection. En mode conformité, passé le délai de grâce, le verrou ne peut être changé ou retiré tant que le coffre contient des points de restauration, y compris par root ou AWS. La restriction volontaire a donc une substance.

Elle peut protéger l’entreprise contre une opération destructive menée avec des pouvoirs élevés. Elle permet aussi à une décision de conservation de tenir face au prochain administrateur pressé. Offrir à ce dernier une dérogation commode diminuerait précisément la valeur recherchée.

Reste à donner à cette contrainte un domicile durable. Un produit lancé pour une saison peut laisser des pièces utiles bien après sa disparition. Le calendrier du produit et celui des pièces doivent alors être administrés séparément. Le coffre hérite du sort du compte qui le porte, même si l’organigramme a déjà oublié ce compte.

Le délai n’est pas une salle de lecture

Les règles de clôture précisent que la fermeture vaut notification de résiliation de l’accord client pour ce compte. Pendant la période de 90 jours, l’accès au contenu et aux services exige une réouverture. À son terme, la fermeture permanente empêche de rouvrir le compte et de réutiliser son identifiant.

Une sauvegarde peut donc être intacte sans être disponible pour le travail du jour. Pour un directeur qui doit retrouver l’historique d’une transaction, la distinction a un coût très concret : il doit d’abord rétablir le contenant administratif.

Imaginons une division arrêtée, ses employés réaffectés et son budget soldé. L’équipe chargée de la fermeture gagne à terminer vite ; celle qui devra répondre à une question sur une vieille commande n’a peut-être même pas été invitée. Le risque naît de cette absence, avant le moindre incident technique. Les documents publics ne fournissent ni inventaire de comptes clients ni résultats de restauration permettant de chiffrer une exposition particulière.

Le retour a ses conditions

La procédure actuelle de réouverture autorise une démarche en libre-service pour un compte fermé par son client, sans solde impayé au moment de la fermeture. Elle exige l’identité root et une demande pendant les 90 jours, ainsi qu’un moyen de paiement valide. Une identité IAM ordinaire ne remplace pas root.

Pour un compte fermé par AWS, la documentation prévoit le règlement du solde sous 30 jours après la fermeture, puis le recours au support. Le délai de conservation ne remplace donc ni l’identité autorisée ni le traitement de la situation financière.

Même après réouverture, certaines ressources demandent une action : redémarrer des instances EC2 arrêtées, par exemple, ou restaurer des bases RDS depuis les instantanés créés à la clôture. Le retour du compte ouvre le chantier de remise en service.

La page sur la clôture décrit aussi un piège d’organisation : une adresse root utilisant un domaine Route 53 hébergé dans ce même compte peut perdre sa messagerie lorsque le domaine est suspendu. Le canal de récupération dépend alors de l’objet à récupérer. Voilà une économie de moyens qui fabrique un cercle parfait, et parfaitement inutile.

Deux comptes, une responsabilité à établir

La copie entre comptes AWS Backup permet de placer une copie dans un compte destinataire, puis d’y restaurer les données. Cette voie exige notamment l’appartenance à la même organisation AWS Organizations, des ressources et régions prises en charge, les autorisations adaptées et les clés nécessaires. Les copies entre comptes vers les classes de stockage froid ne sont pas prises en charge.

Le destinataire reçoit une copie rechiffrée avec la clé de son coffre. Une permission de consulter l’original reste une dépendance à l’original. Pour organiser une succession, il faut une copie achevée et une restauration dont le résultat a été contrôlé.

Deux comptes soumis à la même direction peuvent encore être fermés par la même campagne de nettoyage. L’intérêt du compte d’archives vient donc de son mandat : conserver des éléments définis jusqu’à une échéance choisie, avec un financement et un responsable. La multiplication des comptes ne produit pas, à elle seule, cette décision.

Une entreprise peut détruire une histoire devenue inutile. Elle peut aussi payer pour préserver une histoire qui continue de servir. Elle devrait prendre cette décision avant que la fermeture d’un produit la prenne à sa place.