AWS S3: цены на недействительные запросы для React. приложение js, размещенное на S3

#amazon-web-services #amazon-s3 #amazon-cloudfront

#amazon-веб-сервисы #amazon-s3 #amazon-cloudfront

Вопрос:

У меня есть веб-приложение, разработанное с использованием React.js , HTML и Java script. Это react.js веб-приложение вызывает серверные API REST.

Я разместил это веб-приложение на AWS S3.

Я могу получить доступ к веб-приложению с помощью HTTP.

Чтобы включить доступ на основе HTTPs, я планирую использовать AWS cloud front.

У меня не так много статического медиа-контента, но мало css, js и несколько небольших изображений.

Насколько я понимаю, цены на облачный фронт основаны на

  1. Объем передачи данных
  2. Количество запросов HTTP / HTTPS
  3. Запросы о признании недействительными

В моем случае веб-приложение выполняет вызовы HTTPs для серверной части, когда пользователь запрашивает веб-страницу или хочет выполнить поиск в записях.

Я хочу знать, обрабатывается ли этот каждый запрос к серверной части как "Invalidation Request" ?

Или запросы на аннулирование применимы только при изменении статического содержимого (HTML, CSS, JS, изображений)?

Существует ли какой-либо другой экономически эффективный вариант включения HTTPs для веб-приложений на основе S3?

Комментарии:

1. Отправка запросов в облачный интерфейс — нет invalidation request . Вы можете прочитать о недействительных запросах здесь

Ответ №1:

Вы могли бы создать только invalidation request , если бы хотели очистить кэш CloudFront от кэшированного содержимого (т. Е. Старой версии файлов) и использовать новую версию.

С вашим проектом React / HTML / CSS вы поместите его в корзину S3 и установите свою корзину S3 в качестве источника для CloudFront. Когда CloudFront извлекает объекты из S3, он кэширует их в своем пограничном кэше для будущих запросов TTL (время жизни) объекта. Объект останется там, и CloudFront не будет проверять ваше происхождение на наличие новой версии объекта, пока не истечет срок действия TTL.

Запрос на аннулирование попросит CloudFront удалить объекты из кэша, и поскольку их больше нет в кэше, когда запрос поступает в CloudFront, он получит объект из вашего хранилища S3.

По сути, каждый раз, когда вы публикуете новую производственную сборку, вам нужно, чтобы CloudFront использовал новые версии ваших объектов, поэтому вы захотите делать аннулирование каждый раз, когда вы вводите новую версию своего объекта в производство.

Вы можете прочитать больше о недействительности и стоимости недействительности здесь:https://aws.amazon.com/blogs/aws/simplified-multiple-object-invalidation-for-amazon-cloudfront /

Стоит отметить, что мы делаем 5-10 выпусков в день, и наш CodePipeline заботится о недействительности для нас. Мы никогда не платили никаких сборов за недействительность. Кроме того, просто предупреждаю, что, по моему опыту, в зависимости от количества объектов, признанных недействительными, аннулирование может занять от нескольких минут до более чем 30 минут.