Versionado en Los Buckets S3, Ventajas E Implicaciones

Introducción

En el artículo anterior de esta serie hablamos de las reglas de ciclo de vida y la importancia que tienen a la hora de ahorrar costos relacionados a S3 de una forma bastante sencilla operativamente hablando. En este artículo estaremos hablando sobre el versionado en los buckets S3, uno de los puntos clave para poder entender como funcionan los buckets S3 y como podemos aprovecharlos al máximo.

Comportamiento de los buckets S3 sin versionado

Por defecto cuando creamos un bucket S3, el versionado no está habilitado en el mismo, y esto trae las siguientes consecuencias:

• Supongamos que tenemos un objeto en la raíz de nuestro bucket cuyo nombre es imagen.jpg. En caso que subamos otro objeto con el mismo nombre a la raíz de nuestro bucket, el comportamiento es sobreescribir el objeto anterior precisamente debido a que no tenemos el versionado habilitado

• Si accidentalmente eliminamos un objeto de nuestro bucket, no tenemos forma de revertir esto debido a que el versionado no está habilitado

Porque es una buena práctica versionar nuestros buckets S3?

Una vez que habilitamos el versionado en nuestro bucket S3, los siguientes cambios ocurren:

El versionado se habilita nivel de Bucket

• Si eliminamos un objeto, en vez de eliminarlo permanentemente, S3 inserta un delet marker, que pasa a ser la versión actual del objeto. De esta forma, podemos recuperar la versión anterior.

• Si sobreescribimos un objeto, S3 añade una nueva versión del objeto en el bucket. Las versiones anteriores del objeto permanecen disponibles y por lo tanto podemos recuperarlas en caso que lo deseemos.

Es importante tener en cuenta que a cada versión de un objeto aplican los cargos normales de S3. Por lo tanto si tenemos tres versiones de un objeto, seremos cargados económicamente hablando por tres objetos.

Cuando se habilita el versionado de un bucket S3 por primera vez, puede tomar cierto tiempo en propagar el cambio completamente. Durante este proceso, se pueden obtener errores HTTP 404 para solicitudes de crear o actualizar objetos. AWS recomienda que se esperen 15 minutos luego de habilitar el versionado en un bucket antes de realizar operaciones tipo PUT o DELETE hacia objetos en el bucket.

Buckets con el versionado suspendido

Una vez que tenemos el versionado habilitado en un bucket S3, este no se puede inhabilitar, solo suspender. Cuando esto sucede, los objetos existentes en el bucket no cambian, solo cambia la forma en que el bucket maneja los siguientes objetos. Veamos los distintos casos a tener en cuenta en caso que un bucket tenga el versionado suspendido:

Añadiendo objetos

Cuando añadimos objetos a un bucket S3 con el versionado suspendido, S3 le añade un version ID null a cada objeto añadido. Esto se muestra en la siguiente imagen:

Es importante recalcar que este nuevo objeto reemplaza al anterior si y solo si el version ID del objeto anterior es igualmente null. Veamos una imagen para poder entender mejor:

Luego de entender, llegamos a la conclusión que cuando añadimos objetos a un bucket con versionado suspendido, no se sobreescriben los objetos que estaban almacenados en el mismo antes de suspender el versionado, ya que estos se guardan con un version ID distinto de null, pero los que almacenamos a partir de que está suspendido el versionado, si se sobreescriben, ya que todos tienen como version id null

Obteniendo objetos

Siempre que se obtienen objetos de un bucket S3, este devuelve la versión actual del objeto independientemente del estado del versionado del bucket, por lo tanto, en este caso, no hay diferencias relacionadas al versionado del bucket

Eliminando objetos

Cuando un bucket tiene el versionado suspendido, una solicitud DELETE hará lo siguiente:

• Elimina el objeto solo si tiene un version id igual a null
• En caso que el objeto tenga un version id distinto de null añade un delete marker

Para eliminar permanentemente in objeto con version ID distinto de null, debes incluir el version id en la solicitud.

Buenas prácticas

Para prevenir problemas de rendimiento relacionados al versionado, es recomendable lo siguiente:

• Habilitar una regla de ciclo de vida que expire las versiones anteriores de los objetos. Por ejemplo, una regla de ciclo de vida que que expire las versiones no actuales de un objeto 30 días después de que la versión del objeto no sea la actual.

• Habilitar una regla de ciclo de vida que elimine los delete marker expirados de un objeto.

Hasta la próxima

Esto es todo por ahora relacionado al cuarto artículo de esta serie donde estaré brindándote una guía completa sobre los buckets de S3. En el próximo artículo estaremos hablando sobre las pólizas en los bucket S3. Nos vemos pronto.