Acceso FTP / SFTP a un cubo Amazon S3

¿Hay alguna forma de conectarse a un cubo de Amazon S3 con FTP o SFTP en lugar de la interfaz de transferencia de archivos incorporada de Amazon en la consola de AWS? Parece extraño que esta no sea una opción disponible.

Simplemente monte la cubeta utilizando el sistema de archivos s3fs (o similar) a un servidor Linux (por ejemplo, Amazon EC2) y use el servidor SFTP integrado del servidor para acceder al depósito.

  • Instale el s3fs
  • Agregue sus credenciales de seguridad en un formulario access-key-id:secret-access-key a /etc/passwd-s3fs
  • Agregue una entrada de assembly de cubeta a fstab :

      /mnt/ fuse.s3fs rw,nosuid,nodev,allow_other 0 0 

Para más detalles, consulte mi guía Configuración de un acceso SFTP a Amazon S3 .


O use cualquier “cliente FTP / SFTP” gratuito , que también sea un “cliente S3” , y no tenga nada configurado en el servidor. Por ejemplo, mi WinSCP o Cyberduck .

Hay razones teóricas y prácticas por las cuales esta no es una solución perfecta, pero funciona …

Puede instalar un servicio FTP / SFTP (como proftpd) en un servidor Linux, ya sea en EC2 o en su propio centro de datos … luego monte un segmento en el sistema de archivos donde el servidor ftp está configurado para chroot, usando s3fs .

Tengo un cliente que sirve contenido de S3, y el contenido es proporcionado por un tercero que solo soporta ftp push … así que, con cierta vacilación (debido a la impedancia no coincidente entre S3 y un sistema de archivos real) pero que falta el momento de escribir un paquete de software de servidor de puerta de enlace FTP / S3 adecuado (que todavía tengo la intención de hacer uno de estos días), propuse y desplegué esta solución para ellos hace varios meses y no han informado ningún problema con el sistema.

Como beneficio adicional, dado que proftpd puede juntar a cada usuario en su propio directorio de inicio y “pretender” (hasta donde el usuario puede saber) que los archivos propiedad del usuario proftpd son realmente propiedad del usuario conectado, esto segrega a cada usuario de ftp en un “subdirectorio” de la categoría y hace que los archivos de los demás usuarios sean inaccesibles.


Sin embargo, hay un problema con la configuración predeterminada.

Una vez que empiezas a obtener algunas decenas o cientos de archivos, el problema se manifestará cuando hagas una lista de directorios, porque ProFTPd intentará leer los archivos .ftpaccess una y otra vez, y para cada archivo en el archivo. directorio, .ftpaccess se verifica para ver si el usuario debe poder verlo.

Puede deshabilitar este comportamiento en ProFTPd, pero sugeriría que la configuración más correcta es configurar opciones adicionales -o enable_noobj_cache -o stat_cache_expire=30 en s3fs:

-o stat_cache_expire (el valor predeterminado no expira)

especificar el tiempo de expiración (segundos) para las entradas en la memoria caché de estadísticas

Sin esta opción, hará menos solicitudes a S3, pero tampoco siempre descubrirá los cambios realizados en los objetos si los procesos externos u otras instancias de s3fs también están modificando los objetos en el depósito. El valor “30” en mi sistema se seleccionó de forma un tanto arbitraria.

-o enable_noobj_cache (el valor predeterminado es deshabilitar)

habilitar las entradas de caché para el objeto que no existe. s3fs siempre tiene que verificar si el archivo (o subdirectorio) existe bajo el objeto (ruta) cuando s3fs realiza algún comando, ya que s3fs ha reconocido un directorio que no existe y tiene archivos o subdirectorios debajo de sí mismo. Aumenta la solicitud ListBucket y hace que el rendimiento sea malo. Puede especificar esta opción para el rendimiento, s3fs memoriza en el caché de estadísticas que el objeto (archivo o directorio) no existe.

Esta opción permite a s3fs recordar que .ftpaccess no estaba allí.


Sin relación con los problemas de rendimiento que pueden surgir con ProFTPd, que se resuelven con los cambios anteriores, también debe habilitar -o enable_content_md5 en s3fs.

-o enable_content_md5 (el valor predeterminado es deshabilitar)

verificar los datos cargados sin multiparte por el encabezado content-md5. Habilite el envío del encabezado “Content-MD5” al cargar un objeto sin publicación múltiple. Si esta opción está habilitada, tiene algunas influencias en el rendimiento de s3fs al cargar un objeto pequeño. Como s3fs siempre verifica MD5 al cargar objetos grandes, esta opción no afecta al objeto grande.

Esta es una opción que nunca debería haber sido una opción: siempre debe estar habilitada, ya que al no hacer esto, se pasa por alto una verificación de integridad crítica para un beneficio de rendimiento insignificante. Cuando un objeto se carga en S3 con un Content-MD5: S3 validará la sum de comprobación y rechazará el objeto si está dañado en tránsito. Por improbable que sea, parece miope desactivar este control de seguridad.

Las citas son de la página man de s3fs. Los errores gtwigticales están en el texto original.

Bueno, S3 no es FTP. Sin embargo, hay muchos clientes que admiten S3.

Casi todos los clientes notables de FTP en OS X tienen soporte, incluidos Transmit y Cyberduck .

Si está en Windows, eche un vistazo a Cyberduck o CloudBerry .

O gire la instancia de Linux para SFTP Gateway en su infraestructura de AWS que guarda los archivos cargados en su depósito de Amazon S3.

Apoyado por Thorntech

Filezilla acaba de lanzar una versión Pro de su cliente FTP. Se conecta a las cubetas S3 en una experiencia de FTP optimizada. Lo uso yo mismo (sin afiliación alguna) y funciona muy bien.