Creacion de un ciclo de vida del dato en S3

Subir archivos a S3 es facil, de hecho, demasiado. De forma que es importante controlar el ciclo de vida del dato almacenado, así como el uso que se le da al mismo. Cabe la posibilidad que los datos que subas a S3 son para consultas esporádica, o ni siquiera...quizá algunos datos que almacenas en este entorno solo son por seguridad, y la idea es no tener que recurrir a ellos. Entonces, ¿por qué tenerlos en S3 sin mas, cuando podriamos tenerlos en S3 IA (acceso infrecuente) o directamente en Glacier, con la consecuente reduccion de costes? Incluso pasado cierto tiempo, puede no ser necesario conservar esos datos, y podriamos eliminarlos.

Todo esto podemos gestionarlo con un lifecycle en S3. Para ello, vamos al bucket que queremos gestionar y entramos en él. Veremos 4 pestañas principales: Overview, Properties, Permissions y Management. Bien, pinchamos sobre esta última.

Hay una gran cantidad de opciones, como configurar métricas de uso, análisis, inventario, replicacion de archivos o de buckets, y la que nos interesa, Lifecycle.

Como en la creacion del cubo en S3, pinchamos o en el botón "add lifecycle rule" o bien en "get started", que ambos iniciarán el mismo asistente.

Este es el paso fácil: nombre de la regla y tag para ayudarnos en funciones como inventariado y métricas, a futuro. Importante, en el tag no incluyas el nombre del bucket.

Esta ventana es más complicada, aunque se vea simple. Me explico: aqui debes indicar a qué se va a aplicar la regla de ciclo de vida, así como si debe moverse el archivo a S3 IA o a Glacier.

Puedes no marcar nada, pero esta ventana te permite definir si solo vas a aplicar la regla al objeto actual, o si se debe aplicar tambien, o solo a, versiones previas del archivo almacenado. Y para esto, logicamente, debes haber activado la opción de versionado de archivo. Si no, solo podras realizar transiciones para "current versions". En mi caso, ademas, los archivos van a ir directos a Glacier (transition to Amazon Glacier after), ya que no se van a tocar normalmente, y me interesa reducir costes de almacenamiento (serán archivos pesados). El tiempo mínimo para mover los archivos a Glacier es de 1 dia. No se pueden archivar inmediatamente en Glacier, deben pasar siempre antes por S3.

Importante: S3 no deduplica datos, de forma que el versionado aumenta geométricamente el volumen de datos almacenados, asi que si los archivos a guardar son muy pesados, el versionado no es muy recomendable.

Pulsamos next, y llegamos a la pantalla que ves arriba. Bueno, ya he ido marcando varias opciones.
En Configure expiration, puedes indicar si es solo para la version d archivo actual, o para versiones previas (y volvemos a la importancia del versionado).
Expire current version of object es la fecha en la que el archivo será borrado de AWS. Por si acaso, también marco la opcion "clean up incomplete multipart uploads, por si se ha quedado algun archivo a medio subir, y durante el espacio de tiempo indicado no ha terminado su tarea. En este caso, he puesto 7 dias.

La ultima pantalla es un simple repaso de la regla que vamos a programar. Con esto, queda la regla programada y aplicada a todo el bucket. De todas formas, la regla puede ser editada, borrada, o puedes agregar sobre el mismo bucket otras reglas.

¿Facil, verdad? Pues la verdad es que era más fácil en la interfaz de AWS del 2017, donde además se generaba de forma automática en el proceso un gráfico cronológico del proceso que configurabas, haciendo la tarea más visual. Pero supongo que la idea de Amazon es unificar criterios de diseño entre las distintas herramientas. De hecho, si buscas informacion en Youtube, por ejemplo, y no ves imágenes como las mostradas aquí, seguramente sea un video antiguo y no muy útil.