Eu respondi a mesma pergunta no Stack Overflow .
O s3fs é de fato uma solução razoável e, no meu caso, associei-o ao proftpd com excelentes resultados, apesar dos problemas teóricos / potenciais.
Na época em que escrevi a resposta, eu havia configurado isso apenas para um de meus clientes de consultoria ... mas desde então também comecei a beber meu próprio kool-aid e o uso na produção em meu trabalho diário. Empresas com as quais trocamos dados com upload e download de arquivos o dia inteiro no meu servidor sftp, que armazena tudo diretamente no S3. Como bônus, meu sistema de exportação de relatórios - que grava planilhas do Excel diretamente no S3 - pode exportar relatórios "para o servidor FTP" simplesmente colocando-os diretamente no bucket do servidor ftp, com metadados apropriados para mostrar o uid, gid e modo de cada arquivo. (o s3fs usa os cabeçalhos x-amz-meta-uid, -gid e -mode para emular as permissões do sistema de arquivos). Quando o cliente faz logon no servidor, os arquivos de relatório estão apenas ... lá.
Eu acho que a solução ideal provavelmente seria um serviço de gateway sftp para S3, mas ainda não consegui projetar um, pois essa solução funciona muito bem ... com algumas ressalvas, é claro:
Nem todos os valores padrão para s3fs são sensatos. Você provavelmente desejará especificar estas opções:
-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
Provavelmente, é melhor usar uma região que não seja o padrão dos EUA, porque é a única região que não oferece consistência de leitura após gravação em novos objetos. (Ou, se você precisar usar o US-Standard, poderá usar o nome your-bucket.s3-external-1.amazonaws.comde host quase não documentado da região us-east-1 para impedir que seus pedidos sejam roteados geograficamente, o que pode melhorar a consistência.)
Eu tenho a versão de objeto ativada no bucket, da qual o s3fs não tem conhecimento. A vantagem disso é que, mesmo que um arquivo seja "pisoteado", sempre posso acessar a versão do bucket para recuperar o arquivo "substituído". A versão do objeto no S3 foi projetada de maneira brilhante, de forma que os clientes do S3 que não têm conhecimento de versão não sejam de modo algum desabilitados ou confusos, porque se você não fizer chamadas REST com reconhecimento de versão, as respostas retornadas pelo S3 serão compatíveis com os clientes que possuem nenhum conceito de versionamento.
Observe também que a transferência de dados para o S3 está livre de taxas de transferência de dados. Você paga apenas o preço por solicitação. A transferência de dados do S3 para o EC2 em uma região também está livre de taxas de transferência de dados. Somente quando você transfere o S3 para a Internet, para o Cloudfront ou para outra região da AWS é que paga as taxas de transferência. Se você deseja usar o armazenamento de redundância reduzida com preço mais baixo, o s3fs suporta isso com -o use_rrs.
Como uma parte divertida, você sempre terá uma sensação de aconchego ao ver os 256 terabytes de espaço livre (e 0 usados, uma vez que um cálculo real de tamanhos é impraticável devido ao fato de o S3 ser um armazenamento de objetos, não um sistema de arquivos )
$ 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
Obviamente, você pode montar o balde em qualquer lugar. Acabei de tê-lo em / srv / s3fs.