Tengo una aplicación web estática (SPA) implementada en S3 y sirvo la aplicación mediante CloudFront y enruto el dominio mediante Route53. Ahora, quiero que Route53 y cloudFront tengan el TTL máximo en sus respectivos cachés. Hay unapregunta similar como esta, pero está desactualizada.
Mis preguntas:
¿Establecer la memoria caché de CloudFront en un año (365 días) es bueno y cuando se producen nuevas actualizaciones en S3, podemos invalidar la memoria caché mediante la API o la consola?
Suponiendo que el registro de alias no cambia con frecuencia, ¿es correcto configurar el caché Route53 NS en 2 días (48 horas) ? Si tenemos que cambiar, entonces debemos ser precavidos y esperar 2 días para reflexionar.
Creo que establecer la caché de Route53 y CloudFront al máximo brindará la mejor experiencia (baja latencia) a los usuarios. Por favor corrígeme si estoy equivocado.
P1: si está bastante seguro de que su objeto vive tanto tiempo, entonces podría estar bien usar el caché de CloudFront durante 1 año. Siempre puede invalidar sus objetos usando la consola web o usando un script como este:
#!/bin/sh aws configure set preview.cloudfront true INVALIDATION_ID=$(date +"%S") INVALIDATION_JSON="{ \"DistributionId\": \"<YOUR_DISTRIBUTION_ID>\", \"InvalidationBatch\": { \"Paths\": { \"Quantity\": 1, \"Items\": [ \"/*\" ] }, \"CallerReference\": \"$INVALIDATION_ID\" } }" aws cloudfront create-invalidation --cli-input-json "$INVALIDATION_JSON"Tenga en cuenta que si necesita invalidar, NO PUEDE invalidar el caché del navegador de los usuarios. Por lo tanto, solo elegiría una configuración alta como esa para los archivos, de los cuales estoy absolutamente seguro de que no cambiarán (por ejemplo, Videos).
Me resultó útil elegir mi tiempo de caché de acuerdo con lo que recomienda Google. Encontrarás algunas entradas aquí .
Sin embargo, no almacenaría en caché un SPA con tanta fuerza: supongo que tendrá cambios con bastante frecuencia allí.
P2: Creo que es una buena práctica general poner el TTL de la Ruta 53 en un número más alto. Solo recuerde que no puede cambiar el DNS tan rápido entonces. Por lo general, antes de un cambio de DNS, simplemente baje el TTL a un número más bajo con unos días de anticipación. Como está utilizando AWS, con Alias-Resources esto no debería ser un gran problema, los cambios de DNS se realizan sin problemas.
En términos generales, estoy de acuerdo con tu enfoque. Sacrificas algo de flexibilidad, pero generalmente vale la pena.