¿Es seguro montar cubos S3 directamente en instancias EC2?

Como dice el título de mi pregunta, me gustaría saber si es una buena práctica o no,

Sé que puedo montarlo en una instancia EC2, pero me preguntaba si, ya que agregaré más instancias para escalar mi aplicación, esto podría causar algunos problemas; ¿Tienes alguna experiencia con esto?

Estoy usando S3 para permitir la carga de archivos a través de un script PHP, así que básicamente la pregunta es:

¿Es una buena práctica usar el enrutamiento o hay mejores formas de manejar las cargas de archivos de usuario?

Gracias por adelantado

Si está utilizando S3 para almacenar datos de las cargas de usuarios, especialmente en un entorno distribuido, una gran consideración es el hecho de que S3 es 'eventualmente consistente' (aunque algunas regiones son consistentes de lectura después de escritura). La consecuencia de esto es que puede cargar un archivo con éxito, pero si verifica su existencia inmediatamente después, puede encontrar que no existe. Este problema es más pronunciado para escenarios como actualizaciones o eliminaciones, donde incluso la coherencia de lectura después de escritura no ayudará.

Lo anterior se aplicará a sus cargas a S3 independientemente del enfoque que adopte. De hecho, esto es cierto para la mayoría de los problemas que uno podría esperar de S3: no es tanto el enfoque utilizado para almacenar los datos, sino las limitaciones de S3 que probablemente serán las más problemáticas.

S3fs usa la API S3, al igual que el SDK de PHP (u otro). Además, S3 está diseñado para manejar niveles bastante altos de concurrencia, por lo que (aparte de los problemas de coherencia) no debería haber problemas para montarlo en varias instancias (teniendo en cuenta que no es un sistema de archivos tradicional, problemas como el bloqueo, etc se manejan en el lado S3).

Dicho esto, hay algunas ventajas y desventajas potenciales de cada implementación:

S3fs:

• No hay soporte para descargas parciales / fragmentadas (hasta donde yo sé), por lo que debe descargar el archivo completo para leer cualquier parte del mismo, probablemente no sea un problema si solo lo está utilizando para almacenar (y servir) cargas.
• Escrito en C ++ posibles ganancias de rendimiento
• Su aplicación se beneficia de cualquier actualización de s3fs
• Implementa el almacenamiento en caché (tanto de archivos completos como de información de archivos): tiene el potencial de mejorar un poco la velocidad y reducir los costos
• Limitado a las funciones que expone el fusible

SDK:

• Expone el conjunto completo de características que S3 tiene para ofrecer; dependiendo de su caso de uso, esto puede ser suficiente para merecer el uso del SDK
• Integración potencialmente más estrecha con su aplicación: los errores devueltos, etc. pueden permitir que su aplicación tome decisiones mejor informadas (y, por lo tanto, más precisas)
• Es necesario codificar todas las ventajas posibles: su aplicación debe aprovecharlas y mantenerse actualizado con futuros cambios en S3
• Más complejidad y gastos generales para su código.

En términos de 'seguridad', podría significar 'evitar la corrupción de datos' o 'evitar el acceso no autorizado'. Con respecto al primero, el SDK podría ayudar un poco para lidiar con la consistencia eventual (en forma de errores más detallados), pero el almacenamiento subyacente es el mismo, y espero que las diferencias sean menores. Con respecto al control de acceso, puede usar IAM para crear una cuenta limitada, pero esa cuenta aún necesitará acceso de lectura / escritura a sus archivos S3. Ambos deben ser adecuadamente seguros, en cualquier caso, su sistema debe verse comprometido para obtener acceso a su bucket de S3; sin embargo, sugeriría que con S3fs (ya que las credenciales generalmente se almacenan fuera del webroot y no son accesibles a través de PHP) hay una seguridad ligeramente mejor.

Opinión personal: preferiría s3fs para un caso en el que hay un único directorio de carga (por ejemplo, un sitio que lo utiliza) y donde el acceso será bastante simple (solo es necesario cargar archivos y ocasionalmente actualizar / eliminar). Si va a necesitar un acceso más complejo (por ejemplo, descargas parciales, múltiples buckets, etc.) o va a usar el SDK de S3 para otros fines, entonces me quedaría con el SDK para las cargas también.

Preferiría subir a S3 a través de PHP lib. Es más fácil que montar S3 en cada servidor.

Mira este ejemplo: http://aws.amazon.com/code/126

Para uno de mis proyectos utilicé esta biblioteca: http://undesigned.org.za/2007/10/22/amazon-s3-php-class . Me funcionó muy bien.

Puede permitir que los usuarios carguen directamente a s3 desde el navegador sin cargar en su servidor (y luego cargar a s3).

Aquí hay algunos buenos consejos para esto: https://leonid.shevtsov.me/post/demystifying-s3-browser-upload/

después de cargar el archivo, si necesita procesar el archivo (zip, transcodificar, etc.) puede usar S3fs