amazon-web-services - services - aws que significa
Múltiples orígenes de Cloudfront con redirección de ruta de comportamiento (1)
Actualización: la respuesta a continuación es precisa cuando se escribió en 2015 y está basada en el comportamiento integrado de CloudFront.
Sin embargo, la introducción de Lambda @ Edge en 2017 cambia la dinámica.
Lambda @ Edge le permite declarar ganchos de activación en el flujo de CloudFront y escribir pequeñas funciones de Javascript que inspeccionan y pueden modificar la solicitud entrante, antes de que se compruebe la caché de CloudFront (solicitud del visor) o después de que se marque la caché (solicitud de origen). Esto le permite volver a escribir la ruta en el URI de solicitud. Podría, por ejemplo, transformar una ruta de solicitud desde el navegador de /download/images/cat.png para eliminar /download , lo que da como resultado que se envíe una solicitud a S3 (o un diseño personalizado) para /images/cat.png .
Esta opción no modifica qué Cache Behavior realmente servirá la solicitud, porque esto siempre se basa en la ruta solicitada por el navegador, pero puede modificar la ruta en vuelo para que el objeto solicitado real se encuentre en una ruta diferente. que el solicitado por el navegador.
Para anteponer un prefijo a la solicitud del navegador, la configuración de la ruta de origen puede seguir utilizándose, como se indica a continuación, pero para eliminar o modificar los componentes de ruta se requiere Lambda @ Edge.
Sí, los patrones deben existir en el origen.
CloudFront, de forma nativa. puede preceder a la ruta para un origen dado, pero actualmente no tiene la capacidad de eliminar elementos de la ruta (sin Lambda @ Edge, como se indicó anteriormente).
Si sus archivos estaban en /secret/files/ en el origen, podría hacer que el patrón de ruta /files/* transformara antes de enviar la solicitud al origen configurando la "ruta de origen".
Lo opuesto no es verdad Si los archivos estaban en /files en el origen, no hay una forma integrada de servir esos archivos desde path pattern /download/files/* .
Puede agregar (prefijo) pero no quitar.
Una solución relativamente simple sería un servidor proxy inverso en una instancia EC2 en la misma región que el cubo S3, apuntando CloudFront al proxy y el proxy a S3. El proxy volvería a escribir la solicitud HTTP en su camino a S3 y transmitirá la respuesta resultante a CloudFront. Utilizo una configuración como esta y nunca me ha decepcionado con su rendimiento. (El software de proxy inverso que desarrollé puede verificar múltiples cubos en paralelo o en serie y devolver la primera respuesta sin errores que recibe a CloudFront y al solicitante).
O bien, si utiliza los puntos finales del sitio web S3 como orígenes personalizados, puede usar las reglas de enrutamiento de redirección S3 para devolver un redireccionamiento a CloudFront, enviando de nuevo el navegador con el prefijo no administrado eliminado. Esto significaría una solicitud adicional para cada objeto, lo que aumentaría un poco la latencia y el costo, pero las reglas de redirección S3 se pueden configurar para que se activen solo cuando la solicitud no coincide realmente con un archivo en el depósito. Esto es útil para la transición de una estructura jerárquica a otra.
http://docs.aws.amazon.com/AmazonS3/latest/dev/HowDoIWebsiteConfiguration.html
Tengo dos contenedores S3 que sirven como mis servidores de origen Cloudfront:
example-bucket-1
example-bucket-2
El contenido de ambos contenedores vive en la raíz de esos segmentos. Estoy intentando configurar mi distribución de Cloudfront para enrutar o reescribir en función de un patrón de URL. Por ejemplo, con estos archivos
example-bucket-1/something.jpg
example-bucket-2/something-else.jpg
Me gustaría hacer que estas URL apunten a los respectivos archivos
http://example.cloudfront.net/path1/something.jpg
http://example.cloudfront.net/path2/something-else.jpg
Traté de configurar los comportamientos de caché que coinciden con los patrones path1 y path2, pero no funciona. ¿Los patrones tienen que existir realmente en el cubo S3?