Almacenamiento de objetos vs almacenamiento de bloques: ¿cuál es mejor?

El almacenamiento de objetos gana para archivos subidos por usuarios, activos estáticos, copias de seguridad y archivos históricos: básicamente cualquier cosa a la que se accede mediante HTTP y que rara vez se muta. El almacenamiento de bloques gana cuando necesitas escrituras aleatorias de baja latencia: bases de datos, volúmenes de arranque, sistemas de archivos de alta transacción. Para cargas de trabajo de transferencia de archivos específicamente, el almacenamiento de objetos es casi siempre la opción correcta porque escala horizontalmente, cuesta entre 0,015 y 0,023 $/GB/mes frente a 0,08-0,125 $/GB/mes del almacenamiento en bloques, y gestiona buckets a escala de petabytes sin reparticionamiento.

El artículo 32 del RGPD exige cifrado en reposo como medida técnica apropiada: ambos tipos de almacenamiento lo admiten, pero el almacenamiento de objetos lo hace con controles de acceso por objeto más granulares (políticas de bucket, URLs prefirmadas, etiquetas) que facilitan el cumplimiento documentado que exige la AEPD.

Cómo difieren realmente bajo el capó

El almacenamiento de bloques expone un dispositivo sin formato (un LUN o un volumen EBS) que el SO formatea con ext4, XFS o NTFS. Las lecturas y escrituras ocurren en bloques de tamaño fijo, típicamente de 4 KB o 16 KB, por iSCSI, NVMe-oF o SCSI. El SO es dueño del sistema de archivos; el dispositivo de bloques no sabe nada de archivos, solo de desplazamientos.

El almacenamiento de objetos expone una API HTTP (S3, Azure Blob, GCS) donde cada objeto tiene una clave, bytes y metadatos. No hay sistema de archivos debajo: los objetos son unidades atómicas que se hacen PUT y GET completos. Las escrituras generan nuevas versiones; no puedes modificar el byte 1.000.000 de un objeto de 2 GB sin reescribir el objeto completo. Esta inmutabilidad es una característica: permite la replicación multirregional, el versionado y las reglas de ciclo de vida que el almacenamiento en bloques no puede igualar fácilmente.

Comparación rápida

| Dimensión | Almacenamiento de objetos | Almacenamiento de bloques | |-----------|--------------------------|--------------------------| | API típica | S3 HTTP REST | POSIX + iSCSI/NVMe | | Coste (nivel caliente de AWS) | 0,023 $/GB/mes | 0,08 $/GB/mes (gp3) | | Unidad máxima | 5 TB por objeto | 64 TiB por volumen EBS | | Latencia | 10-100 ms | Por debajo del milisegundo | | Lectores concurrentes | Ilimitados | Un host a la vez (normalmente) | | Garantía de durabilidad | 11 nueves (S3) | 5-6 nueves (EBS) | | Bueno para | Archivos, medios, copias de seguridad | Bases de datos, discos de arranque | | Malo para | Escrituras aleatorias en archivos grandes | Escala horizontal más allá de un volumen |

Rendimiento vs latencia: ganadores distintos

Un volumen EBS gp3 sirve lecturas de 4 KB en menos de 1 ms; un GET de S3 para los mismos 4 KB tarda 20-80 ms dependiendo de la región. Para un WAL de PostgreSQL que realiza 5.000 transacciones por segundo, esa diferencia de latencia es ruinosa. Para un usuario que descarga un .zip de 500 MB, es irrelevante porque el retraso del primer byte desaparece detrás del rendimiento.

En rendimiento secuencial, el almacenamiento de objetos suele ganar a escala. S3 puede servir un solo bucket a 5.500 solicitudes GET/segundo por prefijo, y con el particionamiento por tasa de solicitudes (claves con prefijo hash) eso se eleva a decenas de miles. Un solo volumen gp3 tiene un límite de 1.000 MB/s y 16.000 IOPS. Para diez usuarios concurrentes descargando un archivo de 10 GB, el almacenamiento de objetos satura sus conexiones; el almacenamiento en bloques se convierte en un cuello de botella.

Coste a escala

Para 100 TB de medios moderadamente fríos:

S3 Standard: 2.300 $/mes
S3 Standard-IA: 1.250 $/mes
S3 Glacier Instant Retrieval: 400 $/mes
S3 Glacier Deep Archive: 99 $/mes
EBS gp3: 8.000 $/mes
EBS st1 (HDD optimizado para rendimiento): 4.500 $/mes

El almacenamiento en bloques no tiene niveles. Pagas el precio de acceso máximo por datos que tocas una vez al año. Las reglas de ciclo de vida del almacenamiento de objetos mueven los objetos automáticamente: caliente durante 30 días, Standard-IA durante 60, Glacier después de 90. Para un servicio de transferencia de archivos que almacena subidas con una caducidad de 7 días, el almacenamiento de objetos con una regla Expiration es dramáticamente más económico que ejecutar un servidor respaldado por EBS.

Consistencia y concurrencia

S3 proporciona ahora consistencia fuerte de lectura tras escritura para PUTs y DELETEs a nivel global. Azure Blob y GCS hacen lo mismo. Esto eliminó uno de los argumentos históricos en contra del almacenamiento de objetos: antes se podían ver sorpresas de "consistencia eventual" donde un archivo recién subido daba 404 durante unos segundos.

Pero los escritores concurrentes siguen importando. El almacenamiento en bloques generalmente asume un solo escritor; los modos de adjuntos múltiples existen pero añaden complejidad. El almacenamiento de objetos permite que un millón de clientes hagan PUT simultáneamente, con semántica de último escritor gana (o versionado para conservarlos todos). Para un sistema de intercambio de archivos donde dos usuarios podrían subir archivos diferentes con la misma clave, el versionado en el bucket conserva ambos.

Cuándo las aplicaciones de transferencia de archivos necesitan almacenamiento en bloques de todos modos

La advertencia: la aplicación que sirve el almacenamiento de objetos a menudo se ejecuta en hosts respaldados por bloques. Una API de subida de archivos necesita un disco local para la cola temporal (fragmentos multiparte, análisis antivirus), almacenamiento de metadatos (generalmente en PostgreSQL sobre EBS) y registros. Los objetos en sí van a S3/R2/Blob; la maquinaria que los gestiona vive en bloques.

Para subidas de streaming de alto rendimiento, las tuberías en memoria superan al disco. Las bibliotecas como aws-sdk-js y boto3 admiten subidas multiparte en streaming que nunca llegan al disco local. Un servicio de subida bien ajustado puede enviar un archivo de 5 GB del cliente al almacenamiento de objetos con menos de 500 MB de RAM y cero archivos temporales.

Metadatos: la diferencia silenciosa

El almacenamiento de objetos lleva metadatos con cada objeto: metadatos del sistema (tamaño, mtime, etag), metadatos de usuario (pares clave-valor arbitrarios, cabeceras x-amz-meta-*) y etiquetas. Puedes buscar por metadatos mediante S3 Object Lambda, informes de inventario, o combinándolos con DynamoDB. El almacenamiento en bloques deja los metadatos completamente al sistema de archivos, lo que significa que etiquetar 10 millones de archivos requiere una base de datos personalizada.

Para una aplicación de transferencia que necesita responder instantáneamente "encuentra todos los archivos de más de 100 MB subidos la semana pasada por usuarios en Francia", los metadatos de objetos más un inventario Parquet permiten consultar con Athena en segundos. La misma pregunta en un volumen de bloques montado por NFS es un comando find que tarda horas.

Cifrado y control de acceso

Ambos tipos de almacenamiento admiten cifrado en reposo con AES-256. El almacenamiento de objetos facilita el control de acceso por objeto: políticas de bucket, URLs prefirmadas, ACLs de objetos y condiciones IAM. El acceso al almacenamiento en bloques es más grueso: el volumen entero está adjunto o no lo está.

Para el intercambio seguro de archivos con enlaces de descarga de tiempo limitado, las URLs prefirmadas de S3 (válidas hasta 7 días como máximo) son el patrón estándar. Para transferencias sin exposición de texto plano en el servidor, el cifrado del lado del cliente antes de la subida funciona con cualquier almacenamiento de objetos. HexaTransfer cifra con AES-256-GCM en el navegador y almacena solo texto cifrado: el backend de objetos ve bytes sin sentido.

La regla de decisión simple

Hazte tres preguntas:

¿Accedes a los datos mediante una API de sistema de archivos (POSIX, SMB, NFS)? Si es así, almacenamiento en bloques o de archivos.
¿Accedes mediante HTTP, los mutas raramente y quieres escala ilimitada? Si es así, almacenamiento de objetos.
¿El conjunto de datos supera los 10 TB y está creciendo? Casi siempre almacenamiento de objetos.

Para cargas de trabajo de transferencia de archivos, la respuesta a la pregunta (2) siempre es sí. Usa S3, R2, Azure Blob o GCS para los archivos en sí, y reserva el almacenamiento en bloques para la base de datos y el nivel web que los gestiona.

Pruébalo en hexatransfer.com, gratis, sin cuenta, hasta 10 GB.