SAA-C03

Deep Dive

Practicar ahora
D2 · Arquitecturas resilientes

S3 Replication: CRR, SRR y Versioning

S3 Replication copia objetos automáticamente entre buckets para DR, compliance o reducción de latencia. Cross-Region Replication (CRR) es clave para arquitecturas de Disaster Recovery. Same-Region Replication (SRR) agrega logs o sincroniza entornos de test/prod. Versioning es un prerequisito obligatorio.

Icon-Architecture/48/Arch_Amazon-Simple-Storage-Service_48

S3 Versioning — prerequisito de replicación

Versioning conserva todas las versiones de un objeto, incluidas las eliminaciones. Es prerequisito obligatorio para activar CRR o SRR en cualquier bucket. Sin versioning habilitado en source y destination, la replicación no funciona.

Unversioned (default)

Estado inicial de todos los buckets. No se guardan versiones anteriores de objetos.

Versioning-enabled

Todas las versiones de cada objeto se conservan. Prerequisito obligatorio para CRR y SRR.

Versioning-suspended

No crea nuevas versiones pero conserva las existentes. Los objetos nuevos reciben version ID "null".

Delete Marker

Al borrar un objeto con versioning activo, S3 crea un "delete marker" en lugar de eliminar el objeto. El objeto sigue existiendo y puede recuperarse eliminando el marker.

MFA Delete

Capa adicional de seguridad. Requiere MFA para borrar versiones permanentemente o para cambiar el estado de versioning del bucket.

Costo de versioning

Se paga por cada versión almacenada. Las versiones antiguas acumulan costo. Usar Lifecycle Rules para expirar versiones no deseadas automáticamente.

Lifecycle + Versioning

Las reglas de Lifecycle pueden mover versiones antiguas a clases más baratas (IA, Glacier) o expirarlas después de N días para controlar costos.

Trampa de examen

Suspender versioning no elimina versiones existentes — solo deja de crear versiones nuevas. Las versiones antiguas siguen ahí y se siguen cobrando. Para eliminarlas hay que usar Lifecycle policies o borrarlas manualmente.

Icon-Architecture/48/Arch_Amazon-Simple-Storage-Service_48

Cross-Region Replication (CRR)

CRR replica objetos automáticamente a un bucket en otra región AWS. Es la herramienta principal para arquitecturas de Disaster Recovery multi-región y para cumplir requisitos de residencia de datos en geografías específicas.

Casos de uso

DR multi-región, latencia reducida para usuarios en otra región, compliance (datos en país específico).

Prerequisitos

Versioning habilitado en bucket source y destination. IAM role con permisos s3:ReplicateObject, s3:ReplicateDelete.

Replication Time Control (RTC)

Garantiza que el 99.99% de objetos se replican en ≤15 minutos. Tiene costo adicional. Sin RTC la latencia es variable.

CRR estándar vs CRR con RTC

CRR estándar

Replica objetos sin SLA de tiempo. Puede tardar desde segundos hasta minutos (o más en casos excepcionales). Sin garantía contractual de RPO.

CRR con RTC (Replication Time Control)

Garantiza que el 99.99% de objetos se replican en ≤15 minutos. Incluye métricas de replicación en CloudWatch. Tiene costo adicional.

Trampa de examen

Los objetos que existían antes de activar CRR no se replican automáticamente. Solo los objetos nuevos (creados después de activar la regla) se replican. Para replicar objetos existentes hay que usar S3 Batch Replication como paso manual adicional.

Icon-Architecture/48/Arch_Amazon-Simple-Storage-Service_48

Same-Region Replication (SRR)

SRR replica objetos entre buckets dentro de la misma región AWS. Comparte los mismos prerequisitos que CRR (versioning en ambos buckets) pero sirve para casos de uso distintos donde la latencia inter-regional no es necesaria ni deseable.

Agregación de logs

Consolidar logs de múltiples buckets de la misma región en un único bucket central para análisis.

Prod a Test

Replicar datos de producción a un entorno de test separado dentro de la misma región, con datos reales pero sin afectar prod.

Multi-cuenta misma región

Sincronizar buckets entre distintas cuentas AWS dentro de la misma región. Útil para segregación de cuentas con compliance regional.

CRR vs SRR — diferencia principal

La única diferencia técnica es la región de destino. CRR = bucket destino en región diferente. SRR = bucket destino en la misma región. Ambas requieren versioning, IAM role, y tienen las mismas opciones de configuración (filters, storage class override, ownership override).

Icon-Architecture/48/Arch_Amazon-Simple-Storage-Service_48

Reglas de replicación y configuración

1

Filters por prefijo o tags

No es necesario replicar todo el bucket. Se pueden crear reglas para replicar solo objetos con cierto prefijo (ej: "logs/") o tags específicas.

2

Storage class override

Los objetos replicados pueden guardarse en una clase de almacenamiento diferente en el destino. Típico: replicar a S3-IA o S3 Glacier para DR de menor costo.

3

Ownership override

En replicación cross-account, el propietario del objeto destino puede cambiarse a la cuenta destino. Sin esto, los objetos pertenecen a la cuenta origen.

4

Replicación de objetos cifrados

SSE-S3: soportada por defecto. SSE-KMS: requiere configuración adicional — la clave KMS destino debe configurarse explícitamente en la regla de replicación.

5

Bucket Replication vs S3 Batch Replication

Replication Rule cubre objetos nuevos a partir de activarla. Los objetos existentes antes de activar la regla NO se replican — usar S3 Batch Replication para esos.

Trampa de examen

Los delete markers NO se replican por defecto. Si el source borra un objeto y se espera que el destino también lo "borre" (reciba el delete marker), hay que habilitar explícitamente la opción "Replicate delete markers" en la regla de replicación.

Icon-Architecture/48/Arch_Amazon-Simple-Storage-Service_48

Replicación como estrategia de DR

CRR es uno de los pilares de una estrategia de DR multi-región en AWS. Combinado con Route 53 Failover Routing y compute pre-configurado (Pilot Light), permite una recuperación rápida ante fallos regionales.

CRR + Route 53 Failover Routing = arquitectura DR sólida con failover automatizado

CRR con RTC: RPO garantizado de ≤15 minutos para el 99.99% de objetos

Object Lock en bucket destino: protección contra ransomware y borrado accidental

Pilot Light DR: CRR mantiene datos replicados; en desastre, lanzar compute en región secundaria

CRR reemplaza un backup — falso. Es replicación sincrónica, no archivado con retención a largo plazo. Usar Glacier para backups

RPO con CRR — referencia rápida

CRR estándar

RPO: minutos (no garantizado contractualmente). Válido para DR donde una latencia de replicación variable es aceptable.

CRR + RTC

RPO garantizado: ≤15 minutos para el 99.99% de objetos. Usar cuando el SLA de negocio exige un RPO concreto y documentado.

Icon-Architecture/48/Arch_Amazon-Simple-Storage-Service_48

Best practices para el examen

1

Versioning es obligatorio en AMBOS buckets (source y destination)

No solo en el source. Si el destination no tiene versioning habilitado, la replicación falla. Este es uno de los errores más comunes en el examen.

2

CRR estándar NO garantiza tiempo de replicación

La latencia es variable — puede ser segundos o minutos dependiendo del tamaño y carga. Solo RTC garantiza ≤15 minutos para el 99.99% de objetos.

3

Los delete markers NO se replican por defecto

Si se borra un objeto en source, el delete marker no se copia automáticamente al destination. Se puede configurar para que sí se replique, pero no es el default.

4

S3 Batch Replication para objetos existentes

Al activar CRR, solo los objetos nuevos se replican. Para migrar objetos que existían antes, se usa S3 Batch Replication como operación manual.

5

Suspender versioning no borra las versiones existentes

Las versiones anteriores permanecen y se siguen cobrando. Solo Lifecycle Policies pueden expirar y eliminar versiones antiguas de forma automatizada.

Diagrama: CRR y SRR — replicación entre buckets

Visualiza Cross-Region y Same-Region Replication con sus casos de uso y configuración.

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Una empresa tiene datos críticos en S3 us-east-1. Necesitan que esos datos estén disponibles en eu-west-1 para DR, con garantía de que el 99.99% de objetos nuevos estén replicados en menos de 15 minutos. ¿Qué configuración es correcta?