В чем преимущество добавления 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 будет видеть только IP-адрес Cloudfront (я знаю, что это можно исправить, чтобы иметь IP-адрес клиента, но тогда у вас будут проблемы со следующим пунктом).
• В качестве дополнительной работы вам необходимо часто обновлять группы безопасности LB, чтобы они соответствовали IP-адресам CloudFront (для этого региона), так как, я полагаю, вы хотите получать трафик только из своего Cloudfront, а не напрямую из публичной конечной точки LB,

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

Есть идеи?

Спасибо!

Answer 1

Вот некоторые из преимуществ облачного интерфейса поверх вашего ALB

• Для веб-приложения или другого контента, который обслуживается ALB в эластичной балансировке нагрузки, CloudFront может кэшировать объекты и предоставлять их напрямую пользователям (зрителям), уменьшая нагрузку на ваш ALB.

• CloudFront также может помочь уменьшить задержку и даже противостоять некоторым распределенным атакам типа «отказ в обслуживании» (DDoS). Однако, если пользователи могут обойти CloudFront и получить прямой доступ к вашему ALB, вы не получите этих преимуществ. Но вы можете настроить Amazon CloudFront и балансировщик нагрузки приложений, чтобы запретить пользователям прямой доступ к балансировщику нагрузки приложений ( ).

• Плата за исходящую передачу данных из сервисов AWS в CloudFront составляет 0 долларов США за гигабайт. Стоимость использования CloudFront обычно на полцента меньше за гигабайт, чем передача данных для того же уровня и региона. Это означает, что вы можете воспользоваться преимуществами дополнительной производительности и безопасности CloudFront, разместив его перед своими ALB, AWS ElasticBeanstalk, S3 и другими ресурсами AWS, доставляющими объекты HTTP(S) практически без дополнительных затрат (документДок. ).

• Глобальная сеть CloudFront, состоящая из более чем 100 точек присутствия (POP), сокращает время на установление соединений с видом на зрителя, поскольку физическое расстояние до зрителя сокращается. Это снижает общую задержку при обслуживании как статического, так и динамического контента ( ).

• CloudFront поддерживает пул постоянных подключений к источнику, тем самым сокращая накладные расходы на повторное установление новых подключений к источнику. По этим соединениям трафик между CloudFront и источниками AWS направляется по частной магистральной сети для обеспечения надежности и производительности. Это снижает общую задержку при обслуживании как статического, так и динамического контента (DocDoc ).

• Вы можете использовать географическое ограничение, также известное как географическая блокировка, чтобы запретить пользователям в определенных географических регионах доступ к контенту, который вы распространяете через распространение CloudFront (Doc).

Другими словами, вы можете использовать преимущества ClodFront для добавления новых функций в свой источник (ALB, Elastic Beanstalk, S3, EC2), но если вам не нужны эти функции, лучше не делать эту конфигурацию в своей архитектуре.

Answer 2

• Cloudfront позволяет вам доставлять контент быстрее, поскольку местоположения Cloudfront Edge ближе к запрашивающему пользователю и подключены к регионам AWS через магистраль сети AWS.
• Вы можете отключить SSL на облачном сервере и заставить балансировщик нагрузки прослушивать порт 80.
• Cloudfront позволяет легко применить ограничение геолокации в 2 клика.

Answer 3

Я думаю, что еще одна причина, по которой вы можете захотеть использовать CF перед ALB, заключается в том, что у вас может быть лучший опыт работы с WAF (если вы уже используете (или планируете) WAF, конечно).

Несмотря на то, что WAF доступен как для ALB, так и для CF, ALB и CF используют разные службы для WAF. Причина в том, что Cloudfront — глобальный сервис, а ALB — по одному на регион.

Это может привести к более сложному управлению и дублированию ACL (и, возможно, к увеличению затрат).

Answer 4

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

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

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

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

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

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

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

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