servidores - Mejores prácticas de implementación de Amazon S3 Cloudfront

como funciona cloudfront

Question

Nuestro plan actual para un sitio es utilizar el servicio Cloudfront de Amazon como un CDN para archivos de activos como CSS, JavaScript e Imágenes, y cualquier otro archivo estático.

Actualmente tenemos 1 segmento en S3 que contiene todos estos archivos estáticos. Los archivos están separados en diferentes carpetas dependiendo de lo que sean, "Scripts" son archivos JS, "Imágenes" son Imágenes, etc. yadda yadda yadda.

Entonces, lo que no me di cuenta desde el principio fue que una vez que implementas un Bucket de S3 a una Distribución de Cloudfront, entonces cada actualización posterior del Bucket no se implementará nuevamente en esa misma Distribución. Por lo tanto, parece que debe volver a implementar el depósito en otra instancia de Cloudfront cada vez que tenga una actualización de archivos estáticos.

Eso está bien para las imágenes, porque podemos asegurarnos fácilmente de que si hay un cambio en una imagen, entonces simplemente creamos una nueva imagen. Pero eso es difícil de hacer para CSS y JS.

Entonces, eso me lleva a las preguntas de la mejor práctica:

1. ¿Es una mejor práctica crear otra distribución de Cloudfront para cada implementación de producción? El problema aquí sería que causa problemas con los registros CNAME.
2. ¿Es una buena práctica NO almacenar CSS y JS en Cloudfront debido a la naturaleza de esos archivos, y su necesidad de ser modificados fácilmente? Parece que la respuesta a esto sería NO porque ese es el propósito de un CDN.
3. ¿Hay algún otro método con Cloudfront que no sepa?

Answer 1

CloudFront ha comenzado a admitir cadenas de consulta, que puede usar para invalidar el caché. http://aws.typepad.com/aws/2012/05/amazon-cloudfront-support-for-dynamic-content.html

Answer 2

Puede emitir solicitudes de invalidación a CloudFront.

http://docs.amazonwebservices.com/AmazonCloudFront/latest/DeveloperGuide/Invalidation.html

En lugar de un cubo S3, utilizamos nuestro propio servidor como un origen personalizado. Tenemos .htaccess alias style_*.css style.css to style.css , e style.css el tiempo de modificación del archivo para style.css en el HTML. Como CloudFront ve una URL totalmente diferente, buscará la nueva versión.

(Nota: algunos CDN le permiten hacer eso a través de una cadena de consulta, pero CloudFront ignora todos los datos de cadena de consulta para el almacenamiento en caché, de ahí la solución .htaccess ).

editar: CloudFront se puede (opcionalmente) configurar para usar cadenas de consulta ahora.