Atualizar
O S3 agora oferece um serviço de gateway SFTP totalmente gerenciado para o S3, que se integra ao IAM e pode ser administrado usando o aws-cli.
Existem razões teóricas e práticas para essa não ser uma solução perfeita, mas funciona ...
Você pode instalar um serviço FTP / SFTP (como proftpd) em um servidor linux, no EC2 ou em seu próprio data center ... e montar um bucket no sistema de arquivos em que o servidor ftp está configurado para chroot, usando s3fs .
Eu tenho um cliente que serve conteúdo fora do S3, e o conteúdo é fornecido a eles por terceiros que apenas suportam pushs FTP ... então, com alguma hesitação (devido à incompatibilidade de impedância entre o S3 e um sistema de arquivos real), mas faltando Na hora de escrever um pacote de software de servidor de gateway FTP / S3 adequado (que ainda pretendo fazer um dia desses), propus e implantei essa solução para eles há vários meses e eles não relataram nenhum problema com o sistema.
Como um bônus, como o proftpd pode fazer o chroot de cada usuário em seu próprio diretório inicial e "fingir" (até onde o usuário sabe) que os arquivos pertencentes ao usuário proftpd são realmente de propriedade do usuário logado, isso separa cada usuário ftp em um "subdiretório" do bucket e torna os arquivos dos outros usuários inacessíveis.
Há um problema com a configuração padrão, no entanto.
Depois que você começar a obter algumas dezenas ou centenas de arquivos, o problema se manifestará quando você abrir uma lista de diretórios, porque o ProFTPd tentará ler os .ftpaccessarquivos repetidamente e novamente e para cada arquivo no diretório, .ftpaccessestá marcado para ver se o usuário deve poder vê-lo.
Você pode desativar esse comportamento no ProFTPd, mas eu sugiro que a configuração mais correta seja configurar opções adicionais -o enable_noobj_cache -o stat_cache_expire=30no s3fs:
-o stat_cache_expire (o padrão é não expirar)
especifique o tempo de expiração (segundos) para entradas no cache de estatísticas
Sem essa opção, você fará menos solicitações ao S3, mas nem sempre descobrirá com segurança as alterações feitas nos objetos se processos externos ou outras instâncias do s3fs também estiverem modificando os objetos no bucket. O valor "30" no meu sistema foi selecionado de forma arbitrária.
-o enable_noobj_cache (o padrão é desativar)
habilitar entradas de cache para o objeto que não existe. O s3fs sempre precisa verificar se o arquivo (ou subdiretório) existe no objeto (caminho) quando o s3fs executa algum comando, pois o s3fs reconheceu um diretório que não existe e possui arquivos ou subdiretórios. Aumenta a solicitação ListBucket e prejudica o desempenho. Você pode especificar esta opção para desempenho, o s3fs memoriza no cache de estatísticas que o objeto (arquivo ou diretório) não existe.
Esta opção permite que o s3fs se lembre de que .ftpaccessnão estava lá.
Independentemente dos problemas de desempenho que podem surgir com o ProFTPd, resolvidos pelas alterações acima, você também precisa habilitar -o enable_content_md5no s3fs.
-o enable_content_md5 (o padrão é desativar)
verificação de dados enviados sem multipartes pelo cabeçalho content-md5. Ative o envio do cabeçalho "Content-MD5" ao fazer upload de um objeto sem postagem de várias partes. Se essa opção estiver ativada, ela terá alguma influência no desempenho do s3fs ao fazer upload de objetos pequenos. Como o s3fs sempre verifica o MD5 ao fazer upload de objetos grandes, essa opção não afeta o objeto grande.
Essa é uma opção que nunca deveria ter sido uma opção - deve sempre estar ativada, porque não fazer isso ignora uma verificação crítica de integridade, apenas para um benefício insignificante de desempenho. Quando um objeto é carregado no S3 com um Content-MD5:cabeçalho, o S3 validará a soma de verificação e rejeitará o objeto se ele estiver corrompido em trânsito. Por mais improvável que seja, parece míope desativar essa verificação de segurança.
As cotações são da página de manual do s3fs. Erros gramaticais estão no texto original.