actualización 2014-11:
Como señala Alan Illing en los comentarios, AWS ahora soporta notificaciones de S3 a SNS, que se pueden reenviar automáticamente a SQS: http://aws.amazon.com/blogs/aws/s3-event-notification/
S3 también puede enviar notificaciones a AWS Lambda para ejecutar su propio código directamente.
respuesta original que predijo notificaciones S3-> SNS:
Si Amazon apoyó esta, que utilizarían SNS para enviar notificaciones que un objeto ha sido añadido a un cubo. Sin embargo, en este momento, el único evento de depósito admitido por S3 y SNS es para notificarlo cuando Amazon S3 detecta que ha perdido todas las réplicas de un objeto de almacenamiento reducido de redundancia (RRS) y ya no puede atender las solicitudes de ese objeto.
Aquí está la documentación sobre los acontecimientos del SNS con el apoyo de S3:
http://docs.amazonwebservices.com/AmazonS3/latest/dev/NotificationHowTo.html
Sobre la base de la forma en que la documentación está escrito, parece que Amazon tiene ideas para otros eventos de notificación para añadir (como quizás su idea para saber cuándo se han agregado nuevas claves).
Dado que no es compatible directamente con Amazon, el cliente S3 que cargue el objeto a S3 tendrá que activar la notificación, o tendrá que hacer algún tipo de votación.
La notificación de eventos personalizados para cargas en S3 se puede hacer usando SNS si desea obtener actualizaciones casi en tiempo real para el procesamiento, o puede hacerse a través de SQS si desea permitir que las notificaciones se acumulen y procesen de una cola a su propio ritmo.
Si está encuestando, puede reducir la cantidad de claves que necesita solicitar haciendo que el cliente cargue con un prefijo de, por ejemplo, "sin procesar/..." seguido de la clave única. Su software de sondeo puede consultar solo las claves S3 comenzando con ese prefijo.Cuando esté listo para procesar, podría cambiar la clave para "procesar/..." y luego para "procesar/..." o lo que sea. Los objetos en S3 se renombran actualmente mediante operaciones de copia + eliminación realizadas por S3.
Para volúmenes de objetos más pequeños, el prefijo del nombre funcionará bien. Para grandes volúmenes de objetos, esto realmente ralentizará S3. S3 particiona internamente los datos en función del nombre del cubo/clave del objeto, y las claves con el mismo prefijo probablemente terminen en la misma partición. Para un alto rendimiento de carga, debe mantener las teclas de objeto cambiando al principio de la cadena. Vea esto para más detalles: http://aws.typepad.com/aws/2012/03/amazon-s3-performance-tips-tricks-seattle-hiring-event.html – dlaidlaw
@dlaidlaw: según lo describe Amazon, puede fácilmente maneja ráfagas de más de 100 solicitudes por segundo, incluso sin una distribución de prefijos especial de las teclas. Si está procesando su cola entrante más rápido que eso, puede simplemente usar un depósito "sin procesar" en lugar del prefijo. Sin embargo, a esa velocidad es probable que esté utilizando procesadores paralelos, en cuyo punto se rompe la sugerencia de tener una sola lista de archivos no procesados que son sondeados (¿cómo sabe qué subproceso está procesando qué archivo?). –
Para un rendimiento muy alto, escribo un mensaje a SQS que contiene el URI en el archivo en S3. Múltiples hilos pueden procesar la cola SQS. Sí, hay una sobrecarga al escribir el mensaje SQS, pero es necesario y se distribuye en todos los hilos que envían archivos a S3. Sería mucho mejor si Amazon tuviera un indicador para enviar un mensaje SNS en create en S3, que luego podría suscribir una cola SQS para distribuir la carga entre los hilos, pero hasta entonces debe escribir sus propios mensajes en SNS o SQS. – dlaidlaw