amazon web services - pricing - Latencia de Amazon CloudFront

cloudfront virus (3)

Estoy experimentando con AWS S3 y CloudFront para una aplicación web que estoy desarrollando.

En la aplicación, dejo que los usuarios carguen archivos en el bucket de S3 (usando el SDK de AWS) y lo pongan a disposición a través de CloudFront CDN, pero el problema es incluso cuando los archivos se cargan y están listos en el bucket de S3, demora aproximadamente un minuto o 2 para estar disponible en la URL de CDN de CloudFront, ¿es esto normal?

¿Se están escribiendo estos nuevos archivos en S3 por primera vez o se actualizan a los archivos existentes? S3 proporciona coherencia de lectura después de escritura para nuevos objetos, y dado el modelo de extracción de CloudFront, no debería tener este problema con los nuevos archivos escritos en S3. Si es así, abriría un boleto con AWS.

Si se trata de actualizaciones de archivos existentes, entonces tiene que lidiar con la consistencia eventual S3 y la caducidad de la caché de CloudFront. Ambos podrían causar este tipo de comportamiento.

CloudFront intenta recuperar contenido no almacenado en caché del servidor de origen en tiempo real. No hay "retraso de replicación" o un problema similar porque CloudFront es un CDN extraíble. Cada ubicación de borde de CloudFront solo conoce la existencia y configuración de su sitio; no conoce su contenido hasta que recibe solicitudes para él. Cuando eso sucede, el borde de CloudFront obtiene el contenido solicitado del servidor de origen y lo almacena en caché, según corresponda, para atender solicitudes posteriores.

El problema que está ocurriendo aquí está relacionado con un concepto que a veces se denomina "almacenamiento en caché negativo" (almacenamiento en caché del hecho de que una solicitud no funcionará), que generalmente se hace para evitar martillar el origen de lo que se almacena en caché con solicitudes que es probable que fallen de todas formas.

De forma predeterminada, cuando su origen devuelve un código de estado HTTP 4xx o 5xx, CloudFront almacena en caché estas respuestas de error durante cinco minutos y luego envía la siguiente solicitud del objeto a su origen para ver si el problema que causó el error se ha resuelto y si se solicitó El objeto ya está disponible.

^{-

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html}

Si el navegador, o cualquier otra cosa, intenta descargar el archivo desde ese borde de CloudFront en particular antes de que se complete la carga en S3, S3 devolverá un error y CloudFront, en esa ubicación de borde, guardará ese error en caché y recordará, por los siguientes 5 minutos, para no molestarse en intentarlo nuevamente.

Sin embargo, no se preocupe: este temporizador es configurable, por lo que si el navegador está haciendo esto bajo el capó y fuera de su control, aún así debería poder solucionarlo.

Puede especificar la duración del almacenamiento en caché de errores (TTL mínimo de almacenamiento en caché de errores) para cada código de estado 4xx y 5xx que CloudFront almacena en caché. Para ver un procedimiento, consulte Configuración del comportamiento de respuesta de error .

^{-

http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/custom-error-pages.html}

Para configurar esto en la consola :

Cuando vea la configuración de distribución, haga clic en la pestaña Error Pages .
Para cada error en el que desee personalizar el tiempo, comience haciendo clic en Create Custom Error Response .
Elija el código de error que desea modificar de la lista desplegable, como 403 (Prohibido) o 404 (No encontrado): su configuración de depósito determina qué código S3 devuelve para los objetos que faltan, así que si no está seguro, cambie 403 luego repita el proceso y cambie 404.
Establezca Error Caching Minimum TTL (seconds) a 0
Deje la opción Customize Error Response establecida en No (si se establece en Yes , esta opción habilita el contenido de respuesta personalizada en caso de errores, que no es lo que desea. La activación de esta opción está fuera del alcance de esta pregunta)
Haz clic en Create . Esto lo lleva de vuelta a la vista anterior, donde verá Error Caching Minimum TTL para el código que acaba de definir.

Repita estos pasos para cada código de respuesta HTTP que desee cambiar del comportamiento predeterminado (que es el tiempo de espera de 300 segundos, discutido anteriormente).

Cuando haya realizado todos los cambios que desee, regrese a la pantalla principal de la consola de CloudFront donde se enumeran las distribuciones. Espere a que el estado de distribución cambie de In Progress a Deployed (generalmente unos 20 minutos para que los cambios se envíen a todos los bordes) y pruebe.

Como se observó en su comentario, parece que Google Chrome está estropeando su estrategia de carga / vista previa:

Chrome está solicitando la URL que actualmente no tiene el contenido.
Cloudfront almacena en caché la solicitud con una respuesta no válida
Subes el archivo a S3
Al obtener una vista previa del archivo cargado, Cloudfront responde con la respuesta en caché (paso 2).
después de que la caché de Cloudfront caduca, Cloudfront llega al origen y el problema ya no puede ser reproducible.