Versionado, MFA Delete y replicación

S3 Versioning le permite conservar, recuperar y restaurar todas las versiones de cada objeto almacenado en un bucket. Cuando el versionado está habilitado, cada PUT crea una nueva versión con un identificador de versión único; la versión anterior se conserva en lugar de sobrescribirse. Si se elimina un objeto, S3 añade un marcador de eliminación como versión actual, pero conserva todas las versiones anteriores. Esto protege frente a sobrescrituras accidentales, eliminaciones accidentales y corrupción de datos no intencionada a nivel de la aplicación, que son los escenarios más comunes de pérdida de datos en producción.

Un bucket de S3 puede encontrarse en uno de tres estados de versionado: sin versionado (predeterminado, sin identificadores de versión), con el versionado habilitado (todos los objetos nuevos reciben identificadores de versión únicos y todas las sobrescrituras crean versiones nuevas) o con el versionado suspendido (los objetos nuevos reciben un identificador de versión null, pero las versiones existentes se conservan). No puede eliminar el versionado una vez habilitado; solo puede suspenderlo. Los objetos creados antes de habilitar el versionado tienen un identificador de versión null y no se ven afectados hasta que se sobrescriben o eliminan.

Para restaurar una versión anterior de un objeto versionado, tiene dos opciones. Opción 1: copie el identificador de la versión anterior en la misma clave; esto crea una nueva versión que es una copia del contenido anterior y la convierte en la versión actual. Opción 2: elimine la versión actual o el marcador de eliminación para que la versión anterior pase a ser la actual. Cuando «elimina» un objeto de un bucket con versionado mediante la consola sin especificar un identificador de versión, S3 añade un marcador de eliminación; el objeto parece eliminado para las solicitudes sin versionado, pero todas las versiones siguen existiendo.

MFA Delete añade una segunda capa de protección para los buckets con versionado. Cuando está habilitado, para eliminar permanentemente una versión específica o cambiar el estado de versionado del bucket (de habilitado → suspendido) es necesario proporcionar credenciales MFA válidas en la solicitud de la API. Esto protege frente a un atacante que haya comprometido sus credenciales de AWS y elimine permanentemente versiones críticas, frente a la eliminación accidental o automatizada de versiones de objetos protegidas y frente a amenazas internas que intenten destruir registros de auditoría. MFA Delete solo puede habilitarse y deshabilitarse mediante la CLI por el usuario root.

S3 Object Lock impone un modelo de escritura única y múltiples lecturas (WORM) para cumplir requisitos normativos. Los objetos bloqueados con Object Lock no se pueden eliminar ni sobrescribir durante un periodo de retención especificado, ni siquiera por el usuario root de la cuenta. Hay dos modos: Governance mode (los usuarios con permisos especiales pueden anular o eliminar el bloqueo) y Compliance mode (nadie, ni siquiera AWS, puede eliminar el objeto durante el periodo de retención; es la protección más sólida). Object Lock debe habilitarse al crear el bucket y requiere el versionado.

Cross-Region Replication (CRR) replica automáticamente los objetos nuevos y las actualizaciones desde un bucket de origen de una región a un bucket de destino de otra región. Casos de uso: cumplimiento normativo (conservar una copia de los datos en un país específico), recuperación ante desastres (reducir el RPO de los datos críticos manteniendo una copia en una segunda región) y reducción de la latencia (servir los objetos desde la región más cercana a los usuarios). CRR requiere que el versionado esté habilitado tanto en el bucket de origen como en el de destino, además de un rol de IAM con los permisos de replicación necesarios.

Same-Region Replication (SRR) replica objetos dentro de la misma región. Casos de uso: agregación de registros (replicar registros de varios buckets de origen en un bucket central), sincronización de entornos de prueba (conservar una copia de los datos de producción en un bucket de desarrollo dentro de la misma región) y cumplimiento de la soberanía de los datos dentro de un mismo país que tiene varias AZ de AWS. Al igual que CRR, SRR requiere el versionado en ambos buckets y un rol de IAM. Solo los objetos nuevos creados después de habilitar la replicación se replican automáticamente; use S3 Batch Replication para replicar los objetos existentes.

La replicación de S3 sí replica objetos nuevos, metadatos, etiquetas, ACL y el estado de cifrado. De forma predeterminada, la replicación no replica objetos que ya existían antes de habilitarla (use S3 Batch Replication para esos objetos), marcadores de eliminación (salvo que habilite Delete Marker Replication), objetos de Glacier (no se pueden replicar; primero debe restaurarlos) ni objetos replicados (no hay replicación en cascada entre tres buckets). Comprender estos límites es importante para diseñar estrategias completas de recuperación ante desastres en las que también sea necesario replicar los datos históricos y los eventos de eliminación.

Replication Time Control (RTC) es un complemento opcional de CRR que proporciona un acuerdo de nivel de servicio: el 99,99 % de los objetos se replica en un plazo de 15 minutos, con métricas de replicación y notificaciones en CloudWatch. Sin RTC, la replicación no ofrece ninguna garantía de tiempo; la mayoría de los objetos se replica rápidamente, pero algunos casos atípicos pueden tardar horas. RTC es esencial cuando sus requisitos de recuperación ante desastres o cumplimiento normativo especifican un objetivo de punto de recuperación (RPO) máximo para los datos de S3. Añade un coste de replicación por GB al coste estándar de transferencia de datos de replicación.

Habilitar el versionado aumenta los costos de almacenamiento porque S3 conserva cada versión de cada objeto hasta que se elimina explícitamente. Un archivo de 100 MB que se sobrescribe 10 veces ahora consume 1.000 MB de almacenamiento. Mitigue esto con reglas de ciclo de vida que expiren automáticamente las versiones no actuales después de una cantidad determinada de días (por ejemplo, eliminar versiones no actuales con más de 30 días), o transfiera las versiones no actuales a clases de almacenamiento más económicas como Glacier. Siempre combine el versionado con reglas de ciclo de vida para controlar los costos de almacenamiento en producción.

El versionado de S3 combinado con Object Lock (modo Compliance) proporciona una sólida protección contra el ransomware. Si un atacante cifra o elimina sus objetos, el versionado garantiza que las versiones anteriores se conserven (a menos que el atacante las elimine permanentemente, motivo por el cual Object Lock impide la eliminación permanente durante el período de retención). Para obtener la máxima protección: habilite el versionado, habilite MFA Delete, aplique Object Lock en modo Compliance a los datos críticos y replique en una segunda Region con credenciales de IAM independientes para evitar que el compromiso de una sola cuenta destruya todas las copias.

Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.

En esta lección aprendió que: el versionado conserva todas las versiones de cada objeto y protege contra la eliminación accidental, MFA Delete y Object Lock proporcionan inmutabilidad adicional para el cumplimiento normativo y la protección contra ransomware y CRR y SRR replican objetos en otros buckets para cumplir requisitos de DR y cumplimiento normativo. A continuación, exploraremos las clases de almacenamiento de S3 y las políticas de ciclo de vida para optimizar los costos.