Se você estiver usando o S3 para armazenar dados de uploads de usuários, especialmente em um ambiente distribuído, uma grande consideração é o fato de o S3 ser 'eventualmente consistente' (embora algumas regiões sejam consistentes de leitura após gravação). A conseqüência disso é que você pode fazer upload de um arquivo com êxito, mas se verificar sua existência imediatamente a seguir, poderá achar que ele não existe. Esse problema é mais pronunciado em cenários como atualizações ou exclusões, nas quais a consistência de leitura após gravação não ajudará.
O acima será aplicado aos seus envios para o S3, independentemente da abordagem adotada. De fato, isso é verdade para a maioria dos problemas que se pode esperar do S3 - não é tanto a abordagem usada para armazenar os dados, mas as limitações do S3 que provavelmente serão as mais problemáticas.
O S3fs usa a API do S3 - assim como o SDK do PHP (ou outro). Além disso, o S3 foi projetado para lidar com níveis bastante altos de simultaneidade - portanto (além dos problemas de consistência), não deve haver um problema para montá-lo em várias instâncias (lembrando que não é um sistema de arquivos tradicional - problemas como bloqueio, etc são tratados no lado S3).
Dito isto, existem algumas vantagens e desvantagens em potencial de cada implementação:
S3fs:
- Não há suporte para downloads parciais / em partes (tanto quanto eu sei) - portanto, você deve fazer o download do arquivo completo para ler qualquer parte dele - provavelmente não será um problema se você estiver usando apenas para armazenar (e servir) envios.
- Escrito em possíveis ganhos de desempenho em C ++
- Seu aplicativo se beneficia de qualquer atualização para o s3fs
- Implementa o cache (arquivos completos e informações sobre arquivos) - tem o potencial de melhorar um pouco a velocidade e reduzir custos
- Limitado às funções que o fusível expõe
SDK:
- Expõe o conjunto completo de recursos que o S3 tem a oferecer - dependendo do seu caso de uso, isso pode ser suficiente para merecer o uso do SDK
- Integração potencialmente mais rigorosa ao seu aplicativo - os erros retornados etc. podem permitir que seu aplicativo faça escolhas mais bem informadas (e, portanto, mais precisas)
- Quaisquer vantagens possíveis precisam ser codificadas - seu aplicativo deve tirar proveito delas e ser atualizado com futuras alterações no S3
- Mais complexidade e sobrecarga no seu código
Em termos de 'segurança', você pode significar 'prevenção de corrupção de dados' ou 'prevenção de acesso não autorizado'. Com relação ao primeiro, o SDK pode ajudar um pouco para lidar com a consistência eventual (na forma de erros mais detalhados), mas o armazenamento subjacente é o mesmo e espero que as diferenças sejam menores. Com relação ao controle de acesso - você pode usar o IAM para criar uma conta limitada, mas essa conta ainda precisará de acesso de leitura / gravação aos seus arquivos S3. Ambos devem ser adequadamente seguros, em ambos os casos, seu sistema precisa ser comprometido para obter acesso ao seu bucket S3 - eu sugiro, no entanto, que com o S3fs (já que as credenciais são tipicamente armazenadas fora da raiz da web e não são acessíveis de maneira alguma via PHP) existe uma segurança um pouco melhor.
Opinião pessoal: eu preferiria o s3fs para um caso em que haja um único diretório de upload (por exemplo, um site fazendo uso dele) e onde o acesso seja bastante simples (basta fazer upload de arquivos e ocasionalmente atualizar / excluir). Se você precisar de acesso mais complexo (por exemplo, downloads parciais, vários buckets, etc.) ou usar o SDK do S3 para outros fins, eu também ficaria com o SDK para os uploads.