Clases de almacenamiento de S3 explicadas: Cómo elegir la opción adecuada para optimizar costos

Amazon Simple Storage Service (S3) es el almacén de objetos predeterminado para muchas cargas de trabajo de AWS porque escala bien y ofrece varias clases de almacenamiento para diferentes patrones de acceso. Sin embargo, no todos los datos se acceden por igual. Almacenar datos críticos de misión de acceso frecuente en la misma clase que datos de archivo de acceso poco frecuente puede generar un gasto significativo e innecesario en la nube. Comprender los matices entre las diversas clases de almacenamiento de S3 es crucial para diseñar una arquitectura optimizada en costos.

Comprensión de la durabilidad y disponibilidad de S3

Antes de profundizar en las clases, es importante definir dos métricas clave para S3:

• Durabilidad: La probabilidad de que tus datos permanezcan intactos con el tiempo. S3 está diseñado para una durabilidad del 99.999999999% (11 nueves) en toda la infraestructura utilizada para una clase determinada.
• Disponibilidad: El porcentaje de tiempo que tus datos son accesibles para su recuperación. Generalmente se mide anualmente (por ejemplo, 99.9%).

Estas métricas varían ligeramente según la clase de almacenamiento específica elegida.

Las clases principales de almacenamiento de S3: una comparación detallada

AWS ofrece varias clases de almacenamiento optimizadas para diferentes frecuencias de acceso y tolerancia al tiempo de inactividad. Aquí tienes un análisis detallado de las opciones más comunes.

1. S3 Standard

S3 Standard es la clase de almacenamiento predeterminada y de uso general, más adecuada para datos de acceso frecuente.

• Caso de uso: Datos activos, distribución de contenido, contenido generado dinámicamente y aplicaciones móviles/de juegos.
• Durabilidad: 11 nueves.
• Disponibilidad: 99.99% (Alta disponibilidad).
• Tiempo de recuperación: Milisegundos.
• Precios: Costo de almacenamiento más alto entre los niveles de acceso frecuente, pero sin tarifas de recuperación.

Mejor práctica: Úsalo para datos que necesitan acceso inmediato con latencia mínima.

2. S3 Intelligent-Tiering (S3-IT)

S3 Intelligent-Tiering está diseñado para datos con patrones de acceso desconocidos o cambiantes. Mueve automáticamente objetos entre dos o más niveles de acceso según el uso, optimizando los costos de almacenamiento sin sobrecarga operativa.

• Caso de uso: Lagos de datos, datos con patrones de acceso impredecibles, o cuando deseas garantizar el acceso inmediato mientras optimizas el costo con el tiempo.
• Cómo funciona: Monitorea el acceso. Si no se ha accedido a un objeto durante 30 días consecutivos, lo mueve al nivel de Acción Poco Frecuente (IA). Si se accede de nuevo, lo devuelve al nivel de Acceso Frecuente.
• Niveles incluidos: Acceso Frecuente, Acceso Poco Frecuente, Acceso Instantáneo a Archivos (opcional).
• Factor de costo: Incluye una pequeña tarifa mensual de monitoreo y automatización por objeto, además de los costos de almacenamiento, que cambian según el nivel en el que se encuentre el objeto.

Consejo práctico: Si no estás seguro de la frecuencia con la que se accederá a los datos, S3 Intelligent-Tiering a menudo proporciona el mejor equilibrio entre ahorro de costos y consistencia de rendimiento.

3. S3 One Zone-Infrequent Access (S3 One Zone-IA)

Esta clase es ideal para datos a los que se accede con poca frecuencia pero que requieren una recuperación rápida, similar a S3 Standard-IA, pero con una diferencia importante en disponibilidad.

• Caso de uso: Copias de seguridad secundarias, datos recreables (por ejemplo, datos que se pueden regenerar a partir de una fuente), o almacenar datos que no son lo suficientemente críticos para el negocio como para justificar la redundancia multi-AZ.
• Durabilidad: 11 nueves.
• Disponibilidad: 99.5% (Disponibilidad más baja que Standard).
• Ubicación de almacenamiento: Los datos se almacenan de forma redundante en una sola Zona de Disponibilidad (AZ) de AWS, a diferencia de otras clases que abarcan múltiples AZ.
• Factor de costo: Costo de almacenamiento significativamente más bajo que Standard, pero la recuperación de datos incurre en una tarifa.

⚠️ Advertencia sobre One Zone-IA: Debido a que los datos residen en una sola AZ, si esa AZ específica experimenta un evento catastrófico (por ejemplo, un corte de energía importante o un desastre natural), tus datos en este nivel podrían perderse. Por eso es crucial solo para datos no críticos y fácilmente reemplazables.

4. Clases de almacenamiento S3 Glacier (Archivo)

Las clases de almacenamiento Glacier están optimizadas para el archivado a largo plazo donde los tiempos de recuperación de minutos a horas son aceptables.

S3 Glacier Instant Retrieval (S3 Glacier IR)

Esto cierra la brecha entre el Acceso Poco Frecuente y el archivo profundo.

• Caso de uso: Datos a los que se accede una vez al trimestre o menos, pero que requieren recuperación en milisegundos cuando es necesario (por ejemplo, imágenes médicas, archivos de medios de noticias).
• Tiempo de recuperación: Milisegundos (latencia similar a las clases IA).
• Factor de costo: Costo de almacenamiento muy bajo, con tarifas de recuperación.

S3 Glacier Flexible Retrieval (anteriormente S3 Glacier)

Esta es una opción de archivado a largo plazo cuando la recuperación en minutos u horas es aceptable.

• Caso de uso: Archivos de cumplimiento normativo, datos de recuperación ante desastres que rara vez, o nunca, se necesitan.
• Opciones de recuperación (y latencia):
  • Acelerada: 1–5 minutos
  • Estándar: 3–5 horas
  • Masiva: 5–12 horas
• Factor de costo: Costo de almacenamiento extremadamente bajo, pero se aplican tarifas de recuperación y llevan tiempo.

S3 Glacier Deep Archive

La opción de almacenamiento de costo más bajo absoluto en AWS S3.

• Caso de uso: Datos a los que solo se puede acceder una o dos veces al año, generalmente para cumplimiento.
• Opciones de recuperación (y latencia):
  • Estándar: 12 horas
  • Masiva: 48 horas
• Factor de costo: Tarifa de almacenamiento más baja disponible, tarifas de recuperación más altas y ventanas de recuperación requeridas más largas.

Cómo elegir: un marco de decisión

Seleccionar la clase correcta depende de responder tres preguntas clave sobre el ciclo de vida de tus datos:

Pregunta	Consideración principal	Ruta de clase recomendada
¿Con qué frecuencia se accede?	Frecuencia de acceso	Frecuente $\rightarrow$ Standard; Poco frecuente $\rightarrow$ IA o Glacier
¿Cuál es el tiempo de inactividad/pérdida aceptable?	Durabilidad/Disponibilidad	Crítico $\rightarrow$ Standard/Intelligent-Tiering; Desechable $\rightarrow$ One Zone-IA
¿Qué tan rápido debo recuperarlo?	Requisito de latencia	Milisegundos $\rightarrow$ Standard/Intelligent-Tiering/Glacier IR; Horas $\rightarrow$ Glacier Flexible/Deep Archive

Escenario de ejemplo: Activos multimedia de una empresa

Un equipo de marketing sube cientos de archivos de video sin procesar diariamente:

1. Ediciones/promociones actuales (Últimos 30 días): S3 Standard (Alto acceso, baja latencia).
2. Activos más antiguos que necesitan revisión ocasional (30 días a 1 año): S3 Intelligent-Tiering (Para capturar ahorros de costos después del período inicial activo).
3. Maestros finales completados y auditados (Más de 1 año): S3 Glacier Deep Archive (Costo más bajo, solo necesario para auditorías de cumplimiento).

Escenario de ejemplo: Registros, copias de seguridad y cargas de usuarios

Una sola empresa a menudo tiene tres patrones de S3 muy diferentes.

Para los registros de aplicaciones, los datos recientes son valiosos porque los ingenieros los buscan durante incidentes. Una vez que pasa la ventana del incidente, la mayoría de los registros se convierten en datos de cumplimiento o tendencias. Un ciclo de vida razonable podría mantener de 30 a 90 días en Standard o Standard-IA, mover los registros más antiguos a un nivel de archivo y caducar los registros de depuración de bajo valor después de un período de retención fijo. Los números exactos deben provenir de tu política de retención y de la frecuencia con la que las personas realmente consultan prefijos antiguos.

Para las copias de seguridad de bases de datos, la clase de almacenamiento debe seguir la promesa de restauración. Si el equipo dice que una restauración de producción debe comenzar en minutos, mantén las copias de seguridad más recientes en una clase con recuperación inmediata. Las copias mensuales o anuales más antiguas pueden pasar a un nivel más frío si están allí para retención de auditoría en lugar de recuperación rápida. Prueba las restauraciones desde la clase elegida; una política de copia de seguridad que nunca se ha restaurado es principalmente una regla de facturación.

Para las cargas de usuarios, el acceso es más difícil de predecir. Una foto de perfil puede ser pequeña pero obtenida constantemente. Un video original grande puede descargarse una vez, transcodificarse y rara vez tocarse de nuevo. Almacena los activos derivados y los originales bajo prefijos separados para que las reglas del ciclo de vida puedan tratarlos de manera diferente. No hagas que la política de miniaturas herede la misma regla de archivo que los originales de varios gigabytes a menos que eso sea realmente lo que necesita el producto.

Preguntas que hacer antes de cambiar un bucket

Antes de agregar una regla de ciclo de vida, pregunta quién lee los datos, cómo los lee y qué sucede si la recuperación se retrasa. Los ingenieros a menudo conocen mejor la ruta de escritura que la ruta de lectura porque las cargas son parte de la aplicación, mientras que las lecturas ocurren más tarde a través de análisis, herramientas de soporte, exportaciones de cumplimiento o respuesta manual a incidentes.

Busca trabajos por lotes que escaneen prefijos antiguos. Un trabajo nocturno que enumera cada objeto, abre metadatos o muestrea archivos antiguos puede borrar parte de los ahorros de una clase más fría. Si el trabajo solo necesita un manifiesto, S3 Inventory puede ser mejor que enumerar el bucket repetidamente. Si los analistas consultan registros con Athena, considera el diseño de particiones y la compresión antes de mover datos a una clase que requiera pasos de restauración.

Presta atención al tamaño del objeto. Las clases de almacenamiento con tamaños mínimos de objeto facturables pueden ser inadecuadas para grandes cantidades de archivos pequeños. En esos casos, compactar datos en objetos más grandes, usar Parquet para análisis o caducar objetos innecesarios puede ser mejor que cambiar de clase de almacenamiento.

Finalmente, escribe las reglas del ciclo de vida de una manera que puedas explicar durante un incidente. Una regla de prefijo llamada archivar-registros-antiguos-despues-de-90-dias es más fácil de razonar que una regla de todo el bucket que mueve silenciosamente todo después de 30 días. La optimización de costos debería hacer que el sistema sea más barato sin hacer que la recuperación sea misteriosa.

Una comprobación práctica más es la propiedad. En cuentas reales, el propietario del bucket, la cuenta de carga, el rol de replicación y la cuenta de análisis no siempre son los mismos. Antes de mover datos a una clase de archivo, confirma quién puede restaurarlos y quién paga por la recuperación. Los buckets entre cuentas con cifrado KMS pueden fallar en el momento de la restauración si el rol que necesita el objeto puede enumerar el bucket pero no puede usar la clave. Esa es una mala sorpresa durante una auditoría.

El versionado también cambia las matemáticas. Las reglas del ciclo de vida pueden hacer la transición o caducar las versiones actuales y las no actuales de manera diferente. Si una aplicación sobrescribe la misma clave cada hora, las versiones no actuales pueden convertirse en la parte más grande del bucket. Revísalas por separado en lugar de asumir que el recuento de objetos actual cuenta toda la historia.

Implementación de políticas de ciclo de vida

Mover objetos manualmente entre clases es ineficiente. La forma más efectiva de administrar los costos en estos niveles es mediante el uso de políticas de ciclo de vida de S3.

Las políticas de ciclo de vida te permiten definir reglas que hacen la transición automática de objetos a niveles de almacenamiento más fríos o los caducan permanentemente después de un número definido de días.

Ejemplo de regla de ciclo de vida (Transición):

<Rule>
    <ID>Mover_a_IA_Despues_de_30_Dias</ID>
    <Status>Habilitado</Status>
    <Filter>
        <Prefix>logs/</Prefix>
    </Filter>
    <Transition>
        <Days>30</Days>
        <StorageClass>GLACIER_IR</StorageClass>
    </Transition>
</Rule>

Esta configuración mueve automáticamente cualquier objeto en el prefijo logs/ a Glacier Instant Retrieval 30 días después de su creación, reduciendo significativamente los costos de almacenamiento a largo plazo mientras mantiene capacidades de recuperación rápidas si es necesario.

Trampas de costos que la gente pasa por alto

La decisión de la clase de almacenamiento no es solo una comparación mensual de GB. Los cargos de recuperación, los cargos de solicitud, la duración mínima de almacenamiento, el tamaño mínimo de objeto facturable, la replicación, las solicitudes de transición del ciclo de vida y las tarifas de monitoreo pueden cambiar la respuesta. Un archivo de objetos pequeños con millones de claves puede comportarse de manera muy diferente a un pequeño número de archivos de copia de seguridad grandes.

Por ejemplo, los registros de aplicaciones a menudo se escriben una vez y rara vez se leen, por lo que una regla de ciclo de vida de Standard a Glacier Instant Retrieval o Glacier Flexible Retrieval puede tener sentido. Pero si tu proceso de incidentes escanea con frecuencia registros antiguos con Athena, el archivado agresivo puede crear restauraciones lentas y costos de recuperación sorpresa. En ese caso, particionar los registros por fecha, caducar prefijos ruidosos de bajo valor y mantener los meses recientes en una clase compatible con consultas puede ahorrar más dinero que mover ciegamente todo a frío después de 30 días.

Las copias de seguridad tienen una forma diferente. Un volcado de base de datos que pruebas una vez al mes necesita un comportamiento de restauración predecible. Si tu objetivo de tiempo de recuperación se mide en minutos, Deep Archive probablemente no sea el lugar adecuado para la única copia restaurable, incluso si es barata en reposo. Si el mismo volcado es la tercera copia mantenida solo para retención de auditoría, Deep Archive puede ser razonable.

Los equipos de medios a menudo necesitan activos antiguos de manera impredecible. Intelligent-Tiering puede ser un buen valor predeterminado para esos patrones desconocidos, especialmente cuando los objetos son lo suficientemente grandes como para que la tarifa de monitoreo no sea el factor decisivo. Para grandes cantidades de miniaturas pequeñas, la tarifa y el comportamiento del tamaño mínimo del objeto merecen una mirada más cercana antes de activarlo en todas partes.

Una forma práctica de elegir es muestrear un bucket, exportar S3 Inventory, agrupar por prefijo, recuento de objetos, bytes totales, fecha de última modificación y patrón de acceso conocido, luego escribir reglas de ciclo de vida por prefijo. Evita una regla para todo el bucket a menos que el bucket realmente contenga un tipo de datos.