Компании необходимо реализовать аварийное восстановление для критически важного приложения, которое в настоящее время работает в одном регионе AWS. Веб-интерфейс использует инстансы EC2 за Application Load Balancer (ALB). Приложение записывает данные в инстанс Amazon RDS for MySQL DB и выводит обработанные документы в бакет Amazon S3. Финансовый отдел выполняет прямые запросы к базе данных для создания отчетов; в пиковые часы эти запросы потребляют ресурсы БД и снижают производительность приложения. Разработайте решение для аварийного восстановления, которое минимизирует потерю данных и устраняет влияние запросов финансового отдела на производительность. Какое решение удовлетворяет этим требованиям?

Правильный ответ обеспечивает минимизацию потери данных и изоляцию запросов финансового отдела. Создание реплики для чтения RDS в другом регионе позволяет финансовому отделу выполнять запросы без влияния на производительность основного приложения, а также служит основой для восстановления БД с минимальной потерей данных (RPO). Копирование AMI EC2 и настройка S3 CRR обеспечивают быстрое развертывание приложения и доступность данных в случае аварии. Повышение реплики для чтения до автономного экземпляра БД является стандартной процедурой аварийного восстановления для RDS. Неправильные варианты: Перенос в DynamoDB требует значительной переработки приложения и не является решением для аварийного восстановления текущей архитектуры. Запуск дополнительных EC2 в другом регионе и добавление их в ALB не создает полноценную стратегию аварийного восстановления с активным/пассивным подходом, а скорее масштабирование. Ежечасные снимки RDS могут привести к большей потере данных (RPO) по сравнению с репликой для чтения. ElastiCache не решает проблему изоляции запросов финансового отдела, а лишь кэширует данные.