Cómo migrar desde AWS S3 a un proveedor compatible

Migrar object storage asusta menos de lo que parece: como todos los proveedores hablan el mismo protocolo S3, el grueso del trabajo no es reescribir código, sino copiar datos de forma ordenada y conmutar el endpoint con cabeza. En esta guía verás un plan real y reproducible para migrar de AWS S3 a un proveedor compatible sin downtime, con los comandos completos de rclone y AWS CLI, la verificación de integridad y el plan de rollback por si algo se tuerce.

Por qué la migración S3 es más sencilla de lo que crees

La API S3 es un estándar de facto. Eso significa que tus aplicaciones, tus scripts de backup y tus herramientas (AWS CLI, rclone, Terraform, Restic, Velero) seguirán funcionando igual: lo único que cambia es el endpoint y las credenciales. En OtterStorage el endpoint es https://s3.otterstorage.io y la API es compatible, así que la migración consiste en copiar objetos de un bucket a otro y, llegado el momento, apuntar tus apps al nuevo destino.

El otro gran motivo para migrar es económico. AWS S3 cobra por almacenamiento, por peticiones (PUT, GET, LIST), por salida de datos y por operaciones de transición de clase. OtterStorage cobra solo por almacenamiento: sin coste por peticiones, sin coste por borrados y con precios planos de 8 €/TB·mes en HDD, 16 € en SSD y 45 € en NVMe. Si tu factura de S3 está dominada por LIST y GET (muy típico en backups y data lakes), el ahorro es inmediato. Tienes los números en la página de precios y el razonamiento completo en cómo reducir costes de almacenamiento cloud.

1. Inventario y estimación

Antes de copiar un solo byte, necesitas saber qué tienes. Lista todos los buckets de origen, su tamaño, su número de objetos y si usan versionado, Object Lock o reglas de ciclo de vida. También conviene anotar qué aplicaciones escriben en cada bucket: son las que tendrás que conmutar al final.

Para sacar el inventario y el tamaño total de un bucket con AWS CLI:

# Tamaño y número de objetos de un bucket
aws s3 ls s3://mi-bucket --recursive --summarize --human-readable | tail -n 2

# Listado completo a fichero (útil para auditar después)
aws s3api list-objects-v2 --bucket mi-bucket \
  --query 'Contents[].{Key:Key,Size:Size}' --output json > inventario-mi-bucket.json

Con el tamaño total puedes estimar tanto el tiempo de copia como el coste de salida (egress) de AWS, que se factura aparte. Una regla rápida: a 1 Gbps efectivo copias en torno a 400-450 GB/hora. Si tienes decenas de TB, lanza la copia desde una máquina con buen ancho de banda y, a ser posible, en la misma región de tu proveedor de origen para minimizar latencia. OtterStorage ofrece regiones EU-MAD (Madrid), EU-FRA (Frankfurt) y US-EAST: elige la más cercana a tus datos y a tus usuarios.

2. Configurar credenciales y perfiles

Crea unas access keys en OtterStorage desde la consola (puedes aislarlas por bucket, lo que reduce el radio de impacto si una clave se filtra; más detalle en access keys aisladas por bucket). Luego configura dos perfiles en AWS CLI: uno para AWS de origen y otro para el destino.

# ~/.aws/credentials
[aws-origen]
aws_access_key_id = AKIAxxxxxxxxxxxxxxxx
aws_secret_access_key = ********************

[otter]
aws_access_key_id = OTTERxxxxxxxxxxxxxxx
aws_secret_access_key = ********************

Y los dos remotes equivalentes en rclone (~/.config/rclone/rclone.conf):

[aws]
type = s3
provider = AWS
access_key_id = AKIAxxxxxxxxxxxxxxxx
secret_access_key = ********************
region = eu-west-1

[otter]
type = s3
provider = Other
access_key_id = OTTERxxxxxxxxxxxxxxx
secret_access_key = ********************
endpoint = https://s3.otterstorage.io
region = eu-mad

Comprueba que ambos lados responden antes de seguir:

rclone lsd aws:
rclone lsd otter:

3. Crear el bucket destino

Crea el bucket en OtterStorage con el mismo nombre (o uno nuevo si prefieres). Si el origen usa versionado y quieres conservarlo, activa el versionado en el destino antes de copiar:

aws s3 mb s3://mi-bucket --endpoint-url https://s3.otterstorage.io --profile otter

# Activar versionado en destino (si lo necesitas)
aws s3api put-bucket-versioning --bucket mi-bucket \
  --versioning-configuration Status=Enabled \
  --endpoint-url https://s3.otterstorage.io --profile otter

Guía paso a paso en crear un bucket. Si tu caso exige inmutabilidad (retención WORM), planifícalo ahora: el Object Lock debe habilitarse en la creación del bucket, no después.

4. Copia inicial

Esta es la transferencia gruesa: todo el contenido del bucket de origen al destino, con la aplicación todavía escribiendo en origen. La harás una vez y, como puede tardar horas, conviene paralelizar bien.

Opción A: con rclone

rclone es la herramienta más cómoda para migraciones masivas: paraleliza, reanuda y compara hashes. Una primera sincronización completa:

rclone sync aws:mi-bucket otter:mi-bucket \
  --transfers 32 --checkers 32 \
  --fast-list --s3-chunk-size 64M \
  --progress --log-file=migracion.log

Ajusta --transfers a tu CPU y red. --fast-list reduce el número de peticiones LIST (irrelevante para el coste en OtterStorage, pero ayuda con el rate limit de AWS). Guía completa en la documentación de rclone.

Opción B: con AWS CLI

Si prefieres no instalar nada más, aws s3 sync hace una copia equivalente. El truco es que la copia directa de bucket a bucket entre dos endpoints distintos no es trivial, así que lo habitual es pasar por disco local o por un host puente:

# Descarga desde AWS
aws s3 sync s3://mi-bucket ./staging --profile aws-origen

# Sube a OtterStorage
aws s3 sync ./staging s3://mi-bucket \
  --endpoint-url https://s3.otterstorage.io --profile otter

Si tu máquina puente tiene espacio suficiente, este patrón es robusto y fácil de reanudar (cada sync solo mueve lo que falta). Más ejemplos en la guía de AWS CLI.

rclone vs AWS CLI: cuál usar para migrar

En resumen: para el grueso de la migración, rclone suele ganar por velocidad y verificación. Para entornos donde ya solo tienes AWS CLI y un host con disco, AWS CLI es perfectamente válido.

5. Verificación de integridad

No des por buena una copia sin verificarla. Hay dos niveles: recuento (mismo número de objetos y tamaño total) y checksum (mismo contenido objeto a objeto).

# Verificación por hash con rclone (compara MD5/ETag)
rclone check aws:mi-bucket otter:mi-bucket --one-way

# Recuento y tamaño en cada lado
rclone size aws:mi-bucket
rclone size otter:mi-bucket

Si rclone check termina sin diferencias, la copia es fiel. Para datasets enormes, una verificación por muestreo (descargar y comparar el hash de un porcentaje de objetos) puede ser suficiente y mucho más rápida. Anota cualquier objeto reportado como distinto y vuelve a sincronizarlo individualmente antes de continuar.

6. Sincronización incremental

Mientras tu aplicación sigue en producción escribiendo en origen, repite la sincronización periódicamente. Cada pasada solo copia las diferencias respecto a la anterior, así que serán cada vez más rápidas:

# Pasada incremental (solo cambios desde la copia inicial)
rclone sync aws:mi-bucket otter:mi-bucket \
  --transfers 32 --checkers 32 --fast-list --progress

El objetivo es llegar a la ventana de corte con la diferencia entre origen y destino reducida a minutos de datos. Programa estas pasadas (por ejemplo, cada hora) los días previos al cutover. Ten en cuenta una limitación de sync: si un objeto se borra en origen, rclone sync también lo borrará en destino para mantener el espejo; si prefieres no borrar nunca en destino, usa rclone copy en lugar de sync.

7. Ventana de cambio (cutover)

Este es el único momento sensible y suele durar pocos minutos. La secuencia recomendada:

• Pausa las escrituras en origen (modo mantenimiento de la app o congelar el proceso que escribe).
• Lanza una última sincronización incremental, que ahora será mínima.
• Ejecuta una verificación final con rclone check.
• Cambia el endpoint y las credenciales en la configuración de tus aplicaciones.
• Reactiva las escrituras, ahora apuntando a OtterStorage.

Como la API es idéntica, conmutar suele ser tan simple como cambiar dos o tres variables de entorno:

export AWS_ENDPOINT_URL=https://s3.otterstorage.io
export AWS_ACCESS_KEY_ID=OTTERxxxxxxxxxxxxxxx
export AWS_SECRET_ACCESS_KEY=********************

En aplicaciones que usan SDK de AWS, asegúrate de fijar también path-style si tu cliente lo requiere y de revisar que no haya endpoints S3 cableados a mano en el código. Tras conmutar, haz pruebas reales de lectura y escritura desde la propia aplicación, no solo desde la CLI.

8. Plan de rollback

Un cutover bien hecho casi nunca necesita rollback, pero tener el plan escrito te da tranquilidad. La clave: no borres el bucket de origen hasta que el nuevo lleve días funcionando sin incidencias.

• Si algo falla justo tras conmutar, vuelve a poner el endpoint y las credenciales antiguas: el bucket de origen sigue intacto y al día (lo dejaste de escribir hace minutos).
• Conserva los logs de migración (migracion.log) y el resultado de la verificación por si necesitas reproducir el estado.
• Define un periodo de gracia (por ejemplo, 7-14 días) antes de la limpieza definitiva.

Cuando tengas plena confianza, retira el bucket de origen en AWS para dejar de pagar por él. En OtterStorage no hay coste por DELETE ni permanencia, así que limpiar restos en el destino tampoco te cuesta nada.

9. Migración asistida con OtterBridge

Si manejas mucho volumen, muchos buckets o casos complejos (versionado completo, objetos con Object Lock, retenciones legales con Legal Hold), OtterBridge es nuestro servicio de migración asistida: te ayudamos a planificar el inventario, a paralelizar la copia y a validar la integridad, incluyendo los metadatos y políticas que las herramientas genéricas no siempre trasladan. Una vez migrado, puedes apoyarte en OtterSync para mantener replicación entre regiones y en OtterVault para backups inmutables. Tienes el marco general en la documentación.

Preguntas frecuentes