한 회사에서 온프레미스에 Apache 프런트엔드, 모놀리식 Java 미들 티어, PostgreSQL 스토리지를 사용하는 3계층 웹 애플리케이션을 운영하고 있습니다. 최근 프로모션으로 인해 모든 계층에 과부하가 발생하여 애플리케이션이 충돌하고 데이터베이스가 읽기 용량 제한에 도달했습니다. 여러 프로모션이 계획되어 있습니다. 확장성을 극대화하고 운영 노력을 최소화하는 AWS 마이그레이션을 설계해야 합니다. 다음 세 가지 단계 중 이를 달성하는 방법은 무엇입니까? (세 가지 선택)

정적 자산을 Amazon S3와 CloudFront로 분리하면 프런트엔드의 확장성을 높이고 Apache 서버의 부하를 줄여줍니다. CloudFront는 엣지 로케이션에서 콘텐츠를 캐싱하여 지연 시간을 줄이고 성능을 향상시킵니다. AWS Elastic Beanstalk는 Java 애플리케이션을 쉽게 배포하고 관리하며, 자동 스케일링을 통해 미들 티어의 부하를 자동으로 처리하여 운영 노력을 최소화하고 확장성을 제공합니다. Amazon Aurora PostgreSQL로 마이그레이션하고 읽기 복제본에 Aurora Auto Scaling을 사용하면 데이터베이스의 읽기 용량 제한 문제를 해결하고 높은 확장성과 가용성을 제공합니다. 로드 밸런서 뒤의 EC2 인스턴스에 Apache 프런트엔드를 리호스트하고 Amazon EFS에 정적 자산을 저장하는 것은 확장성을 제공하지만, S3/CloudFront 조합만큼 효율적이지 않으며 EFS는 웹 콘텐츠 제공에 최적화된 서비스가 아닙니다. Java 애플리케이션을 Docker 컨테이너로 리팩터링하고 AWS Fargate에서 실행하는 것은 좋은 옵션이지만, Elastic Beanstalk는 모놀리식 애플리케이션을 위한 더 빠르고 운영 노력이 적은 마이그레이션 경로를 제공합니다. 온프레미스 서버의 두 배 메모리를 가진 EC2 인스턴스에 PostgreSQL 데이터베이스를 리호스트하는 것은 일시적인 해결책일 뿐, 데이터베이스의 읽기 용량 제한 문제를 근본적으로 해결하지 못하며 Aurora만큼 확장성이 뛰어나지 않습니다.