Imagen de dennizn en Shutterstock
Hace poco, uno de nuestros clientes se topó con un problema en su bucket de S3 al transferir objetos desde Standard storage hacia Glacier Deep Archive: a pesar de haberlos movido a Glacier Deep Archive, los objetos seguían apareciendo en Standard storage.
Al revisar el bucket de S3 del cliente, confirmé que, efectivamente, el Standard storage no se había reducido desde su tamaño original de 4.9 TB. Esto se aprecia en la siguiente imagen, tomada de la métrica de almacenamiento del bucket.
Métrica de S3 Total Bucket Size
En la métrica de S3 Total Bucket Size se observa que Standard Storage tenía 4.9 TB. La línea naranja representa el Standard storage. El cliente había iniciado la transferencia de objetos a Glacier Deep Archive el 6 de mayo, pero al 10 de mayo la métrica todavía no reflejaba el cambio.
Métrica de S3 para Standard Storage
Al abrir la métrica Total Bucket Size en CloudWatch, noté una diferencia entre las métricas de S3 y las de CloudWatch: la de S3 mostraba 4.9 TB de Standard storage en el bucket, mientras que la de CloudWatch indicaba 5.3 TB.
Métricas de CloudWatch para los buckets por clase de almacenamiento
Desglose de métricas por clase de almacenamiento
Tras el análisis, identifiqué dos problemas en la transición de objetos entre clases de almacenamiento:
(1) La métrica de S3 Standard Storage no se redujo después de mover los objetos a otra clase de almacenamiento.
(2) La métrica de S3 y la de CloudWatch mostraban una diferencia significativa en el total de Standard storage.
Resolviendo los problemas
Al revisar a fondo cómo el cliente había transferido los objetos de Standard a Glacier Deep Archive, descubrí que la operación se hizo manualmente desde la consola de S3. Al abrir el objeto, seleccionaron Action, Edit actions, Edit storage class.
Cambio manual de la clase de almacenamiento del objeto
Cambiar la clase de almacenamiento de un objeto desde la consola crea una copia del objeto y conserva la original como versión anterior (si tienes el versionado habilitado en el bucket).
Cuando editas la clase de almacenamiento de un objeto desde la consola, esta no se modifica: se crea un nuevo archivo en la clase de almacenamiento seleccionada.
Como el bucket tiene el versionado habilitado, ahora existen dos versiones del archivo: una en Glacier Deep Archive (la versión actual) y otra en Standard (la versión no actual). Por eso el tamaño del Standard storage no disminuyó.
Regla de ciclo de vida
Al analizar la diferencia entre las métricas de S3 y CloudWatch para la clase Standard, descubrí que las métricas de S3 que aparecen en la página del bucket solo muestran el tamaño combinado de los archivos actuales, mientras que CloudWatch incluye además los archivos no actuales y las cargas multiparte fallidas.
Como el cliente había editado manualmente la clase de almacenamiento de los objetos, se generó una nueva copia en Glacier Deep Archive como versión actual, y el objeto en Standard storage quedó como versión no actual.
Dado que el cliente no necesitaba la versión no actual en Standard storage, le recomendé crear una regla de ciclo de vida para limpiar el bucket y eliminar esas versiones no actuales de Standard.
El cliente implementó la siguiente regla de ciclo de vida. La regla establece que, dos días después de que un objeto pasa a ser no actual (es decir, cuando se reemplaza por una versión más reciente), todas las versiones no actuales de ese objeto se eliminan de forma permanente.
Regla de ciclo de vida para eliminar versiones no actuales
**El resultado**
Tras implementar la regla de ciclo de vida el 14 de mayo, observamos que S3 comenzó a eliminar automáticamente las versiones no actuales.
El Standard storage se redujo tras aplicar la regla de ciclo de vida
La regla de ciclo de vida redujo de forma considerable el almacenamiento del bucket de S3, pasando de 4.9 TB a 1.3 TB. Esto se tradujo en ahorros en los costos del bucket y, además, mejoró su rendimiento.
Una acción tan sencilla no solo le ahorró costos de almacenamiento al cliente, sino que también optimizó el rendimiento del bucket. En el siguiente gráfico se ve cómo los costos de S3 del cliente subieron al hacer la transición manual de objetos a Glacier Deep Archive el 6 de mayo, y cómo cayeron tras aplicar la regla de ciclo de vida el 14 de mayo. Este gráfico proviene de DoiT Cloud Navigator— Cloud Analytics.
Conclusiones
Este caso evidencia la importancia de las reglas de ciclo de vida de S3 para gestionar el bucket y las transiciones entre clases de almacenamiento de forma efectiva. El cambio manual del cliente derivó en una duplicación innecesaria entre Glacier Deep Archive y Standard, algo que se habría evitado con reglas de ciclo de vida.
Además, apoyarse en las métricas de S3 y CloudWatch resulta clave para entender el contenido de tu bucket, lo que facilita la gestión de costos y la optimización del rendimiento.
Contáctanos
Si tienes preguntas sobre la optimización de S3 o necesitas ayuda para revisar tu arquitectura de AWS, escríbenos a DoiT International. Nuestro equipo de expertos siempre está listo para apoyarte.