Midiendo el rendimiento de AWS S3 Files, un benchmark comparativo con S3fs-fuse.

En base a nuestra experiencia en entornos cloud, el acceso al almacenamiento de objetos como AWS S3 se resuelve habitualmente de tres formas: mediante llamadas directas a la API (AWS CLI), montando el bucket como un filesystem local con (s3fs-fuse) o a través del nuevo cliente nativo de Amazon, AWS S3 Files.

En este artículo presentamos un benchmark automatizado con Terraform/OpenTofu para comparar el rendimiento real de estas tres aproximaciones, midiendo operaciones secuenciales de lectura y escritura sobre diferentes tamaños de archivo.

Analizaremos las IOPS, latencia y throughput de cada método, concluyendo que no existe una solución universalmente superior, sino que la elección óptima depende de las características de la carga de trabajo.

Arquitectura

El entorno de pruebas se ha definido íntegramente como código Terraform y consta de los siguientes elementos:

Cada componente cumple un rol específico:

• S3 Bucket — Almacén de objetos con versionado habilitado, cifrado SSE-KMS y acceso público bloqueado.
• EC2 Instance — Ejecuta el benchmark automáticamente al arrancar mediante user-data.
• IAM Role — Políticas de mínimo privilegio: GetObject, PutObject, DeleteObject, ListBucket y HeadObject sobre el bucket de prueba.
• S3 Files Mount Target — Punto de montaje NFS en la subred VPC que conecta la instancia EC2 con el File System de S3 Files.

Metodología

El benchmark sigue un diseño estructurado para garantizar la comparabilidad de resultados entre ambas aproximaciones:

Parámetros de prueba

Operaciones medidas

Para AWS CLI se miden cinco operaciones secuenciales:

• UPLOAD — Envío de 10 archivos al bucket.
• LIST — Listado recursivo del directorio de prueba.
• DOWNLOAD — Descarga de los 10 archivos a disco local.
• HEAD / STAT — Recuperación de metadatos de cada objeto.
• *DELETE — Eliminación de los 10 objetos del bucket.

Para s3fs-fuse y S3 Files se utilizan benchmarks con fio (v3.32) con I/O directo (libaio, direct=1), midiendo:

• IOPS — Operaciones de I/O por segundo sostenidas durante 30 segundos.
• Throughput (MB/s) — Ancho de banda efectivo.
• Latencia (μs) — Latencia media por operación.

La métrica principal es el tiempo total en milisegundos para completar cada operación (10 archivos) en CLI, complementada con IOPS y throughput en MB/s para los mounts FUSE/S3 Files.

Automatización

Todo el ciclo de vida: crear bucket, lanzar instancia, instalar dependencias, compilar s3fs-fuse desde fuente, montar S3 Files, ejecutar las pruebas y generar el CSV de resultados… se orquesta desde un único script que se ejecuta como user-data en el arranque de la instancia.

La infraestructura se encuentra definida como código con Terraform usando dos módulos reutilizables:

• modules/s3-bucket — Crea el bucket con las configuraciones de seguridad.
• modules/ec2-benchmark — Despliega la instancia, el IAM Role, el Security Group y sube el script de benchmark al bucket para que la instancia lo descargue al arrancar.

Componentes

AWS CLI (S3 nativo)

El enfoque nativo utiliza AWS CLI v2 (aws-cli/2.33.15), que internamente realiza llamadas a la API REST de S3. Cada invocación de aws s3 cp implica:

• Inicio de un nuevo proceso Python/CLI.
• Resolución de credenciales desde el servicio de metadatos del profile de la instancia.
• Establecimiento de conexión HTTPS con el endpoint de S3.
• Autenticación mediante firma SigV4.
• Transferencia del contenido (multipart upload para archivos > 8 MB).
• Cierre y limpieza del proceso.

# UPLOAD -- un archivo individual
aws s3 cp "test_10MB_1.dat" "s3://my-bucket/native/test_10MB_1.dat" --no-progress

# LIST -- listado recursivo
aws s3 ls "s3://my-bucket/native/" --recursive

# HEAD -- metadatos de un objeto
aws s3api head-object --bucket "my-bucket" --key "native/test_10MB_1.dat"

Para las operaciones de UPLOAD y DOWNLOAD se itera sobre los 10 archivos secuencialmente, midiendo el tiempo total del bloque completo.

s3fs-fuse

s3fs-fuse (v1.97, compilado desde github.com/s3fs-fuse/s3fs-fuse) monta el bucket S3 como un sistema de archivos FUSE (Filesystem in Userspace), permitiendo acceder a los objetos mediante operaciones POSIX estándar (cp, ls, stat, rm):

# Compilación desde fuente (Amazon Linux 2023)
dnf install -y fuse fuse3 fuse3-devel fuse-devel libcurl-devel \
libxml2-devel gcc-c++ make openssl-devel autoconf automake libtool git

cd /tmp && git clone https://github.com/s3fs-fuse/s3fs-fuse.git
cd s3fs-fuse && ./autogen.sh && ./configure
make -j$(nproc) && make install && ldconfig

# Montaje con credenciales temporales del IAM Role
eval $(aws configure export-credentials --format env)
s3fs "my-bucket" "/mnt/s3" \
-o access_key_id="$AWS_ACCESS_KEY_ID" \
-o secret_access_key="$AWS_SECRET_ACCESS_KEY" \
-o session_token="$AWS_SESSION_TOKEN" \
-o use_cache=/tmp \
-o use_path_request_style \
-o enable_noobj_cache \
-o sigv2

Nota: s3fs-fuse no está disponible como paquete para Amazon Linux 2023, por lo que es necesario compilarlo desde el código fuente en el arranque de la instancia.

Los parámetros de montaje son clave para el rendimiento:

El mecanismo interno de s3fs-fuse traduce cada llamada POSIX a la API correspondiente de S3. Por ejemplo, un cp a un archivo nuevo se traduce en un PUT Object, mientras que un stat se resuelve como HEAD Object.

AWS S3 Files (mount.s3files)

AWS S3 Files es el servicio nativo de Amazon para montar buckets S3 como filesystem, disponible como mount.s3files en Amazon Linux 2023. A diferencia de s3fs-fuse, S3 Files no conecta la instancia EC2 directamente a S3. El flujo de datos real es el siguiente:

La instancia EC2 monta un filesystem mediante el protocolo NFS desde una instancia EFS que actúa como caché de alto rendimiento. Esta caché se encarga de servir una copia local de ficheros y de sincronizar los cambios con el bucket S3.

# Instalación (Amazon Linux 2023)
dnf install -y amazon-efs-utils

# Montaje -- OpenTofu crea el File System y Mount Target en la VPC.
# El benchmark script monta usando el ID del File System:
mount_file_id=$(cat /root/benchmark-results/s3files_fs_id)
/usr/sbin/mount.s3files "${mount_file_id}" /root/s3files-mount

# Verificación del montaje
mount | grep s3files
# fs-0bbbd1d66142be171 on /root/s3files-mount type s3files ...

Características clave de S3 Files:

S3 Files está diseñado para ofrecer consistencia fuerte y operativa simplificada, pero su rendimiento puede diferir significativamente del de s3fs-fuse según el escenario.

Configuración del entorno

El despliegue completo se ejecuta con tres comandos:

# 1. Inicializar OpenTofu
tofu init

# 2. Revisar el plan
tofu plan -var-file=terraform.tfvars

# 3. Desplegar
tofu apply -var-file=terraform.tfvars
Tras el apply, OpenTofu devuelve la IP pública de la instancia. El benchmark arranca automáticamente en menos de un minuto:
Outputs:

instance_public_ip = "<EC2_PUBLIC_IP"
results_location = "/root/benchmark-results/"
ssh_command = "ssh -i <ssh_key>.pem ec2-user@<EC2_PUBLIC_IP>"

Los resultados se guardan en /root/benchmark-results/ con los siguientes archivos:

• results.csv — Datos crudos (test_name, operation, file_size, bw_mbps, iops, lat_us).
• fio_*.json — Logs detallados de fio por método y tamaño de archivo (latencias percentiles, distribución de I/O).
• benchmark.log — Log completo de la ejecución.
• summary.txt — Resumen con configuración y comandos para descargar los resultados.

Resultados

Los datos completos se recopilan en formato CSV. Los resultados de la CLI se miden como tiempo total para 10 operaciones secuenciales, mientras que los resultados de s3fs-fuse y S3 Files se miden con fio en modo sostenido (30 segundos, I/O directo con libaio).

Lectura secuencial — IOPS

Lectura secuencial — Latencia media (μs)

Escritura secuencial — IOPS

Escritura secuencial — Latencia media (μs)

Throughput de lectura (MB/s)

Throughput de escritura (MB/s)

Operaciones AWS CLI — Tiempos totales (ms, 10 archivos)

Análisis de resultados

1 AWS CLI tiene un overhead fijo de ~7-10 segundos

Independientemente del tamaño del archivo (1 KB o 10 MB), las operaciones con AWS CLI muestran un piso constante de 7 a 10 segundos para procesar 10 archivos (es decir, no puede bajar de ese valor). Esto se debe a que cada invocación de aws s3 cp ejecuta un proceso independiente que:

• Inicializa el runtime de Python.
• Carga la configuración de AWS (~/.aws/config, variables de entorno, servicio de metadatos).
• Establece una conexión TLS nueva con el endpoint de S3.
• Calcula la firma SigV4 (que incluye hashing del payload para uploads).

El tamaño del archivo apenas influye porque el coste de establecimiento domina sobre el coste de transferencia real, especialmente con archivos pequeños en una conexión de red suficiente.

2 s3fs-fuse aprovecha el page cache del kernel

La diferencia de rendimiento más dramática (hasta 750x en DELETE) se explica por la caché en memoria. Con la opción use_cache=/tmp, s3fs-fuse almacena en tmpfs (RAM) los archivos descargados. En Amazon Linux 2023, /tmp es un tmpfs montado en memoria, no en disco. Esto significa que el caché compite directamente con la memoria disponible de la instancia. Cuando la prueba descarga los mismos archivos que previamente subió, el kernel satisface las lecturas desde el page cache sin generar tráfico de red.

Esto no es un "engaño", refleja un patrón de uso real: en producción, los mismos archivos se leen frecuentemente más de una vez y el caché de s3fs-fuse elimina la latencia de red en accesos repetidos.

3 S3 Files: consistencia a cambio de rendimiento

AWS S3 Files ofrece un comportamiento fundamentalmente distinto al de s3fs-fuse. Los benchmarks con fio en modo directo (direct=1, libaio) revelan que S3 Files presenta latencias de lectura 7x a 53x superiores y latencias de escritura 8x a 115x superiores respecto a s3fs-fuse:

En archivos grandes (10 MB), la brecha se reduce pero sigue siendo significativa:

La causa principal es el caching en userspace de s3fs-fuse. Incluso con la opción de fio direct=1 (que ignora la page cache del kernel), s3fs-fuse mantiene su propio caché en /tmp a nivel de proceso FUSE, mientras que S3 Files realiza cada petición a través de NFS hacia S3 sin caché intermedio, priorizando la consistencia fuerte de lectura tras escritura. Esta arquitectura de doble salto (EC2 → → EFS → S3) explica parte de la latencia adicional observada en archivos grandes.

4 UPLOAD con s3fs-fuse muestra resultados variables

Los tiempos de UPLOAD con s3fs-fuse fluctúan (35-55 ms) sin correlación directa con el tamaño del archivo. Esto ocurre porque la operación cp a un mount FUSE es asíncrona por defecto: el kernel devuelve éxito cuando los datos entran en el buffer, y s3fs-fuse realiza el PUT a S3 en segundo plano. El sync posterior fuerza la escritura completa, pero la medición captura solo el retorno inicial del cp.

5 LIST es extremadamente rápido con s3fs-fuse

La operación LIST con s3fs-fuse (2-3 ms) es notablemente más rápida que con AWS CLI (721-738 ms) porque el directorio ya está cacheado tras las operaciones anteriores. AWS CLI, en cambio, ejecuta ListObjectsV2 paginado en cada invocación, recorriendo todos los prefijos del bucket.

6 HEAD/STAT: la ventaja del caché de metadatos

La opción enable_noobj_cache permite a s3fs-fuse cachear también las respuestas negativas de HeadObject. Con 15 ms constantes para cualquier tamaño de archivo, s3fs-fuse resuelve los STAT desde caché local mientras que AWS CLI debe hacer 10 llamadas HTTP independientes (una por archivo).

7 La latencia de S3 Files escala con el tamaño de archivo

Una característica distintiva de S3 Files es que su latencia crece proporcionalmente al tamaño del archivo, tanto en lectura como en escritura. Esto es esperable en un sistema sin caché local donde cada operación de I/O debe completarse a través del Mount Target NFS hacia S3 de forma síncrona: EC2 → Mount Target (VPC) → File System → S3. A diferencia de s3fs-fuse, donde la latencia por operación se mantiene baja gracias al caché en memoria local (tmpfs), S3 Files no tiene esa capa intermedia:

• Lectura 1 KB → 686 μs; lectura 10 MB → 67.888 μs (99x más lento)
• Escritura 1 KB → 4.553 μs; escritura 10 MB → 80.100 μs (18x más lento)

En comparación, s3fs-fuse muestra un crecimiento mucho más suave:

• Lectura 1 KB → 34 μs; lectura 10 MB → 8.761 μs (258x, pero partiendo de una base mucho menor)
• Escritura 1 KB → 42 μs; escritura 10 MB → 9.496 μs (226x)

8 A 100 MB: el throughput de S3 Files se acerca al de s3fs-fuse

Los datos de 100 MB revelan un patrón clave: la ventaja de s3fs-fuse se reduce significativamente en archivos grandes. En lectura, el throughput de S3 Files (210 MB/s) se acerca al de s3fs-fuse (1.496 MB/s), reduciendo la brecha de 54x (1 MB) a 7,1x (100 MB). En escritura, la tendencia es similar: S3 Files logra 216 MB/s frente a los 1.027 MB/s de s3fs-fuse, una diferencia de apenas 4,8x.

Este comportamiento es consistente con la arquitectura de S3 Files descrita por AWS: para archivos grandes (≥ 1 MB), las lecturas se transmiten directamente desde S3, bypassando la capa de caché. Como S3 ofrece alto throughput para transferencias secuenciales grandes, el rendimiento converge hacia el ancho de banda de red disponible.

Sin embargo, el throughput de s3fs-fuse en lectura para archivos grandes (1.496 MB/s para 100 MB) sugiere que su caché local sigue ofreciendo datos desde el page cache del kernel, ya que los 1,5 GB/s superan lo que una conexión de red típica puede ofrecer. Esto confirma que las pruebas de fio con direct=1 no bypassan completamente el caché de s3fs-fuse a nivel de proceso FUSE, como sí lo hacen con S3 Files.

9 S3 Files frente a s3fs-fuse en escalabilidad

La siguiente tabla resume cómo evoluciona la latencia de escritura con el tamaño de archivo:

La ventaja de s3fs-fuse disminuye convergentemente: de 108x en 1 KB a solo 4,7x en 100 MB. Esto tiene implicaciones prácticas importantes:

• Para workloads de archivos pequeños (metadata, configs, logs), s3fs-fuse es ineludible: 100x más rápido.
• Para workloads de archivos grandes (videos, datasets, backups), la diferencia se reduce a ~5x, y S3 Files ofrece consistencia fuerte a cambio de ese rendimiento menor.
• Para transfers masivos donde el throughput importa más que la latencia por operación, S3 Files a 216 MB/s de escritura puede ser suficiente para muchos pipelines.

Ventajas y desafíos

Ventajas de AWS CLI (Native S3)

• Simplicidad operativa — No requiere instalación ni compilación adicional. Viene preinstalado en todas las AMIs de Amazon Linux.
• Consistencia fuerte — Cada operación consulta directamente a S3, garantizando datos actualizados.
• Control granular — Soporte completo para todas las opciones de S3: multipart tuning, storage class transitions, tagging, lifecycle policies desde la CLI.
• Sin estado local — No depende de caché ni mounts persistentes. Ideal para pipelines efímeros (CI/CD, Lambda con container).
• Auditable — Cada operación deja un registro explícito en CloudTrail con el user-agent del CLI.

Ventajas de s3fs-fuse

• Rendimiento dramáticamente superior para accesos repetidos gracias al caché local de archivos y metadatos.
• Transparencia para aplicaciones legacy — Cualquier aplicación que funcione con el sistema de archivos POSIX funciona sin modificaciones contra S3.
• Interactividad — Exploración manual del bucket con herramientas estándar (ls, cat, less, grep).
• Integración con herramientas existentes — rsync, tar, find, scripts bash que operan sobre rutas de archivo.

Ventajas de AWS S3 Files

• Consistencia fuerte garantizada — Cada lectura refleja la última escritura sin riesgo de datos desactualizados. Ideal para workloads donde la integridad de datos es crítica.
• Gestión de credenciales simplificada — Resuelve automáticamente el IAM Role del instance profile sin necesidad de inyectar credenciales temporales manualmente.
• Protocolo NFS con Mount Target gestionado — S3 Files utiliza NFSv4.1 para comunicarse con un Mount Target en la VPC sin pasar por FUSE. AWS gestiona el endpoint de conectividad a S3, evitando el overhead del context switch kernel/userspace que introduce FUSE.
• Soporte oficial de AWS — Mantenido por Amazon, con integración nativa en Amazon Linux 2023 y soporte técnico.
• Instalación simple — Disponible como paquete del sistema (amazon-efs-utils) sin necesidad de compilar desde fuente.

Desafíos de s3fs-fuse

• Consistencia eventual — El caché local puede servir datos stale si el bucket se modifica desde otra fuente. La invalidación manual es necesaria en escenarios multi-escritura.
• Complejidad de montaje — Requiere compilar desde fuente en Amazon Linux 2023 (dependencias: fuse3-devel, autoconf, automake, libtool). Las credenciales temporales del IAM Role deben inyectarse explícitamente porque s3fs-fuse no siempre resuelve iam_role=auto correctamente.
• Limitaciones POSIX — No soporta renombrado atómico, hard links, ni operaciones que requieran locking de archivos. Las operaciones de directorio pueden ser lentas en buckets con millones de objetos.
• Gestión del ciclo de vida del mount — Las reconexiones tras fallos de red requieren scripts de monitorización o systemd mount units con x-systemd.automount.
• Overhead de memoria — El proceso s3fs consume memoria proporcional al número de objetos cacheados, lo que puede ser significativo en instancias con recursos limitados (como la t3.micro de este benchmark).

Desafíos de AWS S3 Files

• Rendimiento inferior a s3fs-fuse — Sin caché local, cada operación de I/O incurre en latencia de red contra S3. En nuestro benchmark, S3 Files muestra de 7x a 115x menos IOPS que s3fs-fuse, y latencias 7x a 108x superiores.
• Latencia proporcional al tamaño de archivo — Sin caching intermedio, el tiempo de cada operación escala linealmente con el tamaño del objeto, lo que impacta especialmente en archivos grandes (62 ms por lectura de 10 MB vs 8,7 ms en s3fs-fuse).
• Disponibilidad limitada — AWS S3 Files no está disponible en todas las regiones. Si la región no soporta S3 Files, la opción directamente no existe.
• IOPS limitados en archivos pequeños — Con solo ~1.400 IOPS de lectura para archivos de 1 KB, S3 Files queda muy por debajo de los ~30.500 de s3fs-fuse, lo que lo hace inadecuado para workloads intensivos en metadata.

Desafíos de AWS CLI

• Rendimiento por archivo — Cada archivo implica un proceso completo. Para transferencias masivas de archivos pequeños, el overhead domina sobre el tiempo de transferencia real.
• Sin caché nativo — Cada aws s3 cp descarga vuelve a solicitar los datos a S3, incluso si el archivo no ha cambiado.
• Limitaciones para aplicaciones legacy — Las aplicaciones que esperan rutas de archivo POSIX no pueden usar la CLI directamente sin un wrapper o adapter layer.

Casos de uso en producción

Más allá de los números del benchmark, estos son los escenarios donde cada método encaja mejor:

Entrenamiento ML con datasets en S3

Con S3 Files, podemos montar petabytes de datos de entrenamiento directamente como filesystem sin duplicarlos en volúmenes EBS. Los workers de entrenamiento (hasta 25.000 simultáneos) acceden a los datos como archivos locales y los grandes batches de entrenamiento se transmiten directamente desde S3.

Recomendación: S3 Files para la accesibilidad compartida; s3fs-fuse si la latencia por epoch es crítica y es tolerable la consistencia eventual.

Workspaces colaborativos para agentes de IA

Sistemas multi-agente donde cada agente lee y escribe logs, estado y memoria en un directorio compartido de S3. Hasta 25.000 recursos (EC2, Lambda, EKS pods) pueden conectarse al mismo filesystem simultáneamente.

Recomendación: S3 Files — consistencia fuerte para escrituras concurrentes y acceso bidireccional S3 ↔ NFS.

Pipelines ETL batch

Procesos que descargan archivos de S3, los transforman y los suben de vuelta. No necesitan un mount persistente.

Recomendación: AWS CLI — simplicidad, sin estado local, sin montajes que gestionar.

Exploración interactiva de buckets

Data scientists y devops que necesitan navegar un bucket con ls, cat, grep, find sin montar nada permanentemente.

Recomendación: s3fs-fuse — la caché local ofrece respuestas instantáneas para accesos repetidos, y la interactividad POSIX es insuperable.

Procesamiento de archivos grandes (> 100 MB)

Videos, datasets de imágenes, backups donde el throughput importa más que la latencia por operación.

Recomendación: S3 Files o s3fs-fuse — a 100 MB, la diferencia de throughput se reduce a 5-7x. Preferir S3 Files si se necesita consistencia fuerte o acceso simultáneo desde múltiples instancias.

Conclusión

Este benchmark demuestra que la elección entre AWS CLI nativo, s3fs-fuse y AWS S3 Files depende fundamentalmente del patrón de acceso, el tamaño de archivo y los requisitos de consistencia:

1. Para workloads batch de un solo uso (ETL, backups, migraciones puntuales), AWS CLI es la opción más sencilla y predecible, con consistencia fuerte y sin estado local.
2. Para accesos interactivos frecuentes o aplicaciones que esperan un filesystem, s3fs-fuse ofrece mejoras de rendimiento de 7x a 115x en IOPS sobre S3 Files, y latencias 7x a 108x inferiores, gracias al caché local, a cambio de gestionar la consistencia eventual y el lifecycle del mount.
3. Para workloads que requieren consistencia fuerte con escrituras concurrentes y acceso filesystem, S3 Files ofrece garantías de lectura tras escritura sin necesidad de gestionar cachés, pero con un rendimiento significativamente inferior en archivos pequeños: 1.452 IOPS de lectura para archivos de 1 KB frente a los 30.546 de s3fs-fuse, y latencias de escritura de 4,5 ms frente a 42 μs.
4. Para transferencias de archivos grandes (100 MB+), S3 Files converge hacia el throughput de s3fs-fuse: a 100 MB, S3 Files alcanza 210 MB/s de lectura (7,1x menos que s3fs-fuse), lo que puede ser aceptable cuando la consistencia fuerte es prioritaria.

Un punto clave a considerar es que los resultados de s3fs-fuse se benefician significativamente del caché de lectura. En escenarios de primera lectura (cold cache), los tiempos de descarga serán comparables a los de AWS CLI y S3 Files, ya que las tres aproximaciones deben transferir los datos desde S3 a través de la red.

La incorporación de S3 Files al benchmark revela que no existe una solución universalmente superior: s3fs-fuse sacrifica consistencia por rendimiento, S3 Files sacrifica rendimiento en archivos pequeños por consistencia y simplicidad operativa, y AWS CLI ofrece simplicidad operativa sin montaje de filesystem. La elección debe alinearse con los requisitos específicos de cada workload.

La infraestructura completa de este benchmark está disponible como módulo de OpenTofu reutilizable en este repositorio, lista para desplegar en cualquier cuenta AWS con una configuración mínima.

¿Has realizado benchmarks similares en tu infraestructura? ¿Qué estrategia usas para acceder a S3 desde tus aplicaciones? Cuéntanos tu experiencia en los comentarios.

Referencias

• AWS S3 Files Documentation — Guía completa del servicio, arquitectura, sincronización y performance.
• AWS News Blog: S3 Files GA Announcement — Anuncio de disponibilidad general (7 de abril de 2026).
• AWS Terraform provider: Release v6.40.0 - Versión del proveedor de Terraform con soporte para S3Files.
• S3 Files Performance Specifications — Especificaciones de throughput, latencia y límites.
• S3 Files Pricing — Costes de almacenamiento en caché, acceso a datos y sincronización.
• s3fs-fuse GitHub Repository — Documentación y opciones de montaje de s3fs-fuse.
• fio — Flexible I/O Tester — Herramienta de benchmark de I/O utilizada en las pruebas.
• Tutorials Dojo: Amazon S3 Files — Análisis conceptual de la arquitectura de S3 Files.