Permítanme comenzar con una introducción rápida a la arquitectura de un sistema que estoy considerando migrar a S3 + Cloudfront.Contenido privado en la nube + arquitectura de URL firmada
Tenemos un numero de entidades ordenadas en un árbol. Las hojas del árbol tienen varios recursos (imágenes jpg para ser específicas), generalmente del orden de 20-5000, con un promedio de ~ 200. Cada recurso tiene una URL única que se sirve a través de nuestra configuración colo hoy.
Podría simplemente transferir todos estos recursos a S3, configurar Cloudfront además de eso y listo. Si tan solo no tuviera que proteger los recursos.
La mayoría de las entidades son públicas (es decir, ~ 99%), el resto af protegido de una de muchas maneras (inicio de sesión, ip, tiempo, etc.). Una vez que una entidad está protegida, todos los recursos deben estar protegidos también, y solo se puede acceder después de que se haya realizado una autorización válida.
Pude resolver esto creando dos contenedores S3, uno privado y otro público. Para el contenido privado generaría URL Cloudfront firmadas después de que se autorizara al usuario. Sin embargo, el estado de una entidad puede cambiar arbitrariamente de público a privado, y viceversa. Un administrador del sistema puede cambiar una entidad en cualquier nivel del árbol de entidades, causando un cambio en cascada en todo el árbol. Un cambio podría causar un cambio de ~ 20k entidades, multiplicado por 200 recursos, que afectaría a 4 millones de recursos.
Podría ejecutar un servicio en el control de fondo para cambios de estado, pero sería engorroso, y cambiar las ACL de 4 millones de elementos S3 tomaría un tiempo considerable, y mientras eso ocurra tendremos contenido privado desprotegido, o contenido público para el que tendremos que generar URL firmadas.
Otra posibilidad sería hacer todos los recursos privados por defecto. En cada solicitud hecha a una entidad, generaríamos una política personalizada que otorgue acceso, para ese usuario específico, a todos los recursos contenidos en la entidad (mediante el uso de comodines en la política personalizada). Esto requeriría la creación de una política para cada visitante, por entidad; sin embargo, eso no sería un problema. Sin embargo, eso significaría que nuestros usuarios ya no pueden guardar nada en la memoria caché, ya que la URL cambiará para cada nueva sesión. Si bien no es un problema para el contenido privado, sería malo para nosotros deshacernos de todo el almacenamiento en caché para el ~ 99% de las entidades que son públicas.
Otra opción sería mantener todo el contenido privado y utilizar el enfoque anterior para las entidades privadas. Para las entidades públicas, podríamos generar una única política personalizada, por entidad pública, que todos los usuarios compartirían. Si fijamos una vida útil de 6 horas y nos aseguramos de generar una nueva política después de 5 horas, se garantizará a un usuario una vida útil de la política de al menos una hora. Esto tiene la ventaja de permitir el almacenamiento en caché de hasta 6 horas, mientras que permite que el contenido privado, posiblemente, sea público durante hasta 6 horas después de un cambio de estado. Esto sería aceptable, pero no estoy seguro de que valga la pena (tratando de calcular la proporción de caché/aciertos de las solicitudes actualmente). Obviamente, podríamos ajustar el borde de 5/6 horas para habilitar el caché más largo/más corto a costa de una exposición más larga/más corta a entidades privadas.
¿Alguien ha implementado una solución similar? ¿Alguna de las características de AWS que estoy pasando por alto que podría ser de utilidad? ¿Algún comentario en general?
@Marque su edición realmente vale la pena una respuesta ¡Yo también habría votado! –
En función de sus comentarios, eliminé la parte editada y agregué una respuesta. ¡Gracias! –