Contrôler le contenu en cache et invalider une mise à jour

Introduction

Une version peut être correctement enregistrée dans S3 alors que la distribution renvoie encore une copie précédente. Réglez la durée du cache, observez sa réutilisation et son expiration, puis invalidez uniquement le chemin de la page mise à jour. Conservez le cache d'un second objet et le caractère privé de l'origine.

Terminez d'abord le laboratoire de diffusion de contenu S3 privé. Cette VM indépendante fournit un nouveau compartiment privé, un OAC, une distribution et la stratégie correspondante. Elle ne réutilise aucune ressource d'une autre VM. Le cache est initialement désactivé, sans requête utilisateur ni invalidation. Les fichiers préparés permettent de se concentrer sur le cache. Consultez l'état réel dans AWS View, en haut, et exécutez les commandes dans Terminal, en bas. Aucun compte AWS personnel ni domaine public n'est nécessaire.

Objectifs de certification

Certification	Tâche de l'examen	Pratique
Solutions Architect – Associate (SAA-C03)	Tâche 3.4	Pratiquer la diffusion de contenu avec CloudFront et observer l'effet de la durée du cache sur les lectures de l'origine.

Vue d'ensemble du laboratoire

Schéma conceptuel : réutiliser une version en cache, puis invalider son chemin exact pour obtenir le contenu actualisé de l'origine tout en conservant un autre objet en cache.

Observer la réutilisation et l'expiration du cache

Dans cette étape, réglez une courte durée pour distinguer une réponse provenant du cache d'une nouvelle lecture de l'origine.

Un cache conserve une copie pour les requêtes suivantes. Le TTL est sa durée de validité en secondes. Le Cache-Control: max-age de l'objet fournit cette durée ; les TTL minimal et maximal de la distribution l'encadrent, et le TTL par défaut s'applique lorsque l'origine n'en indique pas. Nous utilisons les paramètres ordinaires de la distribution sans créer de stratégie de cache séparée.

Identifiez la distribution préparée. --query sélectionne celle portant le commentaire du laboratoire, et $(...) enregistre son ID ou son domaine dans une variable shell. Gardez Terminal ouvert. Consultez le compartiment de référence sans le modifier :

cd /home/labex/project
DIST_ID=$(aws cloudfront list-distributions \
  --query "DistributionList.Items[?Comment=='labex-n03:private-content'].Id | [0]" \
  --output text)
DIST_DOMAIN=$(aws cloudfront get-distribution \
  --id "$DIST_ID" \
  --query Distribution.DomainName \
  --output text)
aws s3api list-buckets \
  --query 'Buckets[].Name'

Lisez la configuration actuelle et son ETag, l'identifiant de version nécessaire pour une mise à jour sûre. > écrit la sortie dans un fichier. sed modifie uniquement les deux attributs TTL initialement à zéro ; le minimum reste zéro. Le nouveau maximum autorise des durées plus longues ensuite :

aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query DistributionConfig > current-config.json
ETAG=$(aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query ETag \
  --output text)
sed -e 's/"DefaultTTL": 0/"DefaultTTL": 6/'   -e 's/"MaxTTL": 0/"MaxTTL": 3600/'   current-config.json > cached-config.json
aws cloudfront update-distribution \
  --id "$DIST_ID" \
  --if-match "$ETAG" \
  --distribution-config file://cached-config.json
aws cloudfront wait distribution-deployed \
  --id "$DIST_ID"

Chargez la première version préparée avec une durée de six secondes. Conservez le type de contenu text/html :

aws s3api put-object \
  --bucket labex-n03-content \
  --key index.html \
  --body index.html \
  --content-type text/html \
  --cache-control 'max-age=6'

curl --include affiche les en-têtes et le corps. --resolve dirige le véritable nom de distribution vers le point d'accès de cette VM sans changer le DNS système. Lancez les deux requêtes à la suite pour que la seconde arrive avant six secondes :

curl --fail --include --noproxy '*'   --resolve "${DIST_DOMAIN}:8082:127.0.0.1"   "http://${DIST_DOMAIN}:8082/index.html"
curl --fail --include --noproxy '*'   --resolve "${DIST_DOMAIN}:8082:127.0.0.1"   "http://${DIST_DOMAIN}:8082/index.html"

La première affiche X-Cache: Miss from cloudfront, la seconde Hit from cloudfront, et toutes deux renvoient Release one. Un succès de cache réutilise les octets conservés sans relire l'origine. Age indique l'âge de la copie ; deux requêtes immédiates peuvent afficher zéro seconde.

sleep 7 laisse expirer la copie de six secondes avant une nouvelle requête :

sleep 7
curl --fail --include --noproxy '*'   --resolve "${DIST_DOMAIN}:8082:127.0.0.1"   "http://${DIST_DOMAIN}:8082/index.html"

Attendez un nouveau défaut de cache avec la même page. L'expiration fait relire l'origine à la prochaine requête ; elle ne supprime pas l'objet S3. AWS View montre les requêtes réelles et le nombre de lectures de l'origine. Exécutez la vérification avant de continuer.

Exemple après expiration : les requêtes réelles montrent défaut, succès puis défaut de cache, avec deux lectures de l'origine.

Observer une mise à jour derrière une copie en cache

Dans cette étape, chargez une nouvelle version et observez pourquoi une copie en cache renvoie encore l'ancien contenu.

Des durées plus longues rendent le phénomène facile à observer. Rechargez la première page avec max-age=900, puis l'objet indépendant stable.txt avec max-age=3600. Le maximum de 3600 de la distribution autorise ces deux valeurs :

aws s3api put-object \
  --bucket labex-n03-content \
  --key index.html \
  --body index.html \
  --content-type text/html \
  --cache-control 'max-age=900'
aws s3api put-object \
  --bucket labex-n03-content \
  --key stable.txt \
  --body stable.txt \
  --content-type text/plain \
  --cache-control 'max-age=3600'

Modifier les métadonnées de l'origine ne change pas rétroactivement une réponse en cache. Attendez l'expiration de la copie de six secondes, puis chargez le cache des deux chemins :

sleep 7
curl --fail --include --noproxy '*'   --resolve "${DIST_DOMAIN}:8082:127.0.0.1"   "http://${DIST_DOMAIN}:8082/index.html"
curl --fail --include --noproxy '*'   --resolve "${DIST_DOMAIN}:8082:127.0.0.1"   "http://${DIST_DOMAIN}:8082/stable.txt"

Les deux requêtes présentent un défaut de cache et lisent les objets actuels de l'origine. La page inclut maintenant Cache-Control: max-age=900. Terminez les deux étapes suivantes dans cette période de quinze minutes.

Le fichier préparé release-two.html contient la page modifiée. Chargez-le sous la même clé d'objet en conservant le type et la durée. Avec la CLI S3 authentifiée, lisez l'objet dans origin-release.html pour voir ses octets réels :

cat release-two.html
aws s3api put-object \
  --bucket labex-n03-content \
  --key index.html \
  --body release-two.html \
  --content-type text/html \
  --cache-control 'max-age=900'
aws s3api get-object \
  --bucket labex-n03-content \
  --key index.html origin-release.html
cat origin-release.html

L'origine contient Release two. Demandez le même chemin à la distribution :

curl --fail --include --noproxy '*'   --resolve "${DIST_DOMAIN}:8082:127.0.0.1"   "http://${DIST_DOMAIN}:8082/index.html"

Attendez un succès de cache renvoyant Release one. Le chargement a réussi, mais la copie de la distribution reste valide selon son propre TTL. Cela diffère d'un refus d'accès à l'origine. Exécutez la vérification de l'ancienne copie.

Exemple avant invalidation : la dernière requête de page provient du cache ; l'objet indépendant est en cache et n'a nécessité qu'une lecture de l'origine.

Invalider uniquement la page modifiée

Dans cette étape, rendez la nouvelle version visible avant l'expiration sans vider le cache de l'objet indépendant.

Une invalidation retire du cache de la distribution les objets correspondants. Le chemin est celui demandé par l'utilisateur, commençant par /, et non un nom de compartiment ou de fichier local. Utilisez exactement /index.html ; /* retirerait inutilement l'autre objet aussi.

Créez la demande. Le raccourci CLI --paths fournit le lot, et la requête enregistre son ID dans une variable :

INVALIDATION_ID=$(aws cloudfront create-invalidation \
  --distribution-id "$DIST_ID" \
  --paths '/index.html' \
  --query Invalidation.Id \
  --output text)
aws cloudfront wait invalidation-completed \
  --distribution-id "$DIST_ID" \
  --id "$INVALIDATION_ID"
aws cloudfront get-invalidation \
  --distribution-id "$DIST_ID" \
  --id "$INVALIDATION_ID" \
  --query 'Invalidation.{Status:Status,Paths:InvalidationBatch.Paths.Items}'

Confirmez Completed et /index.html. Un lot terminé ne prouve pas, à lui seul, les octets reçus par l'utilisateur. Demandez la page deux fois pour vérifier le nouveau contenu et sa réutilisation :

curl --fail --include --noproxy '*'   --resolve "${DIST_DOMAIN}:8082:127.0.0.1"   "http://${DIST_DOMAIN}:8082/index.html"
curl --fail --include --noproxy '*'   --resolve "${DIST_DOMAIN}:8082:127.0.0.1"   "http://${DIST_DOMAIN}:8082/index.html"

Attendez un défaut de cache avec Release two, puis un succès avec la même nouvelle page. La première requête lit les octets actuels de l'origine et la seconde réutilise la nouvelle copie.

Demandez l'objet indépendant et répétez le test anonyme direct sur l'origine :

curl --fail --include --noproxy '*'   --resolve "${DIST_DOMAIN}:8082:127.0.0.1"   "http://${DIST_DOMAIN}:8082/stable.txt"
curl --noproxy '*' --output /dev/null   --write-out 'Anonymous origin: HTTP %{http_code}\n'   http://127.0.0.1:5000/labex-n03-content/index.html

stable.txt doit toujours provenir du cache avec son contenu original, sans nouvelle lecture de l'origine. L'accès S3 anonyme doit encore renvoyer HTTP 403. L'invalidation modifie le cache, pas les autorisations de l'origine. Exécutez la vérification de mise à jour ciblée.

Exemple après invalidation exacte : défaut puis succès pour la page ; stable.txt reste en cache avec une seule lecture de l'origine.

Supprimer uniquement vos ressources de diffusion

Dans cette étape, désactivez et supprimez d'abord la distribution, puis l'OAC et le contenu S3. Conservez le compartiment de référence.

CloudFront utilise ETag comme jeton de version de la configuration. Récupérez la configuration et l'ETag actuels ; ne devinez pas le jeton.

Avant de supprimer la distribution, lisez son ID d'OAC. Cette variable conserve le contrôle exact à nettoyer :

OAC_ID=$(aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query 'DistributionConfig.Origins.Items[0].OriginAccessControlId' \
  --output text)

Enregistrez maintenant la configuration actuelle et récupérez son ETag :

aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query DistributionConfig \
  --output json > distribution-current.json
DIST_ETAG=$(aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query ETag \
  --output text)

Dans la configuration actuelle de ce laboratoire, Enabled de la distribution est le seul attribut de ce nom valant true. Cette substitution standard avec sed produit une copie désactivée en conservant les paramètres de l'origine :

sed 's/"Enabled": true/"Enabled": false/' distribution-current.json > distribution-disabled.json
aws cloudfront update-distribution \
  --id "$DIST_ID" \
  --if-match "$DIST_ETAG" \
  --distribution-config file://distribution-disabled.json

Attendez le déploiement de la configuration désactivée. La propagation AWS peut prendre du temps ; ce laboratoire ne mesure pas le délai mondial de déploiement :

aws cloudfront wait distribution-deployed \
  --id "$DIST_ID"

La mise à jour change l'ETag. Lisez le dernier jeton avant de supprimer la distribution désactivée :

DIST_ETAG=$(aws cloudfront get-distribution-config \
  --id "$DIST_ID" \
  --query ETag \
  --output text)
aws cloudfront delete-distribution \
  --id "$DIST_ID" \
  --if-match "$DIST_ETAG"

Supprimez l'OAC avec son propre ETag. L'ID de distribution et celui de l'OAC désignent des ressources différentes :

OAC_ETAG=$(aws cloudfront get-origin-access-control \
  --id "$OAC_ID" \
  --query ETag \
  --output text)
aws cloudfront delete-origin-access-control \
  --id "$OAC_ID" \
  --if-match "$OAC_ETAG"

Supprimez uniquement les deux objets du laboratoire et leur compartiment :

aws s3api delete-object \
  --bucket labex-n03-content \
  --key index.html
aws s3api delete-object \
  --bucket labex-n03-content \
  --key stable.txt
aws s3api delete-bucket \
  --bucket labex-n03-content
aws s3api list-buckets \
  --query 'Buckets[].Name'

Le compartiment de référence doit rester et celui du contenu doit être absent. AWS View doit montrer aucune distribution de contenu et uniquement l'objet de référence. Exécutez la vérification du nettoyage. Un échec de requête API ne prouve pas une suppression.

Exemple après nettoyage : seule la référence indépendante reste ; l'historique des requêtes et des lectures de l'origine est toujours visible.

Résumé

Vous avez réglé les limites TTL et Cache-Control, observé qu'un succès de cache n'ajoute aucune lecture de l'origine et laissé expirer une copie courte. Vous avez montré qu'une nouvelle version dans l'origine ne remplace pas une copie utilisateur encore valide. L'invalidation du chemin exact a récupéré la nouvelle page tout en conservant l'autre cache et l'origine privée. Vous avez ensuite supprimé uniquement vos ressources. Pour des versions fréquentes, des noms d'objet versionnés permettent aussi de sélectionner le nouveau contenu ; ici, vous avez mis à jour un chemin existant.