Развертывание в нескольких регионах с политикой на основе геолокации v / s Cloudfront

Question

У меня есть пользовательское происхождение, то есть веб-приложение на экземпляре EC2. Как мне решить, стоит ли мне идти на:

1. Облачный фронт CDN

или

2. развертывание нескольких экземпляров в разных регионах и настройка политики маршрутизации на основе геолокации / близости

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

Answer 1

Нет причин, по которым вы не можете выполнять оба этих действия.

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

До сих пор я только действительно указал очевидное.Но на следующем шаге есть тонкая, но важная деталь:

CloudFront выполняет поиск DNS-сервера исходного сервера из местоположения, которое находится рядом со средством просмотра , что означает, что если имя исходного домена имеет задержкуна основе набора записей в маршруте 53, указывающего на развертывания в двух или более регионах EC2, затем запрос CloudFront для «поиска» источника будет направлен к развертыванию источника, ближайшему к краю, которое также по определению будет близко кthe viewer.

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

Если оптимизация кэширования и транспорта обеспечиваетсяCloudFront не дает необходимой вам глобальной производительности: , а затем вы можете развернуть в нескольких регионах, за CloudFront ... всегда помните, что развертывание в нескольких регионах почти всегда является более сложной средой, в зависимости отв базах данных, которые возвращаютсяg ваше приложение и его оснащение для обработки межрегиональной репликации для чтения и / или записи.

Включение CloudFront в качестве внешнего интерфейса также является лучшим решением для обеспечения отказоустойчивости в нескольких региональных развертываниях, поскольку CloudFront правильноучитывает DNS TTL в записи DNS вашего исходного сервера, и если у вас настроены проверки работоспособности Route 53 для удаления нездорового региона из ответа DNS на имя исходного домена, CloudFront быстро прекратит отправку дальнейших запросов к нему.Обозреватели, как известно, не заслуживают доверия в этом отношении, иногда кэшируя ответ DNS, пока все вкладки / окна не будут закрыты.

А если CloudFront - ваш внешний интерфейс, вы можете при желании выгружать части своей логики в Lambda @ Edge.

Answer 2

Вы можете использовать несколько регионов в основном по причинам лота,

1. Близость
2. Аварийное переключение (в случае сбоя первого региона запросы могут быть отправлены в другой регион)

Лямбда-развертывание в нескольких регионах здесь четко задокументировано.Вы можете применить ту же логику ко всем ресурсам AWS.(DynamoDB, S3)

https://aws.amazon.com/blogs/compute/building-a-multi-region-serverless-application-with-amazon-api-gateway-and-aws-lambda/

Вы также можете запустить Lambda @ Edge, чтобы принудительно выполнить все ваши запросы / сплиты в одном регионе на границе.

Надеюсь, это поможет.