В чем преимущество добавления AWS Cloudfront поверх AWS Application LB?

Question

Я посещал тренинг по AWS, и они объяснили нам, что хорошей практикой является кэширование всего динамического контента через Cloudfront с настройкой TTL в 0, даже если у вас есть LB впереди на балансировщике нагрузки.Так что это может быть как:

Route 53 -> CloudFront -> Application LB

Я не вижу никаких преимуществ этой архитектуры, вместо того, чтобы иметь непосредственно (только для динамического контента):

Route 53 -> Application LB

Я не вижуточка, так как Cloudfront всегда будет отправлять весь трафик на LB, поэтому у вас будет:

• Два HTTPS-согласования (клиент <-> Cloudfront и Cloudfront <-> LB)
• Неткэширование вообще (это динамический контент, его не следует кэшировать, поскольку это означает «динамический»)
• У вас не будет IP-адреса клиента, поскольку ваш LB будет видеть только Cloudfront IP (я знаю,это можно исправить, чтобы иметь IP-адрес клиента, но тогда у вас будут проблемы со следующим пунктом).
• В качестве дополнительной работы вам необходимо часто обновлять группы безопасности LB, чтобы соответствоватьCloudFront IP (для этого региона), так как, я полагаю, вы хотите получать трафик только с вашего Cloudfront, а не напрямую с публичной конечной точки LB.

Так что, возможно, я упускаю что-то важное в этомRoute 53 -> CloudFront -> Application LB архитекторture.

Есть идеи?

Спасибо!

Answer 1

Cloudfront - действительно удивительный сетевой сервис доставки контента CDN, такой как Akamai и т. Д.Теперь, если в ваших веб-приложениях много динамического контента, например, медиафайлы, даже статический код, вы можете поместить их в корзину S3 в другой сервис хранения объектов AWS.

Как только вы получите динамический контент в корзину S3, вы можетеСоздайте дистрибутив Cloudfront, считая, что в качестве источника это явление будет кэшировать ваш динамический контент в нескольких периферийных местах AWS.И это станет быстрым для доставки на стороне клиента.

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

Для обеспечения высокой доступности и масштабируемости мы рассматриваем такую ​​архитектуру приложения.

• Мы создаем группу автоматического масштабирования наших экземпляров ec2 и помещаем их за балансировщиком нагрузки и в соответствии с нашим примером политики масштабирования:если загрузка моего процессора или памяти превышает 70%, запускаю другой экземпляр или аналогичный.

Вы также можете установить политику запросов для балансировщика нагрузки, чтобы обслуживать трафик на ваш сервер ec2, возможно, в цикле Robbin или при доступности.

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

Спасибо и счастливого пути !!