Приложение использует дистрибутив Amazon CloudFront с публичным Application Load Balancer (ALB) в регионе в качестве источника по умолчанию. Приложение развернуто во вторичном регионе в конфигурации warm-standby, и бизнес требует нулевого RTO для HTTP GET-запросов. Как можно автоматизировать переключение на вторичный регион, чтобы HTTP GET-запросы соответствовали этому RTO?

Правильный ответ обеспечивает нулевой RTO для HTTP GET-запросов, используя встроенную в CloudFront функциональность групп источников (Origin Groups). Добавление вторичного ALB в качестве нового источника и создание группы источников с основным ALB в качестве главного позволяет CloudFront автоматически переключаться на вторичный ALB при получении HTTP 5xx ошибок от основного. Это происходит на уровне CloudFront, до того как запрос достигнет конечного пользователя, что соответствует требованию нулевого RTO. Создание второго дистрибутива CloudFront с записями Route 53 (первый вариант) не гарантирует нулевого RTO, так как переключение DNS занимает время из-за кэширования. Использование Route 53 с политикой отработки отказа непосредственно для ALB (третий вариант) также страдает от задержек DNS и не использует преимущества CloudFront. Функция CloudFront, возвращающая 307 Redirect (четвертый вариант), не обеспечивает нулевого RTO, так как требует дополнительного HTTP-запроса от клиента.