Миграция lift-and-shift привела к тому, что в одной группе Auto Scaling каждый инстанс EC2 запускает веб-компоненты, базу данных и кэш Redis, что вызывает переменное время отклика и перегрузку инстансов. Компания хочет разделить компоненты для повышения доступности и производительности. Какое изменение архитектуры удовлетворит это требование?

Правильный ответ разделяет монолитное приложение на отдельные компоненты, используя управляемые сервисы AWS для повышения доступности и производительности. Application Load Balancer (ALB) идеально подходит для веб-приложений, так как он работает на уровне 7 и может выполнять маршрутизацию на основе контента. Группа Auto Scaling обеспечивает масштабируемость и отказоустойчивость веб-серверов. Amazon Aurora с Multi-AZ обеспечивает высокую доступность и масштабируемость для базы данных, автоматически реплицируя данные в другую зону доступности. Amazon ElastiCache (Redis OSS) является полностью управляемым сервисом для кэширования, что значительно улучшает время отклика и снижает нагрузку на базу данных. Первый вариант неверен, так как Network Load Balancer (NLB) обычно используется для трафика уровня 4 и не подходит для веб-приложений так же хорошо, как ALB. Создание отдельной группы Auto Scaling для кэша Redis не является стандартной практикой; ElastiCache предназначен для этой цели. Второй вариант неверен, потому что NLB не оптимален для веб-приложений. Размещение кэша Redis в одной зоне доступности снижает отказоустойчивость. Третий вариант неверен, так как NLB не является лучшим выбором для веб-приложений. Использование DNS-целей для ElastiCache не является стандартной конфигурацией для ALB или NLB, так как ElastiCache управляется как отдельный сервис.