J'ai répondu à cette même question sur Stack Overflow .
s3fs est en effet une solution raisonnable, et dans mon cas, je l'ai couplé avec proftpd avec d'excellents résultats, malgré les problèmes théoriques / potentiels.
Au moment où j'ai écrit la réponse, je n'avais mis cela en place que pour l'un de mes clients consultants ... mais depuis lors, j'ai également commencé à boire mon propre kool-aid et je l'utilise en production dans mon travail de jour. Les entreprises que nous échangeons des données avec téléchargement et téléchargement de fichiers toute la journée sur mon serveur sftp, qui stocke tout directement sur S3. En prime, mon système d'exportation de rapports - qui écrit directement des feuilles de calcul Excel vers S3 - peut exporter des rapports «vers le serveur FTP» en les plaçant simplement directement dans le compartiment du serveur ftp, avec les métadonnées appropriées pour afficher l'uid, le gid et mode de chaque fichier. (s3fs utilise les en-têtes x-amz-meta-uid, -gid et -mode pour émuler les autorisations du système de fichiers). Lorsque le client se connecte au serveur, les fichiers de rapport sont juste ... là.
Je pense que la solution idéale serait probablement un service de passerelle sftp vers S3, mais je n'ai toujours pas réussi à en concevoir un, car cette solution fonctionne très bien ... avec quelques mises en garde, bien sûr:
Les valeurs par défaut de s3fs ne sont pas toutes saines. Vous voudrez probablement spécifier ces options:
-o enable_noobj_cache # s3fs has a huge performance hit for large directories without this enabled
-o stat_cache_expire=30 # the ideal time will vary according to your usage
-o enable_content_md5 # it's beyond me why this safety check is disabled by default
Il est probablement préférable d'utiliser une région autre que US-Standard, car c'est la seule région qui n'offre pas de cohérence de lecture après écriture sur les nouveaux objets. (Ou, si vous devez utiliser US-Standard, vous pouvez utiliser le nom your-bucket.s3-external-1.amazonaws.comd' hôte presque non documenté de la région us-east-1 pour empêcher le géo-routage de vos demandes, ce qui peut améliorer la cohérence.)
J'ai le versionnage d'objet activé sur le compartiment, que s3fs ignore complètement. L'avantage de ceci est que même si un fichier doit être "écrasé", je peux toujours aller au bucketing pour récupérer le fichier "écrasé". La gestion des versions des objets dans S3 a été brillamment conçue de telle manière que les clients S3 qui ne connaissent pas la gestion des versions ne sont en aucun cas désactivés ou confus, car si vous ne faites pas d'appels REST prenant en charge la gestion des versions, les réponses renvoyées par S3 sont compatibles avec les clients qui ont aucun concept de versioning.
Notez également que le transfert de données vers S3 est exempt de frais de transfert de données. Vous ne payez que le prix par demande. Le transfert de données de S3 vers EC2 dans une région est également exempt de frais de transfert de données. Ce n'est que lorsque vous transférez de S3 vers Internet, vers Cloudfront ou vers une autre région AWS que vous payez des frais de transfert. Si vous souhaitez utiliser le stockage à redondance réduite moins cher, s3fs le prend en charge avec -o use_rrs.
En passant, vous aurez toujours une sensation floue et chaleureuse lorsque vous voyez les 256 téraoctets d'espace libre (et 0 utilisé, car un vrai calcul de tailles est impossible en raison du fait que S3 est un magasin d'objets, pas un système de fichiers ).
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.9G 1.4G 6.2G 18% /
s3fs 256T 0 256T 0% /srv/s3fs/example-bucket
Bien sûr, vous pouvez monter le godet n'importe où. Il se trouve que je l'ai dans / srv / s3fs.