Respondi esta mesma pergunta no Stack Overflow .
s3fs é de fato uma solução razoável e, no meu caso, eu o integrei ao proftpd com excelentes resultados, apesar dos problemas teóricos / potenciais.
Na época em que escrevi a resposta, eu só tinha configurado isso para um dos meus clientes de consultoria ... mas desde então, eu também comecei a beber meu próprio kool-aid e o estou usando na produção no meu dia trabalho. Empresas trocamos dados com upload e download de arquivos o dia todo no meu servidor sftp, que está armazenando tudo diretamente no S3. Como bônus, meu sistema de exportação de relatórios - que grava planilhas do Excel diretamente para o 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. (s3fs usa cabeçalhos x-amz-meta-uid, -gid e -mode para emular as permissões do sistema de arquivos). Quando o cliente se conecta ao servidor, os arquivos de relatório estão ... ali.
Eu acho que a solução ideal seria provavelmente um serviço de gateway sftp para S3, mas eu ainda não consegui projetar um, já que esta solução funciona muito bem ... com algumas ressalvas, é claro:
Nem todos os valores padrão para s3fs são sãos. Você provavelmente desejará especificar essas 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 diferente da US-Standard, porque essa é 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 padrão americano, poderá usar o nome de host quase não documentado your-bucket.s3-external-1.amazonaws.com da região us-east-1 para impedir que suas solicitações sejam roteadas geograficamente, o que pode melhorar a consistência.)
Eu tenho o controle de versão de objeto ativado no bucket, o qual o s3fs não sabe. O benefício disso é que, mesmo que um arquivo seja "invadido", sempre posso ir para o controle de versão do bucket para recuperar o arquivo "sobrescrito". O versionamento de objetos no S3 foi brilhantemente projetado de tal forma que os clientes do S3 que não estão cientes de versionamento não são de forma alguma desabilitados ou confusos, porque se você não fizer chamadas REST com reconhecimento de versão, as respostas retornadas pelo S3 são compatíveis com clientes que possuem nenhum conceito de versionamento.
Note também que transferência de dados S3 está livre dos custos de transferência de dados. Você paga apenas o preço por solicitação. A transferência de dados do S3 para o EC2 dentro de uma região também é isenta de encargos de transferência de dados. É somente quando você transfere do S3 para a Internet, para a Cloudfront ou para outra região da AWS que você paga taxas de transferência. Se você quiser usar o armazenamento de redundância reduzida com preço mais baixo, o s3fs suporta isso com -o use_rrs .
Como um divertimento à parte, você sempre terá uma sensação de conforto ao ver os 256 terabytes de espaço livre (e 0 usados, já que um cálculo real de tamanhos é impraticável porque o S3 é 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
Claro, você pode montar o balde em qualquer lugar. Por acaso, eu tenho isso em / srv / s3fs.