Общая идея заключается в том, что вы используете TTL для установки политики, которую CloudFront использует для определения максимального времени, в течение которого каждый отдельный объект может потенциально обслуживаться из кэша CloudFront без дальнейшего взаимодействия с источником.
По умолчанию TTL : максимальное время, в течение которого объект может сохраняться в кэше CloudFront, не считаясь устаревшим, если соответствующая директива Cache-Control не предоставлена источником.Заголовок Cache-Control не добавляется в ответ CloudFront.
Минимальный TTL : если источник предоставляет значение Cache-Control: s-maxage (или, если его нет, тоCache-Control: значение максимального возраста) меньше этого, CloudFront игнорирует его и предполагает, что он может сохранить объект в кэше не дольше, чем это.Например, если минимальный TTL установлен на 900, но ответ содержит Cache-Control: max-age=300, CloudFront игнорирует 300 и может кэшировать объект до 900 секунд.Заголовок Cache-Control не изменяется и возвращается зрителю в том виде, в котором он был получен.
Максимальный TTL : если источник предоставляет директиву Cache-Control, указывающую, что объект может кэшироваться дольшечем это, CloudFront игнорирует директиву и предполагает, что объект не должен продолжать обслуживаться из кэша дольше, чем Максимальный TTL.
См. Указание того, как долго объекты остаются в CloudFront Edge Cache (срок действия) в Руководстве разработчика по Amazon CloudFront.
Итак, эти три значения управляют тем, что CloudFront использует для определения того, является ли кэшированный ответ все еще «достаточно свежим», чтобы быть возвращенным последующим зрителям.Это не означает, что CloudFront удаляет кэшированный объект после истечения TTL.Вместо этого CloudFront может сохранить объект, но не будет обслуживать его после истечения срока действия без предварительной отправки запроса к источнику, чтобы узнать, изменился ли объект.
CloudFront не проверяет источник заранеедля новых версий объектов, срок действия которых истек - он только проверяет, запрашиваются ли они снова, пока они все еще находятся в кэше, а затем определено, что срок их действия истек.Когда он делает это, он обычно отправляет условный запрос, используя такие директивы, как If-Modfied-Since.Это дает источнику возможность ответить 304 Not Modified, что говорит CloudFront о том, что кэшированный объект все еще пригоден для использования.
Недоразумение, которое иногда возникает из-за того, что TTL указывает CloudFront, как долго кэшировать объекты.Это не то, что он делает.Он сообщает CloudFront, как долго разрешено кэшировать ответ без повторной проверки относительно источника.Хранение в кэш-памяти внутри CloudFront не связано с зарядом, а кэш-память по определению эфемерна, поэтому редко запрашиваемые объекты могут быть удалены из кэша до истечения срока действия их TTL.
Если объект в пограничном местоположении не часто запрашивается, CloudFront может выселить объект - удалить объект до истечения срока его действия - чтобы освободить место для объектов, которые были запрошены совсем недавно.
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/Expiration.html
При следующем запросе CloudFront снова запросит объект у источника.
Еще одно недоразумение заключается в том, что кэш CloudFront является монолитным.Это не так.Каждый из глобальных ребер имеет свой собственный независимый кеш, кеширующий объекты в ребрах, через которые они запрашиваются.Каждое глобальное ребро также имеет восходящий региональный кэш (в ближайшем регионе EC2; может быть более одного на регион, но это не задокументировано), где также будет храниться объект, что позволяет другим соседним глобальным ребрам находить объект вближайший региональный кеш, но CloudFront больше не ищет, внутри, кешированные объекты.Что касается производительности, он просто обращается к источнику при промахе кэша.
См. Как CloudFront работает с региональными пограничными кэшами .
Аннулирование совершенно иное, и его следует использовать экономно - только первые 1000 недействительных путей , отправляемых каждый месяц аккаунтом AWS, бесплатны.(Путь может соответствовать многим файлам, а путь /* соответствует всем файлам в дистрибутиве.)
Запрос на аннулирование имеет временную метку, когда была создана недействительная программа, и отправляет сообщение во все регионы, направляячтобы они делали что-то вроде этого (точный алгоритм не задокументирован, но это точно описывает чистый эффект):
- Удалите все файлы, соответствующие
${path}, из вашего кэша, если они были кэшированы ранее${timestamp} и - Между тем, поскольку это может занять некоторое время, если вы получаете какие-либо запросы на файлы, соответствующие
${path}, которые были кэшированы до ${timestamp}, не используйте кэшированные файлы, потому что онибольше не может использоваться.
Запрос на аннулирование считается выполненным, как только вся сеть получила сообщение.Аннулирование по существу является идемпотентным действием, в том смысле, что аннулирование файлов, которые на самом деле не существуют, не является ошибкой, поскольку аннулирование говорит ребрам, что эти файлы недействительны , если они существуют.
Из этого должно быть очевидно, что правильный курс действий состоит не в том, чтобы выбрать один или другой, а в том, чтобы использовать оба при необходимости.Задайте свои TTL (или выберите «использовать заголовки кэша источника» и всегда настраивайте сервер происхождения, чтобы они возвращали их с соответствующими значениями), а затем используйте аннулирования только при необходимости для очистки кэша выбранного или всего содержимого, что может потребоваться, если выдопустил ошибку или внес значительные изменения в сайт.
Однако рекомендуется не рассчитывать на недействительность, а вместо этого использовать методы очистки кэша при изменении объекта.Разрушение кэша означает изменение фактического запрашиваемого объекта.Например, в простейшей реализации это может означать, что вы измените /pics/cat1.png на /pics/cat2.png в своем HTML-коде, а не сохраните новое изображение как /pics/cat1.png, когда вам нужно новое изображение.Проблема с заменой одного файла другим по тому же URL-адресу заключается в том, что браузер также имеет кэш и может продолжать отображать старое изображение.
См. Также Недопустимые объекты .
Обратите внимание, что основные TTL не используются для ответов об ошибках.По умолчанию ответы типа 404 Not Found кэшируются в течение 5 минут.Это Минимальное время кэширования ошибок * TTL , предназначенное для освобождения исходного сервера от получения запросов, которые, вероятно, будут продолжать сбой, но только в течение нескольких минут.