Résumé

  • Dans un compartiment S3 dont le versionnement est activé, une suppression sans identifiant de version crée un marqueur ; les versions de données ne sont pas définitivement effacées et les versions non courantes restent soumises aux tarifs habituels.
  • Le nettoyage d’un marqueur expiré et l’expiration des données non courantes sont deux opérations distinctes. Les conditions d’âge, de nombre et de protection peuvent maintenir une version.
  • AWS ne facture pas le délai de stockage associé à un objet véritablement expiré en attente de retrait asynchrone. Ce cas ne doit pas être confondu avec des données simplement devenues invisibles.

Une clôture pour l’utilisateur, pas encore pour le budget

La documentation de suppression des versions donne à une suppression ordinaire un sens précis. Lorsque le versionnement est activé et que la demande ne vise pas une version déterminée, S3 ajoute un marqueur de suppression au lieu d’effacer définitivement les versions de données.

Le marqueur devient courant. Une lecture sans identifiant de version obtient alors une réponse 404, et les listes ordinaires ne présentent plus la clé correspondante, explique la page consacrée aux marqueurs. L’application constate bien une disparition dans son mode de consultation habituel. Elle n’a pas pour autant établi un inventaire de ce que le stockage conserve.

Deux équipes peuvent donc annoncer des résultats différents sans que l’une mente. L’équipe applicative a retiré l’objet de l’usage ordinaire ; l’équipe de stockage garde une histoire. Le désaccord apparaît lorsque le premier résultat est transmis au budget comme preuve du second. Il ne s’agit pas ici d’une facture client examinée, ni d’un frais caché découvert, mais d’une différence de sens publiée par le fournisseur.

L’histoire conservée peut être le service recherché

AWS indique que les tarifs habituels s’appliquent aux versions stockées et transférées, y compris aux versions non courantes. Leur statut ne les retire pas automatiquement de l’unité facturable. Une baisse du nombre de clés visibles n’autorise donc pas à conclure à une baisse équivalente des octets conservés.

Le marqueur lui-même n’a pas de données associées. Son stockage correspond à la taille du nom de clé encodé en UTF-8, dans S3 Standard. Son empreinte modeste ne doit pas être confondue avec celle des données anciennes qu’il masque à une consultation ordinaire. Une revue qui ne traite que le résidu du marqueur peut laisser intact le véritable sujet budgétaire.

Il n’en résulte pas que chaque version ancienne soit inutile. Une suppression ou un écrasement accidentel peut rendre cette histoire précieuse. La bonne question commerciale porte sur la justification de la conservation : quelle possibilité de reprise veut-on encore acheter, pour qui, et pendant combien de temps ? Rien dans cette recherche ne mesure la valeur de cette option chez un client.

Le mot « expiré » arrive après les données

Le guide de gestion des marqueurs appelle marqueur de suppression expiré le marqueur unique qui demeure lorsque toutes les versions de l’objet ont été supprimées. Le nettoyage de ce dernier résidu ne réalise pas la suppression des anciennes données : la définition suppose qu’elles ont déjà disparu.

Une nouvelle suppression ordinaire ne corrige pas nécessairement la situation. Si un marqueur est déjà courant, une demande sans son identifiant ajoute un autre marqueur. À l’inverse, enlever le marqueur courant peut rendre de nouveau courante une version antérieure et restaurer sa visibilité. Ce sont des changements d’état différents, pas trois façons équivalentes de prouver la fin du stockage.

Cet article ne donne pas de procédure de suppression et n’exécute aucune demande. Il invite à préciser la signification d’un compte rendu : parle-t-on de clés devenues invisibles, de marqueurs retirés, ou de données définitivement supprimées ? Un intitulé « objets supprimés » ne tranche pas ces possibilités.

Une règle de durée peut garder un second seuil

Le guide d’expiration sépare l’expiration de la version courante de celle des versions non courantes. Dans un compartiment activé, la première peut créer un marqueur et transformer les données courantes en données non courantes ; elle n’expire pas pour autant toutes les autres versions.

Les éléments de configuration du cycle de vie distinguent aussi deux conditions lorsque toutes deux sont configurées : l’âge depuis le passage à l’état non courant et le nombre de versions non courantes plus récentes. Les deux seuils doivent être dépassés. Une promesse résumée à un nombre de jours peut donc omettre une conservation par nombre volontairement prévue.

L’âge de non-courant n’est pas l’âge depuis la création initiale. Et l’expiration permanente d’une version non courante est irréversible par ce mécanisme. La validation d’une règle engage la capacité de reprise aussi bien que le coût ; elle ne peut se réduire à demander que toute trace ancienne soit éliminée le plus vite possible.

La documentation Object Lock ajoute une autre limite. Le cycle de vie peut encore placer des marqueurs et changer de classe de stockage, mais sa politique d’expiration ne supprime pas une version protégée. Les marqueurs ne sont pas eux-mêmes protégés en écriture unique. Un objet peut donc sembler absent alors que sa version est volontairement préservée. Ce n’est une preuve ni d’effacement de cette version, ni d’échec de sa protection.

Il faut reconnaître les cas qui ne sont plus facturés

Le raisonnement sur les versions conservées a une limite importante. AWS explique qu’un objet ayant véritablement expiré peut attendre son retrait physique asynchrone, sans facturation de l’expiration ni du temps de stockage associé à cet objet expiré. Un délai de retrait n’est donc pas, à lui seul, la démonstration d’une fuite budgétaire.

Il serait tout aussi erroné d’étendre cette exception à chaque version ancienne derrière un marqueur. Il faut connaître ses conditions d’éligibilité. Le guide cite également des états de réplication en attente ou en échec qui empêchent l’action concernée du cycle de vie. Aucun état réel de compartiment n’a été examiné ici.

La tarification S3 distingue encore l’engagement minimal de certaines classes : 30 jours pour Standard-IA et One Zone-IA, 90 pour Glacier Instant Retrieval et Flexible Retrieval, 180 pour Deep Archive. Une suppression, un écrasement ou une transition anticipés peuvent entraîner une charge au prorata de la durée minimale restante. Ce n’est pas un minimum universel de 30 jours pour S3 Standard.

Les demandes DELETE et CANCEL sont gratuites selon cette même page. La gratuité d’une demande ne rend pas gratuites les versions toujours stockées ou les durées minimales applicables. L’article ne calcule aucun tarif régional, montant client ou économie obtenue.

Mesurer des états plutôt qu’une absence

Le glossaire Storage Lens sépare les octets de versions non courantes des octets de marqueurs. Le compte des objets courants inclut des marqueurs courants ; « courant » ne signifie donc pas nécessairement « fichier accessible ». Les indicateurs gratuits sont collectés quotidiennement, non à chaque événement.

Storage Lens exclut aussi les objets expirés encore présents en attente de retrait. Sa frontière de mesure n’est pas celle d’un inventaire physique instantané. Il sert à structurer les questions, sans devenir par interprétation une facture ou une expertise en temps réel.

Le résultat utile pour l’acheteur est une explication des versions encore conservées : reprise souhaitée, protection, conditions non atteintes, expiration véritable. La réponse 404 décrit autre chose. Le versionnement a précisément de la valeur parce que l’absence peut rester réversible. Cette valeur rend l’absence insuffisante comme preuve de fin d’engagement économique.

Sources