По сути, да. Оценка целевого состояния делает записи подходящими кандидатами для получения ответов, только когда они исправны. Без политики восстановления после сбоя они все жизнеспособны, когда они все здоровы.
Если вы делаете что-то вроде маршрутизации на основе задержек и у вас есть две цели, скажем, Огайо и Лондон, то у вас по существу будет двойная активная / пассивная конфигурация с обращенными ролями - Огайо активен и Лондон пассивен для зрителей на севере. Америка, и роли поменялись для зрителей в Европе. Но если вам нужен глобальный активный / пассивный режим, вам потребуется политика восстановления после отказа.
Обратите внимание, что если вы конфигурируете какой-либо дизайн высокой доступности с использованием Route 53 и целевого здоровья, лучше всего сделать все это за CloudFront - когда средство просмотра всегда подключается к CloudFront, а CloudFront выполняет поиск DNS Маршрут 53, чтобы найти правильное происхождение, основываясь на любых правилах, которые вы создали. Причина этого в том, что CloudFront всегда учитывает значения TTL DNS. Браузеры по соображениям производительности этого не делают. Ваши зрители могут застрять с записями DNS для мертвой цели, потому что их браузеры не сбрасывают свои поиски в кэше DNS, пока все вкладки во всех окнах не будут закрыты. Для таких пользователей, как я, этого почти не бывает.
Это также работает с маршрутами на основе задержки в Route 53 за CloudFront, потому что CloudFront уже направил зрителя к его оптимальному краю, и когда этот край выполняет поиск на маршруте на основе задержки в Route 53, он получает ответ он имеет наименьшую задержку от края CloudFront, который обрабатывает запрос ... поэтому оптимальны как просмотрщик к CloudFront, так и CloudFront к исходным маршрутам.
Обратите внимание также, что аварийная маршрутизация на S3 только с DNS невозможна, поскольку S3 ожидает, что имя хоста совпадает с именем сегмента, а имена сегментов являются глобальными. Отказ S3 является редким событием, но это произошло по крайней мере один раз. Когда это произошло, воздействие было ограничено одним регионом, как и планировалось. Чтобы сайт выдержал региональный сбой S3, требуются дополнительные героические действия, включающие либо триггеры CloudFront и Lambda @ Edge, либо прокси-серверы на основе EC2, которые могут по мере необходимости изменять запрос и отправлять его в альтернативное ведро в альтернативном регионе.
Маршрутизация на основе задержки в сегменты с маршрутом 53 также невозможна по той же причине, но может быть выполнена с помощью триггеров запроса происхождения Lambda @ Edge. Эти триггеры знают о регионе AWS, где выполняется данный вызов, и, таким образом, могут менять исходные серверы в зависимости от местоположения.